The rise of marketing tech has brought forth countless new technological solutions. But their implementation has been increasingly reliant on quality data layers.
I mentioned data layers in a previous article: But just the same, let’s do a brief review of what data layers are, and the purpose behind them.
What are data layers?
A data layer is a digital container of information that is communicated from one software or cloud application to another. The solutions that use the information are considered a technology stack (for marketers, of course, a marketing tech or martech stack).
A variety of marketing tech applications rely on data layers. Analytics solutions, for example, use tag managers, which deploy data layers to simplifying tagging a website. This keeps tags in sync with website revisions to functioning media and links meant to measured, such as replaced videos, whitepapers, and updated links.
Programmatic advertising also relies on data layers through header bidders (I explained header bidders here).
A typical data layer would start with a script tag in a HTML file like this:
The brackets on line 11 typically hold a JSON array, a JavaScript object text string, to pass the information. Arrays in programming language are used to contain a name:value pair, a string of associated text that reflects what information is being collected, and thus what gets shared through a JSON format. The name is an identifier, while the value is information that gets assigned to that identifier. All those items are placed in between the brackets in the code.
So a typical simple array would look like this:
In this example, the numbers are an identifier, and clothing items are values for those identifiers. Many solutions have actual names instead of numbers, a reserved word that cannot be used as a regular variable name in programming. In Google Tag Manager, for example, ‘transactionId’ is a reserved word that must be used for an eCommerce variable identifier.
So what should marketers verify when planning a data layer? What makes the data suitable for a data layer?
Planning a data layer
For starters, map out the complexity you need in terms of tracking the following information:
- Product or service description
- Webpage/app/user interface, and
- Details of a signed in user
The functional magic of JavaScript (and other object-oriented programming languages) is that objects can be placed within an array – kind of an array within an array. That makes it possible to have product/service, webpage, and user attributes aligned against the information that can be used.
These data protocols allow marketers to set granular control of information related to customer activity on a website, app, or user interface on a device. Originally much of this was designed for website activity, but marketers can work with developers establishing what kinds of identifier:value pairs are possible against the products and services offered. Pairs can be numerous and varied, consisting of things like e-commerce transaction information, web behavioral data, and mobile application usage.
Data layers offer marketers control and flexibility over a marketing tech stack, organizing how information is curated throughout the stack.
Discussions on data layers should also raise conversations about where the information is stored – a key step in maintaining privacy.
The privacy question
The data layer can reveal where information leaks can occur, or where profiles from personal identifiable information can be suddenly created, since values can store numbers and many personal identifiable information elements are a number.
A great example of privacy protection in a data layer is User IDs, an identity protocol (which I discussed here). User ID represents a signed-in online customer with an account. The purpose behind IDs is to avoid personal identifiable information from appearing in the analytic reports or within exported data. Every analytics platform has a variation of a User ID — Google Analytics and Piwik both offer User IDs, while Adobe Analytics offers a similar system called
VisitorID.
The value of open source
Marketers should also work with solutions that incorporate open source practices. Open source is meant to share and research programming ideas, and programmers have developed solutions for data transfer issues. Thus picking solutions supported by a large developer community can save time in finding technical solutions to array errors and concerns. This is especially valuable when in-house technical teams are small and constantly pressured for time.
A data layer ultimately unites marketing and technical teams on a shared outlook: to think about customer interaction with applications through shared definitions of data. That unity can make establishing a cohesive customer experience across websites, apps, and devices much easier.
