“Data Layer on the fly”

If you have ever worked with a marketer who listens to what’s fashionable, or if you read any digital marketing related blogs, you have heard of the concept of the Data Layer. It is a construct belonging onto each of the pages of your web site, and it is supposed to surface information to the browser so that your friendly Marketer can use the data in any tool she needs.

So far so good. I personally think this is a good idea, especially when used with a tag management solution. I would always aim for a complete Data Layer.

There are a couple of issues with Data Layers, of course, nothing comes for free.

One is that if you populate your data layer server-side, pages can not be cached aggressively, depending on what data you put into the data layer.

Think of a standard product detail page.

Data such as the product SKU, product name or even poduct price are relatively static, but if your data layer contains product stock or availability, you have a very dynamic page on your hands.

This has a direct impact on the cost of hardware needed to serve that page, so you’d probably not populate any dynamic data into the data layer.

But… but… we NEED it!

From the perspective of the analyst or as someone who uses a testing or targeting tool, the earlier the data is available the better. Early as in:

• During page load — this is where tools like Adobe Target would want you to expose data. That way they can make decisions and modify the DOM accordingly (for testing, targeting or personalisation) before the visitor sees anything. No flicker.
• Right after page load — this is ok for analytics tools. You’d usually want those to fire their tracking calls as soon as possible after page load. The rule: give the user what she wants first, then care about your marketing needs. Don’t slow the site down.
• After some additional content has been loaded using AJAX — this is essentially too late. The risk is too high that by this time, the visitor has moved on.

If you ask your friendly marketer, she’ll tell you that having all data available during page load would be ideal, but that she could live with right after page load if that’s all you can do.

The third case is not an option really, except in one specific case which I’ll get to, later.

Caching & Backends

Unfortunately, the third case is the one that the content management system people will favour. It allows them to cache most of their content and build web apps that do a lot of the work in the browser.

And that’s ok.

The difficult cases are those where multiple systems interact. Say a site that uses a shopping module for products, carts and purchases. The site serves templates, which then use Javascript to get product, cart and other details from the shop backend.

If you want to track the content of the shopping cart, you have to wait for those Javascript calls to come back with results. By that time, the visitor might have moved on to the next page.

Very difficult to track reliably.

At the “client-side” end of the spectrum lie web apps based on AngularJS and similar frameworks. They sometimes do everything in Javascript, with the occasional calls to some web service to get or submit some data.

Those are actually not that complicated, but they have to be tagged manually because there is no page load (except one). In web apps like this, everything is option 3 from above!

I guess since the developer decided to leave a couple of fundamental concepts behind (a web page, a View (iOS), an Activity (Android)), they’re on their own with tagging as well. But I am fully prepared to admit that I don’t know enough about Angular to make a judgment.

Split it up!

Back to web sites that use a mixture of server- and client-side logic with a sprinkle of AJAX. What can you do if your developers or IT refuse to build anything dynamic into the site? “Sorry mate, it’ll slow down the site too much. Nothing I can do.”

The question at that point is: how much control do you have over the templates in your CMS?

If you can get something into the templates, you can get at least the static part of your data layer in. Things like “this is a product details page template, so let’s put something in that says pageInfo.pageType='productDetailsPage';

Not exactly a revelation, but sometimes this will allow you to later segment based on types of pages, sections of the sites or similar things. And it will also allow you to write very targeted rules in DTM or other tag management systems.

More dynamic data – like which product the visitor is actually looking at – can later be added via Javascript and still tracked.

What I am saying is: try to get as much data as you can into the data layer server-side, and add the rest via client-side Javascript. It’s better than nothing.

Go all the way

An alternative can be to go all the way.

Back to the Angular-based “web apps” I mentioned. Those literally have one single page load, everything else is done by modifying the DOM in the browser. A little bit like open-heart surgery.

The trick with tracking a web app like this is to add code into the Controllers you build for your app. That code would read attributes from your Model and send those into Analytics.

This is not uncommon, there is even an article in the help section: Implementing with AJAX.

The interesting part here is the Model. The Model “carries” those attributes around whilst the web app is active. That means you have access to the attributes at any point in the lifetime of the web app.

You can use a similar concept for your web site even if it is not based on Angular: write all data into storage, either browser-based or into cookies.

Example? Ok:

Your site has a shopping cart mechanism, fully client-side. Whenever a visitor adds or removes things from the cart, AJAX calls are made to the server. On a normal page load, there is no shopping cart available server-side because the page comes from one place and the cart sits in another.

What you do is tap into the client-side part of the shopping cart.

The shopping cart is likely stored in local storage, session storage, or cookies, and due to the nature of Javascript, you have access to that.

Use your browser to see where the cart contents are stored, then create Javascript code that reads that stuff.

If you are using a tag management system, you can inject that code. Using DTM, for example, you could create a Data Element that reads the cart contents, or even a couple of Data Elements for the different aspects of the cart: products, number of products, total price, …

The nature of a client-side solution like that is that it is available even during page load, which means we can access and use the data as early as we’d like to. Success!

Are there down sides? Yes, certainly!

Code like this is more complex than code accessing a classic, server-side Data Layer. That is never a good thing! If you ever replace the team member managing the code, the new person will have an interesting learning curve…

Browsers are not all exactly the same, either. Some of them will mess up the storage and your code. While it is likely that your developers or third party vendor will fix the functionality of the cart itself, you will still have to deal with changes on your end.

Nothing is free, it seems, not even on the Internet.