In the first blog of this series, we recognized the motivation for sharing data effectively and also introduced a framework that Advertisers could apply to manage the process. In a nutshell, the framework requires advertisers to understand their data, the various sources and the impact of each data set or field from a marketing/advertising perspective. Let’s explore the data sources/ingestion aspect of the framework in more detail in this post.
For obvious reasons, most digital marketing channels are largely interested in two blocks of first party data: User interaction data (what products/categories are of interest to a user?) and the product catalog (what is the advertiser selling?). Both blocks can be used in isolation but are best used in conjunction to enable meaningful one-to-one conversations (customized messaging) with end users.
1. User interaction data: Sourced almost exclusively from the website, this block of data is extremely crucial for targeted marketing channels like retargeting. Data is ingested from the website using some form of affiliate tags (parameterized, DOM scraping, hybrid etc.). These tags are also used for user tracking (cookies). Off late, this block of data is also expected to include CRM data for users who are registered on the website (anonymized/aggregated data) to build richer user profiles that can be used for more effective marketing. This means that existing linkages between back-end systems like CRM and CMS need to be more fluid or there should be support for off-line exchange of data normalized on User IDs (cookie, CRM ID).
While cleaner ingestion methods are not expected any time soon for this data block, Advertisers should address the following concerns:
- Ensure data sufficiency and accuracy by cleanly bridging back-end systems and providing a flexible interface for sharing data through tags on the website
- Force affiliates to engineer their tags for minimal impact on user experience (advisable to occasionally monitor latency & design of these tags)
2. Product Catalog data: The scope of catalog data is also being constantly redefined. Advertisers have every incentive to include information on special offers, channel specific images etc. along with the regular payload (list of products). Sharing this block of data is a more straightforward instance of systems-integration (between Inventory Mgmt. Systems & affiliates’ data storage systems). Rather, it would have been so if there were homogeneity in the technology/product stack used by different advertisers. To mitigate long, drawn-out manual server-to-server integrations, historically, most ad-tech companies chose to scale faster by using a relatively ‘sub-optimal’ integration method – ingesting XML/text files at some given frequency. This was great in the short run, but issues like discrepancy between website information and marketing messages (difference in prices, products being out of stock etc.) are being noticed in such instances. These kind of issues are best avoided by Advertisers interested in safe-guarding their brands and the experience they offer their customers (and not just on the website!). The problems are compounded for marketplace websites where different vendors could be following different update cycles for their inventory. So, if you are an advertiser you should:
- Invest in technology to disseminate catalog data in almost real-time: the good news is that most open-source/commercial components support programmatic or rule based export & publishing of data. Utilizing these features is the next best thing to having a clean web-service (API – interface) based exchange of data.
- Build latency expectations for ingestion with affiliates and have clear SLAs defined for freshness of data.
The issues or recommendations highlighted in this post are not meant to be exhaustive and would have been part of the natural outcome of a data dictionary building exercise.
Clearly, both affiliates and advertisers have to work their way towards exchanging data more effectively to get the best results for everyone. While getting close to the ideal scenario may be difficult without standards in place, there are 3rd party solution providers who are trying to bridge this gap. In the next post, we will take a look at some of these solutions and how they stack up in different scenarios. As always, we would love to hear your take on this. So, please drop a comment or write to us at firstname.lastname@example.org.