1
Lab 1 - EmVi Product Description
EmVi – Orange Team
David Wise
CS411W
Mrs. Brunelle
July 26, 2016
Version 4.0
Lab 1 – EmVi Product Description
2
1.
Table of Contents
INTRODUCTION ................................................................................................................... 3
2.
EMVI PRODUCT DESCRIPTION ........................................................................................ 5
2.1
Key Product Features and Capabilities ........................................................................... 7
2.2
Major Components (Hardware/Software) ....................................................................... 8
3.
IDENTIFICATION OF CASE STUDY................................................................................ 11
4.
EMVI PRODUCT PROTOTYPE DESCRIPTION .............................................................. 12
4.1
Prototype Architecture (Hardware/Software) ................................................................ 14
4.2
Prototype Features and Capabilities ............................................................................... 18
4.3
Prototype Developmental Challenges ............................................................................ 22
GLOSSARY ................................................................................................................................. 24
REFERENCES ............................................................................................................................. 28
List of Figures
Figure 1 Current Marketing Email Generation Proccess ................................................................ 6
Figure 2 Proposed Marketing Email Generation Process ............................................................... 7
Figure 3 Real World Product Major functional Component Diagram ........................................... 9
Figure 4 EmVi User Interface Site Map ....................................................................................... 13
Figure 5 Prototype Major functional Component Diagram .......................................................... 14
Figure 6 EmVi Database Schema ................................................................................................. 15
Figure 7 User Log on Page Test Script ......................................................................................... 22
Lab 1 – EmVi Product Description
3
1. INTRODUCTION
Email is an active tool in the marketing industry. The use of email in marketing dates back
to the early 90’s. During its early days email was used to send unsolicited bulk messages, more
commonly known as “SPAM”. Things have changed quite a bit since then. Even in today’s new
world of mobile devices and social media networks, email still reigns as the dominant method for
advertising and marketing.
Two thirds of all email users check their email on average three times a day (Connolly,
2011). This means that the email content is being viewed by potential customers. In a report
from SOS Emarketing, ROI Comparison Across Media Channels, email marketing generates, on
average, about $40 for every dollar invested (Schwartz, 2011).
Because of this, 97% of
companies said that they would be increasing their email marketing budgets (Rice, 2012).
The process of creating email content across various clients is time consuming. The email
has to be created and then sent through a rigorous approval process that can “trap” that content in
an endless loop of disapprovals and rework. The goal of this approval process is to ensure that
accurate representation of the company and its products is displayed in the marketing email that
is delivered. Mistakes are costly and embarrassing so this approval is an essential step.
Along with the process being time consuming, testing to make sure it renders correctly can
be complicated. Keeping track of changes in the client software is a full time job when you are
talking about hundreds of different options. This is accomplished through the time consuming
task of sending out the content and checking to see if it looks right at the receiving end and then
approving or rejecting. If the email is rejected then the process has to begin again and all effort
toward delivery is lost.
Lab 1 – EmVi Product Description
4
A solution is needed to reduce the time and complexity of generating and approving
marketing email. The solution needs to be a stand-alone email content management system with
the capability of being integrated into an existing email marketing system. The process of
getting approvals needs to be streamlined in a way as to break the endless approval loops that
can send an email campaign task beyond deadlines. There needs to be fast reliable testing of the
email content where results can be provided to those generating the campaigns to reduce the
errors the first time. If the content generation team had the capability to view that marketing
email before it moves on to the approval stages, it would provide an opportunity to proof the
content in advance, reducing the number of times a campaign is rejected. This would reduce the
time from concept to delivery for a marketing email.
EmVi – Email Viewer (Email Content Management System) provides a global solution for
email marketing content management, testing and campaign distribution. The overall effort in
this project is to provide a tool that will seamlessly integrate into the current standard operating
procedure of any email marketing agency allowing for a more streamlined approach to their
marketing strategy. This tool will store the content, making it available to other projects and
campaigns through a content management system (CMS). It will provide an interface through
which testing can be performed at any stage in the development of the campaign. EmVi will
create an environment from which a streamlined approval and distribution process can take
place, reducing the time and complexity currently involved in performing the task of creating
and approving a marketing email.
(This space intentionally left blank.)
Lab 1 – EmVi Product Description
5
2. EMVI PRODUCT DESCRIPTION
EmVi will be a stand-alone system to be used on a single workstation or run on a server to
be used in a larger organization with multiple entities needing access. EmVi will have the ability
to interface with other tools such as CMS or Content Delivery Network (CDN) through the use
of application programming interfaces (API). The tool will also provide a What You See Is
What You Get (WYSIWYG) editor to allow the content to be modified at different stages of
approval.
EmVi will provide an interface where campaign content can be uploaded quickly and stored
on the local system in a stand-alone environment or on a server in the larger installation. After
the content has been uploaded it can be viewed in various web browsers and email clients
through the automated retrieval of images from test browsers and clients. This will give an
accurate set of images from which an approver can verify the content is correct and visually
appealing.
EmVi will allow all email campaign marketing tasks to take place in house generating the
end product in less time. It will provide tools to allow the team generating the content to see it in
real browsers and clients, allowing them to critique their own work prior to sending it off for
approval and thus decreasing the amount of little errors that delay the distribution of marketing
email. Decreasing the amount of time from inception to delivery of a marketing email will
reduce the cost of developing the campaign, increasing the return on investment.
The goal of EmVi is to streamline the email testing process to enable rapid iteration on
designs allowing for a quicker approval of email campaigns to be distributed. The objective in
creating EmVi is to automate much of the current process outlined in Figure 1. As described
earlier, this process is very time consuming and some of the finer details that will be discussed
Lab 1 – EmVi Product Description
6
later are complex. This current process has a flaw in that some of the steps are handled by
outside agencies causing delays in the testing and approval phases when working a campaign
through the process. With EmVi, the aim is to automate some of these steps and bring others
back into the control of the local teams. Figure 2 outlines where EmVi will reduce the current
process, thus reducing the timeline required to generate and distribute content.
Figure 1 Current Marketing Email Generation Proccess
In Figure 2, the tasks of uploading and testing are moved back into the creative team’s
hands. The whole process stays in house and can be accomplished without the reliance of
another organization or group. With EmVi the aim is to provide an interface to upload content
and automate the distribution of test emails, generation of preview images, the approval process
and version control for campaigns.
Lab 1 – EmVi Product Description
7
Figure 2 Proposed Marketing Email Generation Process
2.1 Key Product Features and Capabilities
In order for EmVi to reduce and automate much of the current process, some features and
capabilities need to be defined. Some of these are integration of existing systems where others
will need to be developed to meet the needs of the email marking industry. Examples of tools
that could be integrated are a CDN, CMS, and existing email systems. The parts that would need
to be developed are the interactions between these existing systems and the tool that handles the
movement of the data from one to the other.
The ability to store and edit the content is very important in email marketing. After all, if
there were no content there would be no email. This content can be stored locally on a standalone configuration or on a fileserver or CMS in a larger installation. These methods of storing
content will allow the storage of older versions as part of the version control system as well as
allowing the EmVi application to search within campaigns. The general types of data that will
Lab 1 – EmVi Product Description
8
be stored are text files, HTML files and images. The text and HTML will be stored in the
database as a long string while the images will be stored on a CDN with a URL in the database
pointing to its location.
A CDN will allow for the seamless delivery of the content to the test environment and
ultimately to the final distribution of the final product. EmVi will replace the local URLs in the
HTML of the marketing email with the remote URLs to the location on the CDN where the
images are stored. This will allow for the reuse of images in different version of the campaign in
order to meet the need of the unknown environments to which emails will be sent for testing.
EmVi will need an approval system to properly vet each and every campaign prior to its
deployment to the public. This approval process will force the marketing email to be checked
for quality and correctness before a final deployment is initiated. Mistakes are costly and
embarrassing to a company.
This approval system will create an environment where costly
mistakes can be corrected before being sent out.
EmVi will provide a method to view campaigns as they would be seen in different
browsers and email clients. This will assist in the approval process because views can be
regenerated through the tool to provide real time analysis of a campaign. This gives the creators
and approvers more control and accountability for what they are creating and approving.
Because this is all done in the EmVi tool it will get done quicker rather than relying on some
outside agency or group to provide those images for analysis which could be the next day.
(This space intentionally left blank.)
Lab 1 – EmVi Product Description
2.2
9
Major Components (Hardware/Software)
In order to implement the features described in the previous section, there are hardware
and software needs. Figure 3 provides a quick look at all the parts together that will be described
in further detail later. EmVi will be comprised of many different servers and development
machines. There will be Web, SMTP and Database services utilized for EmVi. These can all be
installed on a single workstation or server as would be the case in a stand-alone system or
distributed on multiple platforms in a larger scale operation. There will be client machines used
to access the tool via a web browser.
Figure 3 Real World Product Major functional Component Diagram
EmVi will be running on a host system with an operating system. If the database and
scripting language can be installed and configured on the host system, then EmVi can be
configured to run there. Some of the software that will be used to set up and run EmVi include
MySQL, PHP, and the API interfaces to the CDN and test rendering provider.
Lab 1 – EmVi Product Description
10
The web server software will be Apache or Microsoft Internet Information Server with
the PHP scripting language installed as an add-in. PHP will be the scripting language that will
act as the interface between the database and the HTML that is presented to the end user. PHP
will allow the creation of an access control system in order to protect the data being stored in the
database. With PHP, EmVi will interface with the public API for the CDN and CMS if one is
configured with the system.
The webpage logic will be controlled with PHP where a Model, View, Controller (MVC)
site configuration will be implemented. In this MVC the EmVi GUI will be able to interface
with MySQL securely, separating the logic from the view.
EmVi being an email viewer
application, will need some way to get those emails out and the images back. This will be
accomplished via an email SMTP interface.
(This space intentionally left blank.)
Lab 1 – EmVi Product Description
11
3. IDENTIFICATION OF CASE STUDY
A case study, performed with the customer, Keith Walsh, provided some insight into the
email marketing design and approval tools currently in use in the industry. Keith Walsh is a
development lead for email marking systems with Microsoft. Some of the internal clients that he
deals with are Bing, MSN and Hotmail. Keith provided a view of the internal process of the
current email marketing system that is in place today outlined in Figure 1.
There are three major groups involved in getting marketing email approved in Keith’s
current system. The first of which is the Marketing Department. They take direction from
company executives and are responsible for meeting engagement metrics or making sure that the
content reaches the potential customers. The next group is the Advertising Agency who is
responsible for creating the HTML content for the marketing email. This group is hired by the
Marketing Department. The last group is the Data Operations group who is responsible for safe
handling of customer data and sends campaign to mailing lists and collects post-campaign
metrics and analysis. The current system is working but there is room for improvement.
EmVi will provide this improvement. With the help of the faculty mentor, Stephen Zeil, an
associate professor at Old Dominion University, and the domain experts, the EmVi tool will be
tested in order to develop a useful tool for users of email Content Management Systems. The
domain experts are Sarah Johnson, President of A Touch of Tech, Dana Rambo, Program
Manager at Microsoft, and Ryan Ward, a Network Administrator at SimIS. This will provide a
broad group from which to get the best and most useful feedback during testing of the
application and network performance from the perspective of a user.
Lab 1 – EmVi Product Description
12
4. EMVI PRODUCT PROTOTYPE DESCRIPTION
In an effort to provide a proof of concept the EmVi team will be building a prototype of
EmVi that will demonstrate the capabilities of the application without all of the complexity that
would be involved in a full scale build and configuration. Test campaigns and pre generated
images will be used to demonstrate the flow of data and approvals through EmVi. The EmVi
prototype will be an email content management system that will streamline the testing and
development process of campaigns. With this prototype, the plan is to show a reduction of errors
in email content, reduction in cost associated with processing an email campaign and get those
campaigns to production and to the customers in a quicker more reliable manner.
The EmVi prototype will provide a GUI written in HTML, PHP and JavaScript containing
various user role interfaces such as administrator, campaign administrator, contributor, and
approver. Each of these roles will have different capabilities within the tool derived from flags
set in the database. Some of these roles can be seen in the site map in Figure 4. The prototype
will demonstrate the functionality of the registration and logon pages. After a user registers for
access to the prototype it will demonstrate the capability to deliver confirmation email via the
send mail function provided in PHP. The backbone of the EmVi tool will be the MySQL
database. The EmVi team will demonstrate the ability to interface with database in order to save
new data, update records and remove data. This will provide a demonstration of the access
control measures and version control for both EmVi versioning and Campaigns. This tool will
automate the distribution of test emails which currently, is a manual process. After these test
emails are sent the EmVi prototype will render and retrieve the rendered marketing email images
to be used in the approval process.
Lab 1 – EmVi Product Description
Figure 4 EmVi User Interface Site Map
(This space intentionally left blank.)
13
Lab 1 – EmVi Product Description
14
4.1 Prototype Architecture (Hardware/Software)
Figure 5 provides a visual representation of the prototype components. The prototype
will simulate parts of the application in order to provide services that would normally already be
onsite or need to be purchased such as a CDN account. This diagram will be described in further
detail later.
Simulated CDN file
share
Web
Browser
Email Designer
EmVi Web Application
Running on a virtual
machine on CS ODU
network
File System
Version
Controlled
Simulated Email
Simulated Email
Simulated Email
previews for view previews for view previews for view
SMTP Server Running in
a virtual environment
On ODU CS network
My SQL
Database Running on
ODU CS Network
Simulated Data containing test
campaigns with links to
simulated CDN and Previews.
Figure 5 Prototype Major functional Component Diagram
In the prototype, the server will be a virtual computer running Linux operating system
located on the computer science network at Old Dominion University. The development and test
team will utilize this virtual computer to run the web application, the database, and the SMTP
services needed to test email campaigns. The development environment will be the EmVi
team’s personal computers and or the ODU CS lab.
Much of the development can be
accomplished with the typical text editor like notepad. The development team will be using
some integrated development environments (IDE) such as Microsoft Expressions, Eclipse, and
Notepad++ to program the HTML and PHP required to generate the GUI. The CS350 git system
will provide a way to handle the versioning and the multiple programmer environments.
Lab 1 – EmVi Product Description
15
The prototype will simulate access to the CDN and Test rendering environment via an
API to a file server containing the files that will be stored in the database as a URL. A
demonstration of the functionality of EmVi will be accomplished with the use of the open source
MySQL database engine.
This is a fairly powerful database engine for smaller projects that
require database support. MySQL databases can be easily ported over to other larger database
engines such as Microsoft SQL and Oracle. MySQL will be used because it is free and will
work in small scale implementations of EmVi. Figure 6 provides a high level representation of
the database schema that is planned to be implemented for EmVi. It will hold the access control
parameters as well as build the structure needed to generate an approval flow through the system
and maintain data needed to generate the test email.
Figure 6 EmVi Database Schema
The EmVi development team will be building a custom framework on which to build the
rest of EmVi. It will be a structured MVC environment separating the logic from the visual
Lab 1 – EmVi Product Description
16
presentation to the end user. This will allow the tool to process in the back end while still
engaging the end user of the application. Play framework was considered as an initial starting
point but after looking into that found that the learning curve would be greater than just building
one from scratch. The MVC will be built using the PHP scripting language.
The prototype for EmVi in the web server software will not differ too much from what
the real application will provide. The Linux, Apache, MySQL, and PHP (LAMP) configuration
will be used to accomplish this. The difference will be in some of the scripting and API
programming.
EmVi will deploy a User based access control system. Users will register with the site
and wait for an EmVi administrator’s approval before being allowed to log in. The EmVi
administrator will set the permissions for the end user based on the request and the role that user
plays in the campaign lifecycle. Access rights will be stored and managed in the database and
maintained via an administration page in the web application shown in Figure 4.
The development team will provide an API for EmVi to allow for seamless integration
into other systems. This will be publically available. This API will provide an interface from
which other developers can incorporate this tool into their environment. It will provide a list of
programming functions that will pass instructions into the EmVi environment.
The web page logic will not change drastically from what is proposed for a real world
product provided in Figure 4. The movement and PHP scripting will be the same and only the
API’s that determine where the data comes from will change in a real world implementation of
the tool. Testing functionality will need to be added to the prototype in order to fully test and get
automated feedback from the system.
information to the development team.
This will not change the logic just provide more
Lab 1 – EmVi Product Description
17
The interface with the MySQL database will be accomplished via the MySQL API
provided with PHP. The database will be prepopulated with test data to run a campaign from
inception to closure. The EmVi prototype will have existing campaigns in various stages of
completion and approvals to test every avenue of the system. The data that will be stored as part
of the prototype will be like data used in production so that a true representation of the tool can
be acquired.
EmVi will utilize a real SMTP server to generate email for both registration and email test
sends. These emails will then have to be parsed to generate images that the approvers will
review to allow them to make informed decisions to advance a campaign. EmVi will use the
sendmail application that can be setup on Linux and the PHP API mail, to send out the
notification and test email.
(This space intentionally left blank.)
Lab 1 – EmVi Product Description
18
4.2Prototype Features and Capabilities
In the prototype, EmVi will simulate some of the features and capabilities that would be
programmed in the real world application. Some of the areas that will be simulated will be the
API to CDN and the email rendering environment. If the EmVi team has the bandwidth to add
these in as a non-simulated feature, then that will take place toward the end of the semester.
Some of the major features include authentication, storage of campaign data, the approval
workflow, and the email send-to test distribution. These will all be provided in the prototype of
EmVi either as a functioning part of the application or a simulation to assist in demonstration the
capabilities.
Authentication will be handled by the database and PHP scripts at a logon page. After a user
registers for access to the tool the EmVi administrator can then approve the registered user and
set that user’s roles in the system. Once this is complete, the user will be able to browse to the
EmVi logon page and present their credentials for authentication. If they are successfully
entered, the user will be granted access to the EmVi tool with the user access roles defined in
their account. At successful authentication, a cookie will also be issued for managing the current
session for the user and provide some security as the user moves through the site and the data
stored within the database.
The determination of what will be stored and how to store it is the first thing that needs to be
accomplished to make all of the parts of EmVi work as one fluent system. With a campaign,
there will be HTML, plain text and image files that will need to be stored. The plan is to store
the HTML and text files as long strings in the database and the image files on a simulated CDN.
The prototype will have the ability to interpret, parse and insert into the database or unpack files
and copy them to the file shares in the case of images. A file server will be used to simulate the
Lab 1 – EmVi Product Description
19
CDN, so there will be a URL pointing to the image that can be used when generating the
campaign email on send.
The workflow will not be simulated. Test users will be generated in the EmVi prototype to
allow the movement of a campaign from inception to final product through the system. This will
provide a workflow demonstration of the tool with each user role acting on the campaign in its
turn.
When a new campaign is generated, it is attached to an automatic test distribution list. The
campaign administrators (those creating the campaign instance) will have the option to add
additional email addresses to the campaign for sending to their own test accounts outside of the
tool. The send-to distribution will be an automated aspect of the tool and will be used to
generate the images of the campaigns in the different browsers and clients.
With any tool there needs to be a division of labor. The EmVi tool will separate the roles
into four major sections; campaign administrators, contributor, approver, and administrators.
Each of these groups will play different key parts in the tool and workflow.
Campaign Administrators will kick off the campaign and workflow. They are the catalyst for
this process. An administrator can generate a new empty campaign or kick off a new one from a
copy of an existing campaign that they already have access to.
Contributors will be able to edit the campaigns that they have access to allowing them to add
and remove content from the campaign. They will be able to copy content between campaigns
that they own and can set campaigns as ready for testing and approval. They will be able to
upload content to the campaign such as HTML and text files as well as content to display the
HTML properly such as photos.
Lab 1 – EmVi Product Description
20
An approver will be able to do all the contributor tasks as well as approve campaigns created
by any contributor. They will be able to reject active campaigns awaiting approval to send back
to the contributor for further editing. As an approver, they will be able to set the status of a
campaign based on their analysis of the tests. With the approver having the same capabilities as
a creator, a system of checks and balances needs to be in place, so an approver cannot approve a
campaign that is generated by self.
Administrators will be able to do all tasks that all of the other user types can do with the
addition of account maintenance and EmVi system configuration. Administrators will have the
ability to assign and remove contributor as owners of campaigns. Administrators can modify
access rights to campaigns assigning contributors and approvers to the campaign workflow that
they currently do not belong to. They can edit the status of campaigns. One of the major roles of
an administrator is access control. They will be responsible for the addition, approval and
modification of user accounts on the system.
Registration will be required in order to use this system. The data being housed could
potentially be proprietary in nature and needs to be protected and separated by a need to know
environment. There will be a registration page in the GUI with a link from the home logon page.
After a potential user registers for access, they will still be unable to log into the system until
they have been verified by an administrator who will, as described as part of their roll, approve
or reject the request for access. The user will receive an email that will be sent using the PHP
send mail function and the SMTP server. This email will contain information about the user’s
registration and the steps that the user can expect to happen next. After successful registration
and activation, the user will be able to log into the EmVi tool via a logon page that will generate
session information. They will be able to use the system as long as the session is active. The
Lab 1 – EmVi Product Description
21
session will have an inactive timer that will auto log out after a set amount of time. When the
user logs off or closes the browser, their session will be destroyed to prevent unauthorized
access.
The tool home page will be the logon page. The user will present their credentials to the tool.
If the credentials provided match what is stored in the database fir that user, they will be granted
access to the site. If not then they will receive a message stating that the account does not exist
and request that registration take place, that the account is not active, or that improper credentials
were provided. Once logged in the user roles kick in to allow them to perform their assigned
actions in the tool.
The ability to preview test email is an important aspect of this tool. The email preview will
allow the final inspection of an email campaign and the grounds for approval or rejection of a
campaign. After a campaign is sent to the test distribution list, a compilation of the images will
be provided that represent how the campaign email will look in different HTML browsers and
email clients to ensure that no mistakes were made and that it renders correctly for proper
viewing at the customer end of the chain.
These will be presented as thumbnails to the
contributors and approvers in the EmVi tool, where they will have the ability to sample as many
as is needed to verify correctness of the campaign before sending out to customer distribution.
The EmVi team along with the case study group will run through the features defined in this
prototype description. Test scripts will be used to verify the functionality of the GUI. This will
ensure that it is working and looks correct. Figure 7 is an example of the script that would be
used to test the user logon page.
Lab 1 – EmVi Product Description
22
Figure 7 User Log on Page Test Script
4.3Prototype Developmental Challenges
As with any program there are development challenges. Defined in this section are the
known risks and what the team plans to do to mitigate the risks. Program latency and scaling
issues, problems with version control, security risks and others described in this section will have
to be overcome..
Latency and scaling are interconnected. As the amount of data passing through the EmVi
tool increases so will the time to process that data and get it to the end user. This will be
overcome by thoroughly testing and optimizing the algorithms used to retrieve and display the
data to improve the latency that is usually associated with scaling. The team will also stress test
the database by loading as much data as they can into the system to see how it performs as the
amount of data stored increases.
Lab 1 – EmVi Product Description
23
Automating the version control could be problematic in that it could cause the saving of too
much data or duplication of data when no changes were made.
A manual interface for
versioning of the campaigns will be provided in the tool. This puts the campaign administrator
back in control of the version control. This should only be used in the case that the campaign
administrators are not satisfied with the way the automated version control is working or the
automation fails to run properly.
The rendering and retrieval of test emails pose many issues. The testing of every available
client and the access and retrieval of images from all browsers and clients are all huge efforts and
may be out of the possible scope for the time allotted for generation of a prototype. The
prototype will generate a simple email test that will allow the users to send to an email of choice
to demonstrate the email generation and sending capability. The user will be able to check their
mailbox manually to see the rendered email. If there is enough time to complete an automated
version of this the team will take that into consideration at that time.
There are a couple of different security risks that need to be protected against. The obvious
unauthorized users gaining access to the system. The other is due to the use of an SQL database.
SQL injections could cause huge problems with the functionality of the system. This will be
mitigated by deploying proven standards for programming that protect against such attacks.
Employing one of the team members to “attack” in a black hat kind of effort will test the security
measures.
Most software has some associated cost. EmVi is no different though many of these costs
are costs that a company using email marketing would already be incurring. The use of CDN’s
and CMS environments are common among marking email strategies. EmVi will just be
Lab 1 – EmVi Product Description
24
providing a center hub for these interfaces and an approval system. EmVi will be comprised of
all open source software, so the initial cost of the tool is minimal if any cost at all.
Some of the challenges that will be faced when building the EmVi prototype could be
disastrous and cause the team not to complete the task. The API’s between EmVi and Exact
Target (Email Deployment Company) and Drupal (CMS) could prove to be more complicated
than anticipated. That is why EmVi will simulate to a file server first and if time permits attempt
the real world implementation of the API’s. This is also the case with the CDN of choice,
Amazon. Again this can be simulated via a file server. The Rendering of test emails is probably
the most difficult task. Reaching into a client or a browser to capture images from email and
deliver them back to the tool is going to be a momentous effort. EmVi will simulate this in the
prototype by placing pre-staged images in the repository for use in the tool while the team works
the renderer in the back end. If the team can overcome all of these development challenges then
these features will be part of the prototype in their real world form.
(This space intentionally left blank.)
Lab 1 – EmVi Product Description
25
Glossary
Access Control: Security features that control who can access resources in the operating system,
selective restriction.
Administrator (Admin): Has the ability to create and remove new contributors as well as restrict
their access.
Analytics: The process of transforming data into meaningful patterns to help in the decision
making process.
API: Application Programming Interface
Approval Chain: The series of steps necessary for an email to be authorized and distributed.
Approval Tracking: Specific to a workflow, the workflow action to perform when a user sets an
approval type.
Authentication: The process of identifying an individual, usually based on a username and
password.
Azure: A Content Distribution Network (CDN), a Microsoft product that allows you to build,
deploy, and manage applications globally.
Campaign Filter: Allows campaigns to display based on criteria that are chosen by the user.
Campaign Search: Searching for the content of a campaign (content browsing).
Content Distribution Network (CDN): Or delivery network is a large system of servers that
allows for faster and more efficient delivery of content to end-users.
Contributor: Has the ability to read, write, and edit content.
Customize: Changing or altering to fit current needs.
Database: A collection of information organized in a manner which allows for efficient retrieval.
Dynamic messaging: The use of variable content to fill particular sections of an email message.
Some examples are using first name personalization or product name insertions within
the body of a message.
Drupal: A Content Management System (CMS) that allows for easy organization, management,
and publishing of content, with an endless variety of customization.
ECMS: Email Content Management System
Email Campaign: A single instance of an email sent to a list of email addresses. Campaigns
may include multiple sends and multiple messages.
Lab 1 – EmVi Product Description
26
Email Client: A computer program used to access and manage a user’s email.
Email header: The data that appears in the header of an email message, usually consisting of to
and from email addresses, email subject and IP-level tracking information.
Email Marketing: Usually done by a company to directly market a commercial message for
promotional or notification purposes to a group of consumers through the use of email.
Email Message: A single email received to an email address within a campaign. A message
contains a multipart, alternative message which includes an HTML and text file.
ESP: Email Service Provider
Exact Target: A provider of data driven marketing solutions for email content creation, list
management, etc. This company is capable of integration with CDNs.
HTML Email: A subset of HTML that is not well defined and can sometimes have differing
results depending on the email client in which it is viewed in. Some email clients do not
support HTML email at all.
Integrative: Combining or unifying.
Litmus: A company that allows for the rendering and testing of email across various email
clients. Also, email analytics, spam filter tests, and page tests can be performed.
Metadata: Descriptive data about campaigns and images that can be used to search for content.
Multipart, Alternative: An email that includes both an HTML and text version. The email client
determines which version to display.
Open Source: Computer software made available publicly and free of charge.
Outsourcing: The contracting of internal business processes to a third party organization.
Permissions: Or rights, are characteristics given by users or network administrators that prevent
or allow access to files on a computer network.
RACI Chart: Responsible, Accountable, Consulted, Informed. This chart displays the various
roles and responsibilities required in completing tasks for a project or business process.
Simple Mail Transfer Protocol (SMTP): An internet protocol for sending and receiving email
messages.
Version Control: A system to record changes that are made to a campaign. This grants the
ability to restore the campaign to a previous version if necessary.
Lab 1 – EmVi Product Description
Web Application: An application that is accessed over the internet usually through a web
browser. This allows the application to be used on multiple platforms.
Web Server: The hardware or software that helps deliver web content and can be accessed
through the internet.
Workflow: A series of connected steps to complete a process.
27
Lab 1 – EmVi Product Description
References
Balegno, S. (2011), Report: 2011 Email Marketing Benchmark Report, 2011.
Rice, J. (2012), Report: 2012 Email Marketing Benchmark Report, 6, 2012.
Schwartz, D. (2011), SOS Emarketing, ROI Comparison Across Media Channels. SOS
eMarketing, 15 Nov. 2011. Web. 9 October 2013.
Connolly, L. (2011), Report: View from the Digital Inbox 2011, 2011.
Radicati, S. (2012), Report: The Radicati Group Email Market, 2012-2016, 2012.
28