2 Data Challenges to Trigger-Based Marketing
Trigger-based marketing is a well established and respected technique used by marketing practitioners to drive results. But many marketers only scratch the surface and execute simple triggers, leaving opportunities for improvement — and return on investment — on the table. Reaching the potential that trigger-based marketing programs offer means working hard to overcome several common challenges, none more important than how you make data work for you. Here are two key points to consider when preparing data for your trigger marketing programs.
1. Data latency. A big part of your success and creativity with trigger-based marketing programs is going to come from the timeliness and availability of data. Most organizations try to centralize data into one data repository in the form of a marketing data mart, or shared data warehouse. This is a common and prudent practice, just as maintaining a strong data infrastructure is critical to an organization’s success.
The challenge is that the process of data standardization, normalization and eventual migration to the database takes time. Time isn't the friend of many trigger-based marketing programs that run only on the data in the central data store. Organizations still struggle to make the right data available in a timely manner to support critical triggers.
Sadly, sometimes this latency applies to data that should be captured by marketing systems and acted upon immediately. For example, a new customer goes to your website and indicates that they're interested in product A, but they have to wait three weeks before an offer or information from product A is included in marketing messages.
2. New data sources. Closely related to latency is the challenge posed by new data coming from a new set of data sources, namely microsites, web pages and mobile sites that are designed to engage consumers in a more interactive manner. The consumer has gone multichannel, using on average almost four channels in the decision-making process with a brand.
More and more companies are responding by integrating highly customized web and mobile experiences into their marketing programs. These multichannel experiences sometimes drive customers and prospects to an interactive website where customer data can be gathered and used by marketing teams to create programs. The challenge is that this data is often on an island, sitting in a database hosted outside of the client’s IT infrastructure. This data isn't scheduled to be added as a regular update to the company’s database, so the problem goes well beyond latency. The problem is simple availability.
This issue is exacerbated by the fact that microsites, landing pages and WAP sites often drive deeper customer engagement than a client’s own corporate website, and create a customer experience where trigger-based messaging is expected by the client — but to their disappointment, is simply never fulfilled by the brand.
Fortunately, there are two ways to overcome these data challenges:
- Fight the good fight and keep the pressure on your organization’s IT infrastructure to make data more available. A helpful hint: By forecasting the value of your timely trigger-based program and building an ROI model, you'll compel C-level execs to rally behind your vision. With trigger-based marketing programs providing five times to 10 times the lift of traditional campaigns, the argument is strong.
- Consider carefully bypassing the long loop of getting data into your database by simply allowing some of the more interactional systems that your customers engage with to update unique records in your marketing engine directly and immediately. Call it the small loop. This process is nowhere near as risky as you may think. As long as you can provide a unique ID to the marketing engine, most marketing platforms worth their salt will allow you to ingest data from multiple sources, rationalize it on the fly and via the web, and execute on it immediately. Once you’ve made this “small loop cycle,” you can always use that same marketing system to update a more slowly moving database.