How about a Data Layer that somehow gets additional data on your current visitor – on the fly – without your developers having to implement anything?
Welcome to what Tealium calls “Data Layer Enrichment”. We use it e.g. for more accurate long-term metrics, Facebook Retargeting with better privacy, deciding which qualitative surveys a user gets to see, Cross-Device Tracking (limited), and it helps us knowing how many block 3rd-party cookies.
Franz’s Scenario
A user, let’s call him Franz, bought a new iPhone and visits your site in his web browser. As Franz has no cookies from previous sessions, he is regarded as a new user. Now he logs in, and his Visitor ID becomes known. Tealium iQ (the TMS) grabs that ID from the Data Layer and sends it to Tealium Audience Stream, a part of Tealium’s Customer Data Platform “Universal Data Hub” (UDH). There, “Visitor Stitching” takes place, and now we have “revived” all kinds of historically collected (or imported) user data in his Audience Stream Visitor Profile: His lifetime revenue, his gender, has he bought before, what was his last NPS vote etc.
Audience Stream now enriches that historical data with the data from his current behaviour on your site, e.g. if the user now gives you a negative NPS vote, he may join the Audience “Unhappy Customer”. If this Audience is used in a connector e.g. to Salesforce Marketing Cloud, the user’s data is is sent right there in real-time, all server-side.
So far, this is a brief recap of part 1, where I teased you with the elusive “Data Layer Enrichment” (DLE). So now let’s take a look at that in depth.
Not all execution tools (e.g. E-Mail Marketing) support server-side connectors, and even if they do, it is often more helfpul to have the data where the good old Tag Management System is operating: in the Data Layer, i.e. in the browser. That’s what Data Layer Enrichment is there for: It brings Visitor data (back) into the browser, and you can use it there just like a normal Data Layer variable (see the purple part in the diagram):
How Audience Stream works, an important part of Tealium’s Universal Data Hub, a Customer Data Platform (CDP)
We used Data Layer Enrichment for many cases. See some examples:
Example 1: Repeat Order Rate Or “How Reliable Is A Cookie For Long-Term Stuff”?
The Repeat Order Rate is an important metric. It tells us how many of the Orders came from people who have ordered for at least the second time. So “45% Repeat Orders” means that 45% of all Orders came from users who had ordered in the past.
With traditional Analytics tracking, you are relying on Cookies. Cookies however, are useless for these kinds of long-term metrics in a cross-device world. So we use Data Layer Enrichment to send a simple Audience Stream Attribute called “Visitor Lifetime Order Count” into the browser as soon as the user has made himself known. This way, we know at the point when we track his order whether this user is buying for the first or second or third or n-th time. If it is not his first order, we can track an additional metric to count a “Repeat Order” to Google and Adobe Analytics.
A Tealium iQ (TMS) Extension where the Visitor Lifetime Order Count (and other attributes) from Audience Stream, as received via Data Layer Enrichment, is transferred into a normal Data Layer variable “user_ordercount”.
As we didn’t have Audience Stream from the beginning, Audience Stream’s count of orders was of course not in sync with reality. So before we could use this sensibly for the first time, we imported some User’s attributes like his current Order Count etc. via Omnichannel Imports (see part 1).
So how big is the difference between the three Repeat Order Rates: the bad old Cookie-based Rate, the stitched Audience-Stream-based Rate, and the “real” Repeat Order Rate from our shop system?
Let’s look at Audience Stream vs. Adobe’s traditional Cookie-based method (which generates the “Return/Loyal Customers” dimension on the basis of which you can create a cookie-based Repeat Order Rate, here called “% Orders by Return/Loyal Customers”): Looking at the Cookie only, the Repeat Order Rate stagnates at a low level, whereas the Audience-Stream-based “Stitched” Rate tells a much better story. So counting repeat buyers based on a Cookie counting seems way off indeed, if not useless.
Repeat Order Rate based on Audience Stream Enrichment (blue) vs. Cookie-based. We started using Audience Stream in August and did the first omnichannel import with historical user data from our CRM (Salesforce) in October (Screenshot from Adobe Analytics)
Comparing the Audience-Stream-based Rate with the real Repeat Order Rate according to our shop system, we are still about 10 percent below the real rate which is mainly due to the “caveats” at the end of this article. But even so, the stitched Repeat Order Rate is a much better metric for a Marketing Manager who asks himself which channels are mainly generating new customers vs. re-attracting existing ones: Not only is it better because it is closer to reality, but also because the Marketer/Category Manager can use the metric right where he does his usual analysis anyway – in the Web Analytics Tool (Adobe Analytics).
Similar examples were: Stitched Gender / Stitched Zip Code / Stitched Lifetime Revenue / Returning vs. New Visitor / Existing Newsletter Subscriber… In all these cases, the Audience-Stream-based Stitching provides better coverage and thus makes the Analytics data a lot richer.
Example 2: Cross-Device / Cross-Browser Usage
Another example where the traditional tracking cookie is useless is cross-device usage, like in our scenario at the beginning. Audience Stream, by stitching the browsers and devices a user has used in the past and sending them back into your browser, is capable of giving you at least a hint on whether someone has been on several devices before.
Data Layer Enrichment Is Not 100% Real-Time
However – and this is my main issue with Data Layer Enrichment – it is not really real-time! So from the moment a user becomes “known” through an ID (e.g. in our scenario at the beginning, after his login), the Stitching within Audience Stream (see part 1) happens in real-time, and all historical user attributes are available for rules and server-side connectors right away. However, to get the data back into the browser, you need to wait another 2 Page Views. For the user from our scenario, this means he would have to view at least two more pages after the Page View which sent his identifier (the page after successfully logging in) until his stitched profile becomes available in the browser.
So Data Layer Enrichment will not work for all of your users even if they become identifiable during their Visits. How good the coverage will be depends on the Median Visit Depth of your Visitors and how often they are identifiable (e.g. log in). The sooner the Visitor becomes identifiables in his Visit, the sooner the full historical dataset becomes available via DLE. I call this state “fully enriched” vs. “partially enriched”. “Partially enriched” would contain only data particular to a browser cookie history, e.g. the number of previous Visits in this browser and the products viewed in this browser, whereas “fully enriched” gets you all the data from previous Visits in other browsers, omnichannel imports etc.
That is why DLE is great for additional info on everything that happens late in the funnel (e.g. to place an order on our site, you need to authenticate on the first checkout step, and then there at least 3 more Page Views until the Order happens, so an Order is very likely to happen in a “fully enriched” state). For stuff before the Order, it becomes the flakier, the earlier in the funnel.
But of course, we can and should still look for patterns and tendencies before that last funnel step. So let’s get back to our cross-device example.
If you are using several IDs to identify a user (e.g. an email hash or a customer ID, and both are not always available together), you can rely on Audience Stream Visitor Stitching to get that one supported ID you are using in your Google Analytics (GA) User-ID-based View. If that View uses “Session Unification“, it will lead to the data being reported as if Data Layer Enrichment had happened on the first Page View of a Session. Altogether this will give you a better idea about cross-device effects, although it will still fall short of the holy grail of true cross-device tracking).
Device Overlap Report in Google Analytics
Naturally, other tools can also benefit from this. Adobe, which does not offer Visitor-ID-based backstitching of Sessions in its lower-priced offerings, can still get the info whether a user has used multiple devices or browsers in the past and use it as a basis for Metrics like “% Orders by Users with more than 1 Device or Browser used”:
% of Orders by Category by Users who have used more than one device (Screenshot Adobe Analytics)
We see that some categories like Beauty and Health (“Schönheit & Gesundheit”) tend to have less buyers who have had a cross-device journey (about 17%), whereas users buying in Sports, Fashion (“Mode”) and Media tend to surf your website on different devices before ordering.
Example 3: Track User Propensities To Facebook Without Sharing Your Users’ Email with Facebook
Facebook Retargeting is quite powerful, and it gets even mightier when you enrich Facebook’s data with your own first-party data. You can do that e.g. via the Facebook Retargeting Pixel on your website or/and via Facebook’s server-side API.
Data to Facebook’s API can be delivered through an Audience Stream Connector (see part 1), but there is one big issue with this: To do the matching with its users, Facebook requires you to use the email address of the user as the identifier! This way, Facebook gets data about users that are not even registered at Facebook (sort of a bulk version of people importing their address books to Facebook). Out of respect for users’ privacy, this is something which we did not want to do.
The Retargeting Pixel instead runs in the browser through a normal JS Tag and it does not need the user’s email address. So we used DLE to fill things like “User’s Favorite Categories/Brands/etc.” or Propensity Scores back into the browser, and from there to the Facebook Tag via the normal Mapping table in Tealium iQ.
Audience Stream properties retrieved via Data Layer Enrichment become part of the regular Facebook Retargeting Tag (Screenshot Tealium iQ). Yes, the truncation makes differentiating the Attribute labels impossible in this screenshot, but those are three different Product Scorings indeed.
Example 4: How Many People Really Block 3rd-Party Cookies?
In our last example, we leverage Audience Stream to do something a bit more creative. Ever since I started doing “Web Analytics” in 2007, people were talking about how bad it is to use 3rd-party Cookies, as more and more browsers supposedly blocked those because they allow to follow people across several domains. Still, many Display Advertising networks heavily rely on 3rd-party Cookies, and some sites still need 3rd-party Cookies to track a user across main domains.
So knowing more about 3rd-party Cookie blockers among your user base will help you understand e.g. how effective your Programmatic Advertising can be. However, with JavaScript (which is what a Tag Management System usually executes) alone, you cannot read a Cookie that is set to a different domain (= a 3rd-party Cookie) nor set a Cookie to a third-party domain, so it is impossible with JavaScript alone to verify whether a user allows 3rd-party Cookies.
Tealium’s UDH Tag also tries to set a third-party Cookie to allow for cross-domain tracking. The value of this cookie can be retrieved in Audience Stream via the default Attribute “tealium_thirdparty_visitor_id”. This attribute will only be set for those users who have 3rd-party Cookies enabled. With a rule in Audience Stream based on this attribute, and with Data Layer Enrichment which pushes that attribute back into the browser, we were able to quantify for our site how many are really blocking 3rd-party Cookies.
We simply divide the number of those Visits where 3rd-party Cookies were blocked (=where the attribute was not set) by the number of Visits where we can be certain that Data Layer Enrichment has happened (as this won’t be the case until usually the 3rd Page View for new users, see above), and we get data like the following:
Browser Types by Device, ordered by percentage of traffic, and how often they block 3rd-party Cookies (Screenshot Adobe Analytics)
Even in the last 2 months only, we see quite a rise in 3rd-party Cookie blocking for Apple (=Safari) users. This is probably due to more and more users updating to iOS 11 which has “Intelligent Tracking Prevention” enabled by default (Screenshot Adobe Analytics).
Caveats of Data Layer Enrichment
So much for examples of where Data Layer Enrichment can become very useful. However, there are also some more caveats to keep in mind:
- Restrict Data Layer Enrichment to the Attributes you really need in the browser. Every Attribute in Audience Stream has a checkbox to mark it as “restricted” which prevents it from being used for Data Layer Enrichment. You thus reduce the data being exchanged between browser and UDH, as your localStorage otherwise very soon becomes completely swamped with Audience Stream Attributes. I would actually like Tealium to have Data Layer Enrichment deactivated as the default for new Attributes.
- Data Layer Enrichment requires localStorage which is blocked if the user is browsing in Safari Private Mode for example and has other downsides (but many more upsides, see my article on localStorage vs. Cookies).
- The Tealium infrastructure has had some issues lately, especially the part responsible for Data Layer Enrichment has broken down a couple of times this year, a small part of visitor profiles became corrupted at some point etc… Tealium is getting better here, but it is of course absolutely crucial as lost data cannot be retrieved, and a broken user history cannot be repaired.
- Data Layer Enrichment costs additional Server Calls on your Tealium UDH license. How much depends on your Data Layer Enrichment setting in your Tealium Collect Tag in iQ. You can choose between “Frequent”, “Infrequent” (=once per Visit), and “Never”. However, anything apart from “Frequent” makes little sense unless almost all of your users are already known on the first Page View (Tealium, please correct me here, I’m not 100% sure on this).
- As with anything regarding Audience Stream, it is only possible to enrich Visitor data. So you cannot use that to enrich your Data Layer’s product data or blog article data. For these purposes, there is Tealium’s “Hosted Data Layer” aka “Dynamic Data Layer”). That is a whole different world though, and you really need to be careful when implementing it (see the article for more details).
Part 3 coming up soon: Server-Side Tracking!
Part 3 will be on a topic that clearly seems to be the future of tracking: Server-Side Tracking for Adobe Analytics or Google Analytics with Tealium Universal Data Hub. Here Tealium promises server-side capabilities without giving up the flexibility of your Tag Management System. Quite a promise… Let’s see how Tealium’s offer fares here.
Missed the first part of the series? Check out Part I: How We Used Visitor Stitching and Salesforce Connector
Leave a Reply