Let’s Geek out on Unica! Best Practices Blog post: Unica and Email Service Provider (ESP) integration.
I think 2020 will be shaping up to be the year where everyone starts to realize they have too much tooling to manage in their martech stacks. I have been getting many requests lately around best practices for getting tools to work together or to provide clarity about what function should be performed in which tool in the stack.
Recently, one of our banking customers reached out for some advice. They have outgrown their current email service provider, replacing them with a larger enterprise-grade email engine. They hit me with two questions:
- What are the best practices around integrating our new ESP and Unica?
- How do we architect the integration to get the most out of both platforms?
The first question is pretty straightforward, as Unica was designed to integrate with any ESP. With the release of Unica – version 12 later this year, it will be even easier with Unica Link (more information in a future post) to achieve seamless integration.
The second question is endemic of my opening prediction – confusion on the part of marketers about “what gets done where” because of the proliferation of tooling. Just because we can do segmentation or A/B testing in a given solution doesn’t mean we should. The answer also requires an understanding of the functionality in the context- how a customer is set up operationally. There’s no one right solution.
So on to the answers:
Diagram 1 below shows what we call the Unica to ESP “return trip” integration. Step one is to generate the email records to be sent to the ESP as a result of a flowchart run in an output list. This is specified in the mail list process box in Unica.
After the records are delivered to the ESP (via an API or FTP, etc.) Unica writes those same records to a Contact History table. This system of record information is critical in the age of GDPR and CCPA. The important part is designing the right campaign identifiers (shown in the red box) into the output spec and Contact History so that you can line it with the email disposition data that comes back from the ESP.
We recommend adding identifiers for standard views in existing marketing dashboards (orange box). Typically these are sent from Unica so that the granular real-time reports hosted on the ESP platform can be rolled up, sliced and diced using the same attributes as existing dashboards.
After that comes the identifier for which we require a creative template to use for the mailing (yellow box). Lastly, we recommend writing the values for any personalization fields that are used for delivering dynamic content in the ESP platform (orange box). These fields map to the different zones in the email template where dynamic content will be served.
Any enterprise-grade ESP is able to ingest data from the mail file or API call. The ESP joins the contact list to the email template and the personalization fields to execute the mailing. Besides deliverability, the critical role of the ESP(from an enterprise perspective)is to be able to send email dispositions with the same campaign identifiers (red box) as the input data. This helps in writing the dispositions to Contact History for reporting, analytics, and compliance.
This answers the first question about how to integrate Unica with a new ESP. As I mentioned above, the second question, “what to do where” is a little challenging to answer. That said, I always default to the “DNA” test as a starting point.
Diagram 3 below shows some thoughts on what is core to the DNA of each platform.
Things like a system of record data across all channels, audience management, and sophisticated segmentation are core to the DNA of Unica. Deliverability, management of personalization, email content management, and creative testing are in the core DNA of most ESPs.
Key considerations that we always consider with our customers when designing ESP integrations are:
- Deciding the fields to carry in the email output file from Unica, to align reporting views between marketing dashboards and real-time reports in the ESP.
- Determining the process for loading, managing, and maintaining dynamic content identifiers and the content itself.
- Having a deliberate strategy for the containerization of dynamic content that is at a manageable level from a production and maintenance standpoint.
Lastly, make it a practice to avoid frankencampaign at all costs.
Frankencampaign is when campaigns are executed without aligning standard campaign identifiers across channel delivery platforms. We see situations where a channel platform (email, realtime, social) gets set up as a headless system and isn’t integrated for campaign execution. This results in, frankencampaign. The messages are reaching customers across channels with different campaign identifiers, touch rules, and audience definitions — not a great customer experience.
So let’s make 2020 the year of genuinely making tooling in martech stacks work together and think strategically about “what to do where.” You’ll get better business value out of your stack, and my prediction will be proven to be true.