Email – Deployment Type Creation
New clients are required to complete a spreadsheet with the following information:
Deployment Type
This may be synonymous with a ‘list’ that is currently used at another ESP. At Omeda, each newsletter product will have a corresponding Product and Deployment Type. Unique deployment types are also assigned to 3rd party sends, subscription renewals, digital alerts, webinar invites, etc. Unsubscribes/Optouts are stored at the deployment type level. When creating a new deployment for sending, the first step is to declare the deployment type – prior optouts are then automatically removed from the audience list that will be used. In addition, since the Unsubscribe link is a merge variable, the Deployment Type dictates the level at which the unsubscribes will be captured and stored. At conversion time you will need to map your current permission levels to the Omeda deployment type to allow the correct loading of data.
Deployment types are listed in Email Builder and Odyssey in alphabetical order. To easily search for the desired deployment type, it is recommended that the naming convention of the deployment type should follow one of these standards:
1. Group by type of send – i.e. newsletter, events, webinars, subscriptions, etc. first, then the brand
For example:
NL-{brand abbreviation}-{newsletter name}
2. Group by brand and then the type of send
For example:
{brand abbreviation}-{type of send}-{deployment name}
Type of send could be:
NL = newsletter
MA = marketing
EV = events
SS = subscription
SU = surveys
Etc.
3. Group by brand abbreviation then deployment name
For example:
{brand abbreviation} {deployment name}
Within Email Build and Odyssey, the available deployment types will be sorted alphabetically. The determination of naming convention and standardization is extremely important to allow users to easily find the correct one.
Product Name
Depending on the abbreviation structure of the deployment type, you may want to mimic it for the Product Name. There will be a folder in Audience Builder for each newsletter product. Contained within that folder will be additional data fields such as Class (Active, Promotional, Suspend, Inactive), Promo Code, first order date and current verification date. You may prefer to not have the ‘NL’ abbreviation here since it is contained within a newsletter folder. Or, if you used additional abbreviations, you may want to spell out the name of the newsletter. We do recommend using a standard naming convention across all newsletter products.
Product Type
Newsletters should be declared as a Newsletter product. All others will be defaulted to an Email Deployment.
Omeda defines a product as something that has an actual subscription. Newsletters are a ‘product’ -> I signed up for a newsletter and you can track my source, promocode, date, etc. A magazine is a ‘product’ since the same would apply. Deployments such as 3rd party sends, webinar invites, surveys, etc. are not normally a ‘product’. They do not have subscription data since customers normally do not sign up for those types of deployments. They are sent as a by-product of another product subscription.
External Name
This is the actual deployment name that appears on the Unsubscribe page. While all the options above must be changed internally at Omeda, clients are able to change this nomenclature after the initial load of deployment types.
Email Builder -> Tools -> Opt-Out Settings
Select the correct deployment type
Change the name within the Confirm Opt-out Text box
Hit the save changes on the blue header row
Domain
Many factors come into consideration when determining the number of domains that a client may want to use. Primary consideration would be volume and cadence. To keep a domain ‘warm’, there needs to be consistent sending volumes (no severe peaks or valleys) and a steady stream of sending – ideally daily sends. If not daily, then at least multiple days/week.
Other factors to be reviewed are:
Does your company cover one distinct vertical market or multiple markets?
What is your current domain configuration?
Large sending clients at Omeda, more than 10 millions emails sent/month, may want to separate the different types of sends, using sub-domains of the client domain such as this (these need to be configured at the client, see below):
news.{clientname}.com
events.{clientname}.com
Or, use domains exclusively purchased for email sending such as:
News-{clientname}.com
Events-{clientname}.com
{clientname}http://news.com
{clientname}http://events.com
If a client covers many disparate markets and the client name ‘branding’ may not be obvious to recipients, then a sending domain per market group may be more advantageous. All content from each market group will then send from that domain, unless the volume is high enough to support the segregation of the different types of sends.
email.{marketgroupA}.com or em.{marketgroupA}.com or mail.{marketgroupA}.com
email.{marketgroupB}.com or em.{marketgroupB}.com or mail.{marketgroupB}.com
In this scenario, high volume senders may use this:
news.{marketgroupA}.com
events.{marketgroupA}.com
Clients have two options for the domain configuration:
Client will purchase a new sending domain(s) or create sub-domains. You will then point to our nameservers to allow Omeda to use it for sending. Please note that you will only point the NS record, not the A record. Detailed information can be found here
Omeda will purchase domain(s) on the client’s behalf
Designation
Each deployment type will be assigned a Designation value. This value then allows you to run segmented reporting on each Designation value. You are also able to filter on these values in the Deployment Search screen. These can be easily changed by an Omeda staff member after creation-it will then re-categorize all prior sends from that deployment type.
Options are:
Advertiser Promotion
Audience Promotion
Digital Magazine
Events
Live Conferences
Marketing
Newsletter
Other Communications
Reader Service
Research
Surveys
Third Party
Virtual Conferences
Webinar
White Papers
From Name
This is the ‘pretty’ name that will appear when a recipient sees the email in their mailbox. Providing this information initially will allow it to be entered into the Deployment Defaults and therefore pre-populated into all deployments. Even when it is pre-popped, it can always be overwritten in each individual deployment.
Mailbox
This is the information that appears before the @ in the sending domain. Clients may use differing data, based on the type of email that is being sent. There can be no spaces in this data.
For example:
news@
events@
johnsmith@
Reply to Email
Clients can store a standard ‘reply to’ email to capture any responses that a recipient may have sent using the reply-to function in their email client. If no data is entered into this field, any responses would not be retained at Omeda – they are effectively lost.
Table of Contents