Using WhatCounts Publicaster Edition To Send Transactional s

Transcription

1 Using WhatCounts Publicaster Edition To Send Transactional s 1 DEFINITION Transactional by definition is any message in which the primary purpose facilitates an already agreed-upon transaction or updates a customer about an ongoing transaction. If the message contains only transactional or relationship content, then its primary purpose is to facilitate a relationship established by the transaction. Because of this distinction, transactional is exempt from most provisions of the CAN-SPAM Act. Transactional includes any triggered by a user s interaction with a web application, including: signups, password changes, subscription renewal or expiration notices, notifications, friend or follower requests etc. These s typically contain information a user wants or needs. There is no limit to the number of transactional s one could define. 2 SHOULD TRANSACTIONAL S BE SENT THROUGH AN SERVICE PROVIDER (ESP)? It s true that almost every website, CRM and e-commerce product have support for sending transactional s, and in most cases this is out-of-the-box functionality. So why spend extra time and send them through an ESP? 1. Tracking. Using an (ESP) for transactional s allows you to view reporting on all aspects of your transactional messages just like you have for marketing messages. Opens, clicks, engagement -- any metric that is recorded by your ESP for marketing messages is available for transactional messages. 2. Everything in one place: templates can be modified by people who know how to design templates using the same platform tools they are used to using for editing. The template content is not hard coded in some proprietary developer code or platform that only a programmer knows how to access. A transactional can be just as effective, or even more so, than a strictly commercial or marketing Testing: Any tools provided by your ESP for testing are available for use with your transactional messages. 4. Same IP Infrastructure: Optimize your delivery by sending messages over the same IP addresses that you use to send your marketing messages. Most ESPs will also handle all your bounce processing for your transactional messages automatically; if your ESP doesn t, you may want to have a conversation with them and ask, Why not?

2 3 ARE TRANSACTIONAL S SUPPORTED BY WHATCOUNTS PUBLICASTER EDITION? Yes, transactional s are fully supported by WhatCounts Publicaster Edition and do not require an extensive amount of work to setup. Once prepared, many aspects of the transactional campaign can be modified by anyone with access to the WhatCounts Publicaster Edition platform and will not necessarily require development time from a programmer. 4 HOW DO WE SETUP A TRANSACTIONAL IN WHATCOUNTS PUBLICASTER EDITION? The following instructions can be used to demonstrate how one might go about setting up a transactional message in WhatCounts Publicaster Edition. 4.1 DEFINE WHAT TRANSACTIONAL MESSAGES YOU WANT TO SEND Start by determining what message you want to start sending. Create a list of all the different elements in each message that are dynamic, i.e. that would change from recipient to recipient each time they receive this SET UP A SUBACCOUNT DEDICATED TO TRANSACTIONAL S. We ask that all transactional s be sent out of a dedicated account. We do this for a couple of reasons. 1. Given that transactional messages are not promotional, they are not subject to CAN-SPAM regulations. Therefore, we can disable the requirement that these messages must contain a working opt out link because you don t want your subscribers to opt out of transactional messages and potentially miss future messages you send to them that they are expecting. 2. You want to send transactional messages to any user regardless of whether they are signed up in your main marketing list or not, and you want to be able to send to them even if they have previously opted out of your marketing s. By setting up a dedicated sub account for these messages, the subscribers are physically separate, meaning opt outs and unsubscribes in your main account will not affect the ability of these subscribers to receive transactional messages. 4.3 MAILING LIST SETUP Create one or more new mailing lists in your transactional account. The first decision to make is whether you need to create multiple lists, one for each transactional message template, or if you can use a single list with multiple attributes. There isn t necessarily a right or wrong way to answer this question. The mailing list is used as a holding ground for the subscriber s data so it can be inserted into the message via personalization variables.

3 If, for example, one of my transactional s was a Password Reset that is sent to website users when they can t remember their passwords, the dynamic fields I might wish to include could look something like this: Here we ve defined three custom fields: First name, the current date the action was requested, and a space for the reset password URL for the user to click. Repeat this process of creating lists and/or adding custom fields to a single list for each dynamic field in each transactional you wish to set up CREATIVES The next step is to define the creative template for each transactional message you wish to send. This is done in the Creative Manager and is performed just like you would create any other message you send in Publicaster. Copy or write the necessary HTML template code in the editor and substitute in the dynamic fields using personalization snippets. Using our reset password example, our template might look like the following:

4 Here you can see that we ve substituted the dynamic portions of the with personalization snippets that will pull content from the mailing list we created in 4.3. The password reset link has also been configured to use a snippet for the hyperlink.

5 Continue editing the HTML, Text & Mobile versions of your template until everything in the is the way that it needs to be. Repeat these steps for each different transactional that you wish to configure. 4.5 PUTTING IT ALL TOGETHER Once you ve defined the different types of transactional messages you wish to send, created the mailing list to store the personalization variables and created the templates with personalization variables, it s time to put this all together, to be able to associate the subscriber being added to a list and the sending of the template. In WhatCounts Publicaster Edition, the way this is accomplished is through Opt-In Forms. Opt-In Forms are the mechanism that allows a user to be added to a list and trigger an immediate one-time to that subscriber that is both track-able and personalize-able. Opt-In Forms are used behind-the-scenes only. The end-user / recipient will never see or interact with the actual Opt-In Form. Instead, we use HTTP POST in order to send the necessary data elements to the unique Opt-In Form URL for that form (which means the data is sent into WhatCounts Publicaster Edition, as well). Before we dig into those details let s look at setting up the Opt-In Form.

6 4.6 OPT-IN FORMS Creating an Opt-In Form in WhatCounts Publicaster Edition will walk you through a short wizard, asking you for various pieces of information along the way. The first important step is to make sure you indicate on Step 1 that this form is a Notified Single Opt-in form. This selection is critical because this is what allows you to configure, and WhatCounts Publicaster Edition to ultimately send, an to that user after the data has been received. On Step 2 you ll be asked to select the list to which the user should be added. This is the list that you created previously in Section 4.3. In this case, when we re working with transactional s, the list is simply a place to store the data for the subscriber, so it can be inserted into the for personalization purposes. Additionally on Step 2 you are asked to choose from a selection of redirection options. Normally if the user is filling out a physical form this is where the user would be redirected after the form is submitted. For the purposes of a transactional where there is no direct interaction with the form by the user, choose Transactional , No Redirect Required from the drop-down menu. Lastly on Step 2, choose the confirmation to send to the user. This is the creative that we designed for this transactional in Section 4.4.

7 On Step 3 of the Opt-In Form Builder you ll be asked to map all the fields from the list that should be included on the form. Choose all the fields from the list that you created that are necessary for personalization in the creative. None of the selections on Step 3 are essential for Transactional s other than the Included checkbox on the left of each row. This selection tells the Opt-In Form processor what fields are expected for a form and how the fields from the form map to fields in the mailing list.

8 When all the fields have been filled in with values on this screen, press the Finished button, and proceed to the final page of the wizard. The final page shows the sample HTML code for this form. Normally you would take this and make some cosmetic changes and paste it to a page on your website. But since this is for a transactional , we re interested instead in the information shown on the right, in the Integration Details section. Here we see two important pieces of information: 1. POST URL This is a unique URL that identifies the account/form that was just built. 2. Data Field Mappings This section shows all the fields that were just mapped on Step 3, and it shows what the name those fields should be called in the form post. Here we see that the field FirstName that we included on the form is named field6. So when the form data is submitted it will be submitted as field6 and that will map the value in that field to the FirstName field in the list. 4.7 BUILDING AN INLINE FORM POST As mentioned previously, the way that the message is triggered to the recipient is via a HTTP POST to the Opt-In Form Post URL that was previously discussed. Every modern day programming language supports the ability to perform an inline HTTP post. Included below are some links to show examples of performing such posts in various modern day programming languages: Java: C#: VB.Net: PHP: Python: Ruby: JavaScript:

9 This is not a definitive list of links, but we hope it services as a reference to support the notion that this programming is easily doable in many different programming languages, and to illustrate that this feature isn t limited to use by a certain subset of technologies. When the data is posted to the custom HTTP POST URL, it must be formatted just as if it was an HTML form that was being submitted. This includes ensuring the POST request has the correct MIME type, and that the data is formatted and encoded correctly as name/value pairs. More information about HTTP POST data can be found here: You can even test your configuration right from within the platform, using the Opt-In Form preview feature. Here you can manually enter in sample data and submit the form to see what the end result will look like. If this has been done correctly, you ll be well on your way to sending real-time personalize-able, trackable transactional messages in no time at all. 5 FREQUENTLY ASKED QUESTIONS. Q: Do I need to implement the WhatCounts Publicaster Edition API to send transactional s through Publicaster? A: No. Instead of using the API, this feature is implemented using WhatCounts Publicaster Edition Opt-In Forms. WhatCounts Publicaster Edition Opt-In Forms already offer all the capabilities required to programmatically implement and support transactional s so additional, duplicate technology has not been added to the API to support this process nor is it necessary. Q: Are transactional s sent via WhatCounts Publicaster Edition deployed in real-time?

10 A: Yes, these s are sent in real time. Q: Are Publicaster Transactional s personalize-able and trackable? A: Yes, they are trackable. Any tracking and reporting feature that can be applied to a marketing message sent via WhatCounts Publicaster Edition is applied to a transactional as well. Q: Are there any limits to the number of transactional message campaigns that can be created or limit on the number of s they can send? A: No, there are no limits at this time. Each sent counts towards your monthly/annual allotment of allowed s. Q: Does the Opt-In POST URL support A: WhatCounts Publicaster Edition maintains dozens of different click-through URLs. Not all of these URLs support However, if this is a feature you require your Strategic Account Manager / Technical Account Manager can provide you with necessary instructions for using with your transactional s. Q: Does the HTTP POST require any type of authentication? A: No, each POST URL is unique and the query string of the URL includes all the information necessary to identify a specific account and Opt-In Form. Q: Do I need to include working Opt-Out links in my transactional creatives? A: No. Because these s are transactional and not marketing related they do not fall under CAN- SPAM compliance. It will actually work against you to include Opt-Out links in transactional s because this could prevent the user from receiving other additional messages in the future. Q: What about the physical mailing address? A: As with the Opt-Out link, including a physical mailing address is not necessary, because the message is not required to be CAN-SPAM compliant. If you have concerns about the Canadian Anti-Spam Law (CASL), please contact our delivery team at delivery@whatcounts.com. Q: Can WhatCounts Publicaster Edition send transactional messages to a batch of subscribers on a set schedule instead of one-at-a-time to individual subscribers?

11 A: Yes, but the implementation details will differ from what is laid out in this document. If you do not wish to send the s in real-time and instead would like to send the s in bulk at set intervals throughout the day, then you would follow all the same steps laid out above with the exception of creating an Opt-In Form. Instead of using an Opt-In Form, you would create a segmentation in the segmentation manager to somehow target the subscribers who should receive the specified , and then create a Time-based Auto-Response Campaign to check for new subscribers to receive that at specific frequencies. This approach requires that you use some method to import the subscribers in bulk, which may include some work implementing methods of our API. Q: Couldn t you just use a time-based Auto-Response Campaign to send all transactional messages? Is the Opt-In Form method described here really necessary? What are the pros and cons of each method? A: Yes, you could use a time-based Auto-Response-Campaign (ARC) to send a transactional message instead of using the Opt-In Form approach laid out in this document. However the solution in this document that describes how to perform this functionality has a number of advantages over using a time-based ARC. Namely: 1. The s are sent immediately and there is no delay. The minimum execution schedule for a time-based ARC is 15 minutes. 2. The Opt-In Form approach handles adding the user to the list or updating his or her existing data in the list. There is no additional work that must be performed to have the user added to a list. 3. By default, time-based auto response campaigns will not send the same to the same subscriber twice, whereas the Opt-In Form solution doesn t care how many times the user has received the specified . This makes it easier to implement campaigns like order / shipping confirmation, password reminders, etc., that can happen over and over repeatedly for the same subscriber. 4. Using the Opt-In Form method described in this document, you ll find that reporting on your transactional s is much easier to digest. With a time-based Auto Response Campaign each time the schedule executes a new campaign distribution record is created in reporting. Often, time-based Auto Response Campaigns send to very small numbers of subscribers, if any at all, and this quickly creates a large amount of distribution reports in reporting. Using the Opt-In Form approach described in this document, reporting is aggregated into the same campaign distribution, and that campaign distribution only changes if significant edits are made to the Opt-In Form details in the wizard. But even then, you are only dealing with a small number of campaign distributions instead of an enormous number of distributions generated by a time-base Auto Response Campaign. 5. Time-based auto response campaigns work well for transactional messages that are processed in bulk, for which time is not of the essence when sending the message. If your internal systems processed shipping notifications once per day, then it would probably be more suitable to send that data to WhatCounts Publicaster Edition in one import call and have a time-based Auto Response Campaign send out that campaign distribution on a set schedule. This would be opposed to having your automated process iterate through your data one subscriber at a time sending an HTTP POST to a URL.

12 Q: How should I structure my creative / mailing list field definition for an that contains a large amount of dynamic data, such as an order confirmation ? A: For s that are highly dynamic, we recommend (and have had great success with clients) that users create only a couple of text fields in their list named body1, body2, body3, bodyx all with the max size of 4,000 characters. Then, they send over the pre-formatted HTML content for each of those fields, using as many fields as necessary to display the preformatted dynamic data. The template for these transactional messages often looks just like this: [~Body1~][~Body2~][~Body3~][~Body4~][~Body5~]... Q: Do WhatCounts Publicaster Edition Opt-In Forms support your Relational Database Feature? A: At this time they do not. WhatCounts Publicaster Edition Opt-In Forms can only add data directly to a mailing list as opposed to a Relational Database data table list. Q: Do WhatCounts Publicaster Edition Opt-In Forms support mailing lists with Primary Key other than ? A: No. Currently, these forms only support mailing lists with an primary key.