Sunteți pe pagina 1din 29

Data Layer for Digital Marketers (with Examples)

 27th January 2015


 Ed Brocklebank
 Data Layers
 0 Comments

Share this article


 Tweet
 Share
 Plus one
 Pin It
If you are struggling to get your head around the concept of a data layer, or keep
hearing the term being thrown around but have no idea what it is, then this article
is for you.
The concept of a data layer is becoming more important for digital marketing, and
it is essential that both the marketing team and the IT team understand what it is
and why their website needs one.
A data layer helps you collect more accurate analytics data, that in turn allows you
to better understand what potential buyers are doing on your website and
where you can make improvements. It also reduces the time to implement
marketing tags on a website, and reduces the need for IT involvement, leaving
them to get on with implementing new features and fixing bugs.

It is also heavily used by Google Tag Manager, which relies on the data layer to
pass it information about what is happening on the website.

This article aims to provide clarity. By the end of it you will:

 Know what a data layer is and why it is important


 Have an overview of the steps you need to go through to get it implemented
 Understand how to inspect a data layer on a website
 What tools you can use to assist the process
Contents [hide]
 1 Understanding the basics
o 1.1 How a web page reaches your browser
o 1.2 The data layer defined
o 1.3 Example: Comeback
o 1.4 Data layer naming conventions
o 1.5 Data layers are dynamic
o 1.6 Data layer stuctures
 1.6.1 Flat vs hierarchical
 1.6.2 Array vs object
o 1.7 Populating the data layer
 2 Why implement a data layer on your website?
o 2.1 The benefits
o 2.2 Didn’t tag management systems solve this problem?
o 2.3 Example: Reccomendo
 2.3.1 Implementation without a data layer
 2.3.2 Implementation with a data layer
 3 Understanding Google Tag Manager’s data layer
o 3.1 The default dataLayer variable
o 3.2 Adding data prior to page load
o 3.3 Adding data post page load
o 3.4 Implementing Enhanced Ecommerce
 4 Inspecting the data layer
 5 Project managing a data layer implementation
o 5.1 Choose an approach
o 5.2 Design & Requirements
 5.2.1 Standards
o 5.3 Implementation process
o 5.4 Common implementation mistakes
 5.4.1 Placing the data layer at the bottom of page and/or below your tag
management tool
 5.4.2 Missing commas
 5.4.3 Unescaped characters
 5.4.4 Strings for numbers or vice versa
 5.4.5 Commas in numbers
o 5.5 Automating testing
 6 Wrapping Up

Understanding the basics


How a web page reaches your browser
Do you know how a website appears in your browser?

This is the first questions I ask in my Technology for Marketers workshop. Often
no-one can give me a complete answer. I am starting here because you have to
know the fundamentals in order to really understand the data layer.
Here’s what happens at a high level:

1. You enter a URL into your web browser.

2. Your web browser sends a request (a message asking for data) out across the
Internet to the nearest Domain Name Server (DNS). The DNS holds a list of
domain names and their corresponding IP addresses (a unique identifier for a
computer or device attached to the Internet). The DNS looks up the domain
you requested in a table, and if found, returns the IP address of that domain.
This is the address of the computer that holds all the files that make up the
website you want to view.
3. Your web browser receives the IP address and sends out another request, this
time directly to the server holding the information you want.

4. The target server receives the request, processes it and returns


a response (another message). This response is normally HTML (Hyper Text
Markup Language, the universal standard for creating websites).
5. Your web browser receives the response and processes the HTML, rending it
onto your screen as content (text, video, pictures of cute cats). The markup
may contain JavaScript (a web scripting language), and this is run when the
browser gets to it. This part is key to the data layer.
It is the job of the web developer to ensure that step 4 works, and that the correct
HTML is returned when a particular URL is requested.

The data layer defined


A data layer (which can also referred to as the datalayer or data object) is a set of
information that exists on the web page, hidden in the code, invisible to the human
eye, but readable if you know where to look. It contains any data that you might
need to pass to other systems or software.
A web page is simply a text file written in a special markup language called
HTML. You can see this markup by right clicking any page and selecting ‘View
Source’ (although the wording varies from browser to browser).

The HTML may include references to JavaScript code, which is executed when the
page is rendered by the browser. JavaScript is a scripting language that runs in
your browser and allows the website to do clever things such as validating forms,
making images scroll, sending and receiving information from another source
(database, API, etc.) in the background, and much more.

It is within this JavaScript code that the data layer sits. In fact, a data layer is
simply a JavaScript variable or object.

The data layer can be very simple, composed of a single variable, or it can be
complex, composed of multiple nested variables. It all depends on what data you
need.

Example: Comeback
Consider a retail website that is running a fictional basket abandonment software
called Comeback. Comeback is loaded via a JavaScript tag included in the HTML
of every page of a website. Once loaded it sends a request to its servers that
contains data about the state of the basket and who the user is.
This data includes two variables: a unique identifier of the user, uid, and the value
of the items in the basket, total. Comeback stores this information in its database
so that it can trigger an email to the user should they not purchase within 24 hours.
For this to happen, the user ID and the basket total need to be somewhere on the
page so that the information can be passed to Comeback. That place is the data
layer.

Here’s what a data layer needed by the fictional Comeback software would look
like:

1 <script type="text/javascript">
2 var my_data = {
3 "uid": "1234",
4 "total": 29.99
5 }
6 </script>
A JavaScript object has been defined called my_data, which contains the two
variables uid and total. uid is set to 1234, and total is set to 29.99.
Notice how the value 1234 is enclosed by quotation marks. This indicates the value
is a string (a fancy way of saying a piece of text). This is different to
the total variable value of 29.99 which is not enclosed by quotation marks,
indicating it is a number.
Mistaking strings for numbers or vice versa is one of the biggest data layer
implementation mistakes I see and can result in inaccurate data being set to the
various system that rely on it.

Data layer naming conventions


You can call your data layer whatever you want, but there are a few conventions
emerging.

If you use Google Tag Manager then you will already have a data layer on the page
called dataLayer.
If you use Qubit then the convention is to call your data layer universal_variable.
Tagman uses tm_params and Tealium expects it to be called utag_data.
Most of these tag management system let you specific what name you want to use,
but for simplicity it is best to stick with the default.

Data layers are dynamic


The data layer is dynamic and the number of variables it contains changes
depending on what page you are viewing.

For example, the confirmation page of your website that is shown once someone
has placed an order will have access to data about the transaction, such as
transaction ID, what was purchased, the shipping address, etc. But on a product
page you don’t have this information. Instead you probably want to populate your
data layer with information about what product is showing.

This sounds like a massive job. If you’ve got 1,000 products on your retail site
does the developer have to edit each one of those pages?

No, because your website is built around templates.

Modern websites are built using a small set of page templates. These templates
outline the general structure and layout of the page, and define areas where
dynamic content will be injected. This is done for three main reasons: 1) it gives
your website a consistent look; 2) it allows developers to change one template and
have all content using that page template to update; 3) it means you can create a
new page using a content management system (CMS) and only have to specify
content for the dynamic areas.
The good news is that websites typically have less than ten of these templates. A
retail website might have:


home page
 category page
 product page
 basket page
 account page
 checkout page
 confirmation page
The bad news is that your developer still has to implement a slightly different
version of the data layer on each of these types of pages. More on this in the
implementation section.

Data layer stuctures


How you structure your data layer is a mixture of personal preference and the
requirements of software that interact with it. Here are the common structures you
will see.

Flat vs hierarchical

Flat

A flat data layer structure places all variables on the same level (depth). Flat data
layers are good if you only have a few variables and can be easier to implement.

1 var dataLayer = {
2 "userId": "1234",
3 "userEmail": "joe.bloggs@gmail.com",
4 "pageType": "product",
5 "productName": "Xbox One",
6 "productId": "XB1",
7 "productPrice": 449.99
8 };
Variables are accessed with a single dot notation:
1 dataLayer.productName
2 > Xbox One
3 dataLayer.userId
4 > 1234
Hierarchical
A hierarchical data layer groups related variables together into objects within the
main data layer. This type of structure is my preference as I find it easier to read
and manage, especially when the data layer gets big. There is less likely to be any
confusion over what variables mean.

1 var dataLayer = {
2 "user": {
3 "id": "1234",
4 "email": "joe.bloggs@gmail.com"
5 },
6 "page": {
7 "type": "product"
8 },
9 "product": {
10 "name": "Xbox One",
11 "id": "XB1",
12 "price": 449.99
13 }
14 };
Variables are accessed using a dot for each level you wish to go down into the tree
structure.

1 dataLayer.product.name
2 > Xbox One
3 dataLayer.user.id
4 > 1234
Both of these data layers contain exactly the same information. Only the structure
is different.
Google Tag Manager expects a hierarchical data layer for its Enhanced
Ecommerce tracking to function.

Array vs object

Object

Most data layer objects are just that – JavaScript objects. These can be recognised
because they start with a curly brace ({).

1 var dataLayer = { ... }

Array

An array is a list structure in JavaScript. Some people use this notation to define
their data layers. It can be recognised because it will start with a square bracket ([);

1 var dataLayer = [...];

What’s the difference?

Which you choose is often dictated by the tag management system you use. Most
use the object notation, whilst Google Tag Manager (GTM) uses the array
notation. It does this so that additional information can be pushed into the data
layer after the page has loaded.
More on this later in the article.

Populating the data layer


Another stumbling block that marketers experience is understanding where the
data that needs to go into the data layer is sourced from. For this, we need to return
to the opening section of this article that explained how a web page ends up being
rendered in the browser (refresh your memory if you’ve forgotten).
Once the request for a particular page has reached the physical server it is passed
on to the web server software (Microsoft IIS and Apache are the most popular).
The web server runs some server-side code that your developers have written. This
code is responsible for building the HTML that will eventually be returned to your
browser.
During this build process, the server-side code fetches HTML template files stored
on the server, as well as looking up information in your website’s database (most
dynamic websites have databases). Information retreived from the database is
injected into the HTML templates in the appropriate places. This is how a blog
always has the latest posts at the top, a news website always shows you the latest
articles, and a single HTML template can show thousands of different products.

For example, I visit:

http://www.myshop.com/product/widget-a.html

This URL is sent in the request to the server. The web server understands that if it
receives a URL of the form:

http://www.myshop.com/product/<slug>

it needs to render a product page. The HTML template for the product page is
retreived from the hard disk of the server. The server-side code then queries the
database for a product with slug ‘widget-a.html’ and returns all information
associated with this product. The relevant information is then injected into the
HTML template (e.g. <h1>…</h1> is replaced with <h1>Widget A</h1>)

It is at this point that the server-side code needs to construct the data layer.
Why? Because it is the only place that the database can be queried for information.
Once the HTML has been built and returned to the web browser it is too late. The
data layer has to be built at the same time that the page HTML is being built – on
the server.

And that is why only web developers who can manipulate the server-side code are
able to implement the data layer for you.

Why implement a data layer on your


website?
The benefits
The benefits of implementing a data layer are:
 To ensure accurate and consistent data is sent to your digital marketing tools
and systems
 To empower the digital marketing team with the capability to make changes on
the website
 To relieve the web developers of the strain of constant requests for small
changes to be make by the digital marketing team
 To speed up the deployment of marketing tags
(If these sound like the benefits of a tag management system, you’re not wrong.
The two often go hand in hand. Keep reading…)

In the past 3 years the number of digital marketing tools has exploded, and most
require you to place a JavaScript tag on at least one page of your website.

Web analytics tools (Google Analytics, Mixpanel, Kissmetrics, Adobe


SiteCatalyst), basket abandonment software, product recommendation engines,
JavaScript error trackers, user surveys (Qualaroo), heat mapping (CrazyEgg),
advertising and remarking (Criteo, Google AdWords) all require work from your
developers to put these tags onto the website. Some are simple, others are complex.
As a digital marketer, you may be constantly making requests for additional tags to
be placed onto your website, only to experience delays as the changes are deemed
low priority by the IT team. They never make it on to the site, or are implemented
incorrectly, resulting in you receiving no data or inaccurate data.

Didn’t tag management systems solve this problem?


The much heralded tag management systems (Google Tag Manager, Adobe Tag
Manager, Tealium, Ensighten, Qubit) came along to solve this problem, allowing
you, the marketer, to put tags onto the website yourself, without the need for
developers.

Tag management system are excellent and I am all for having one on your website
– BUT they have one massive flaw.

Their true power can only be realised when a complete and valid data layer
exists on the website.
The true power of a tag management system can only
be realised when a complete and accurate data layer
existsCLICK TO TWEET
Most digital marketers fail to realise this, and as a result spend thousands on a tag
management system they can never utilise fully. If you are using a tag management
system but haven’t implemented a data layer you are missing out, BIG TIME.
Example: Reccomendo
Recommendo is a fictional product recommendation engines service I’ve just made
up. Its sole purpose is to show visitors to a retail website a widget with products
they might be interested in (think ‘You might also be interested in…‘ on Amazon).
For this technology to work, the Recommendo servers need to be sent details of
what products a person sees during their browsing session. To do this, it requires
the following JavaScript code to be inserted onto all product detail pages of your
website.

1 recommendo.send('1234', { // User ID
2 "id": "XB1", // ID of the product
3 "name": "Xbox One Console", // Name of the product
4 "price": 449.99, // Price of the product
5 });

Implementation without a data layer


You’ve just got Google Tag Manager installed on the website and promised your
boss that you can now put any marketing tool under the sun onto the website
without having to pay for any more web development time.

You’re pumped, excited, tingling with anticipation as you diligently create a rule to
tell Google Tag Manager to only trigger this tag on product pages.

And it is here that you run into your first problem.

How do you know if it is a product page? Your website doesn’t have a URL
structure that makes product page identification easy (such as
mydomain.com/product/xbox-one.html. This URL would be easy to parse for the
text ‘/product/’).
Luckily your website only sells 50 products and so you decide to hard code each of
the URLs into the Google Tag Manager rule. This takes several hours of manual,
boring work (which you feel is beneath you) but you do the job regardless.

Problem solved (at least until you add a new product or change your URL
structure, at which point your tracking breaks and you probably don’t even realise
until your Recommendo conversion rate begins to drop and your boss reprimands
you for spending so much money on a tool that doesn’t appear to be working –
because you are feeding it bad data without realising).
Next you create a new custom tag and paste in the JavaScript above provided by
Recommendo. Inspecting it more closely you realise to your horror that the values
of user ID, id, name and price are all dynamic – they are different for each of your
product pages.
This means one of two things.

You either have to a) create a different tag in Google Tag Manager for each of your
product pages, manually copying and altering the Recommendo JavaScript code
for each one, or b) use Google Tag Manager’s macro feature to inject the dynamic
variables into the tag.

Option b) seems the most sensible but there’s a problem. You can set up macros to
search for the HTML for product name and price, but user ID and product ID are
not displayed anywhere on the page. There is no way for you get this information.

After several wasted hours you reluctantly type an email to your boss stating that
you need time from the developers to get Recommendo implemented. He says no
because they are busy working on a site redesign, the tag never gets implemented,
and your company loses out of the £1m of incremental annual revenue the
software would have generated.

Sad times.

Implementation with a data layer


You’d read an excellent article on data layers tweeted to you by a colleague (hint:
please share this one if you get value from it!) a few months earlier and asked the
development team to implement the following data layer on all product pages for
you.

Check out this mega post on everything you ever


wanted to know about data layersCLICK TO TWEET

1 var dataLayer = {
2 "user": {
3 "id": "1234" // The user's ID
4 },
5 "page": {
6 "type": "product" // The page template type
7 }
8 "product": {
9 "id": "XB1", // Product ID
10 "sku": "XB1A", // Product SKU
11 "brand": "Microsoft" // Product brand
12 "category": "Gaming", // Product category
13 "name": "XBox One Console", // Product name
14 "price": "449.99", // Product price
15 "thumb": "/media/xbox1.jpg" // Product image
16 }
17 }
This is a hierarchical data layer, because it is structured like a tree with objects
within objects. The data layer contains three top level
objects: user, page and product. This is done to separate the data into logical
sections and makes it easier to read and mange.
The user object contains the ID of the current user. The page object tells us the
type of page we are on (in this case a product page). The product object provides
all the details we need about the product being displayed.

This time you are able to quickly create a rule in Google Tag Manager to only fire
the Recommendo tag on product pages because the fact we are on a product page is
indicated to us by the data layer. You set up a macro called pageType and set it to
read the value of the data layer page.type variable.
As soon as Google Tag Manager loads on a page it will read this value, and set it to
‘product’ (if we are on a product page).
You repeat the process for each of the product variables.
This rule creation took 10 minutes (including logging into Google Tag Manager),
compared with the hours spent in the example without a data layer.

Next you create a tag and paste in the Recommendo JavaScript. You edit each of
the dynamic values to receive the data from the data layer, rather than it being hard
coded (that’s what the {{ }} symbols do).

You assign a firing rule to the tag so it only executes on product pages (remember,
the {{pageType}} value is picked up automatically from the page.type variable in
the data layer. Neat, huh?).
This takes a further 5 minutes.

After just 15 minutes of work you are able to put the tag live.

A month later you receive a promotion for your forward thinking in getting a data
layer implemented and the spike in sales that can only be attributed to
Recommendo.

Understanding Google Tag Manager’s data


layer
Websites that use Google Analytics have started to also use Google Tag Manager,
which is offered free. Since it is becoming more popular I’ve included this short
section on things you should be aware of.

The default dataLayer variable


Google Tag Manager places a data layer variable onto your website
called dataLayer. It is a hierarchical structure that uses Array notation. By default
the data layer will only contain information that GTM uses, such as event variables
that indicate the page has loaded.

1 dataLayer = [{
2 "gtm.start": 1422445519326,
3 "event": "gtm.js"
4 },{
5 "event": "gtm.dom"
6 },{
7 "event": "gtm.load"
8 }
9 ]

Adding data prior to page load


Should you want to populate GTM’s data layer with your own data, you need to
define the dataLayer variable in your HTML code, before the main Google Tag
Manager tag, and populate it with data.

1 <script>
2 // Here's where you define the data layer
3 dataLayer = [{
4 "user": {
5 "id": "1234",
6 "email": "joe.bloggs@gmail.com"
7 },
8 "page": {
9 "type": "home"
10 }
11 }];
12 </script>
13
14 <!-- Google Tag Manager -->
15 <noscript><iframe src="//www.googletagmanager.com/ns.html?id=GTM-YOURID"
16 height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
17 <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
18 new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
19 j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
20 '//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
21 })(window,document,'script','dataLayer','GTM-YOURID');</script>
22 <!-- End Google Tag Manager -->

Adding data post page load


Suppose a person adds a product to their basket by clicking a button on the page.
At that point the information about the action the user has performed (the event)
can be pushed to the data layer.

Here’s an example using Google Tag Manager syntax of pushing


an addToCart event to the data layer when an Add to cart link is clicked.

1 <a href="/basket" onclick="javascript:dataLayer.push({ event: "addToCart" })">Add to cart</a>


Before the link is clicked the data layer might contain the following.

1 dataLayer = [{
2 "product": {
3 "name": "Xbox One",
4 "id": "XB1",
5 "price": 449.99
6 }
7 }];
After the link is clicked, the data layer will have an extra object containing the
variable event.

1 dataLayer = [
2 {
3 "event": "addToCart"
4 }, {
5 "product": {
6 "name": "Xbox One",
7 "id": "XB1",
8 "price": 449.99
9 }
10 }
11 ];
This is useful because you can set up tags in GTM to be fired when a particular
event value is received.
For more on this see the official Google Tag Manager Developer guide.
Implementing Enhanced Ecommerce
One of the most frequently asked questions I get is about implementing Enhanced
Ecommerce reporting in Google Analytics. I believe the confusion occurs because:

 people don’t fully understand the data layer

 there are multiple ways to implement Enhanced Ecommerce

 there are multiple features of Enhanced Ecommerce, all of which are


implemented in different ways.

This article is long enough already without me going into everything you need to
do to get Enhanced Ecommerce working.

However, I would like to stress that there are two methods of implementation:

1. You manually fire JavaScript code that sends data to Google Analytics. The
code depends on what type of page the user is on (product page, confirmation
page, etc.).

2. You put data into the data layer in a format GTM expects. GTM will
automatically read that data, process it, and send it to GA in a format GA
expects. This is in my opinion the simpler option and what you should opt for
if you have a choice.

Inspecting the data layer


Alright, time for a demo. I want to show you how to inspect a data layer on a
website.

1. Open this web page in Chrome.

2. Right click anywhere on the page and select ‘View Page Source’. A
window will popup full of HTML. This is the markup that generates this
page.

3. Hit Ctrl + F (Cmd + F if on Mac) to open the search window, and search
the HTML for the phrase ‘dataLayer’. The first result is where
the dataLayervariable is declared. At this point it is an empty array
(remember GTM uses the Array notation for its data layer).
Search further down the source code and you’ll see the data layer being
populated with values about this article.

There are several points to take note of:

 You are looking at a text version of the data layer. In reality when
the web browser renders this code it understands that it is JavaScript
(because it is enclosed within <script> tags) and executes it.
 The web browser ignores white space in source code. Don’t be
surprised if the data layer code doesn’t look as neat and tidy as the
examples on this page and is shown either expanded with lots of white
space padding, or squished up with no padded. The browser doesn’t
care.
 The browser DOES care that the data layer is valid JavaScript.
White space may not matter, but the code must be written in a way
that browser can run. To check this, let’s move on to step 4.
4. In order to view the data layer as the web browser sees it when it compiles
it, we are going to use the Chrome Console window, part of Chrome’s
Developer Tools. Don’t be scared, it’s easy when you know how. Open the
Developer Tools by selecting View -> Developer -> Developer Tools from
Chrome’s menus.
The wording may be slightly different on Windows machines, but hunt
around and you will find it.

5. Once opened, click the ‘Console’ tab.


6. At the prompt, type the word ‘dataLayer’. Make sure you capitalise the
letter ‘L’. JavaScript variable names are case sensitive. Hit enter and you’ll
will see the console display a list of objects that make up the data layer.

7. Expand the first object by clicking the arrow to the left of it (highlighted in
red). What you are seeing here is the same information that you saw by
inspecting the raw source code in step 3, expect this time it is formatted for
viewing. The data layer holds information about the article, including the
author (that’s me), when the post was published, and the post title.
I may not be using all these variables right now, but you never know what tools
might need them in the future. That’s why it is best to pack as much info as you
can in there when you first design it.

An example use might be tracking who your most popular authors are in Google
Analytics. This could be done by creating an Author custom dimension, then
setting up a tag in GTM to send the pagePostAuthor variable to Google Analytics
whenever the pagePostType is equal to “post”.
(ps. If you aren’t using Custom Dimensions in your Universal Analytics
implementation you should be)

Project managing a data layer


implementation
If you’ve read this far you should now have a good understanding of what a data
layer is and why you should implement one on your website. In this section I’m
going to describe the process you’ll need to go through in order to get that done.

Choose an approach
It goes without saying that unless you are a one man band you need to get
stakeholder buy in for a project like this. They won’t necessarily understand the
purpose of the data layer like you do. From experience I’ve found this the most
challenging part of the implementation – convincing people that it is worth
spending time upfront doing implementation work because ‘you may need the data
in the future’.

Your approach should take into account factors such as:

 The complexity of the data layer required

 How quickly you need it done

 How well you know your developers and how they will react

When pitching the idea, concentrate on selling the idea that it will 1) reduce IT
workload in the future and 2) allow marketing to better gather and analyse data that
will lead to increased revenue.

You can choose to run the project in two ways:

1. The full monty. Draw up a complete specification of all the data you will ever
need (based on current marketing tools in use and anything likely to come up
in the future) and try and get everything implemented in one go.
2. The agile way. Draw up specifications for the smallest data layer you can,
only including information that is essential to get marketing tags working. For
example, you may only need a data layer on your confirmation page to track
revenue in Google Analytics, and can leave out all other pages.
I would strongly recommend you go for option two. First, you are more likely to
get the go ahead as it requires less dev time. Once your business sees the benefits
of the initial implementation securing resource to complete additional bits should
be straightforward.

Secondly, it is also easier to test and validate a small data layer.

Thirdly, once the dev team have implemented the first version they will understand
the concept and can complete further iterations quickly. If you supply them with a
massive specification document up front you are likely to get a ‘we don’t have
time for this’ reaction before they have really taken a look at it.

Design & Requirements


Once you’ve chosen an approach, it’s time to build out a specification document
that details what information needs to go on what page and in what format.

Your document needs to specify:


 the types of page that the data layer needs to go on (e.g. home, product,
category, basket, confirmation)

 the variables to include in the data layer for each of those page types

 details about each variable, such as its format (boolean, text, number, object or
array), whether the variable value is static (remains constant across all pages)
or dynamic (changes for every page) and if the variable is required (must be
present in the data layer) or optional (a nice to have but can be left out).

If you have a simple data layer then Excel is fine for this. Put the page types across
the top and variables in the rows. The cells should contain information about the
variables.

Here’s an sample data layer specification built in Keynote.

The downsides of planning your data layer like this are that:

 you have to keep the file up to date


 you have to continuously email it around
 it gets messy for larger implementations
 you don’t get any sample JavaScript code
For those reasons I built Data Layer Doctor to help manage the data layer design
and implementation process. You can sign up for free here.
Standards
Although you have free reign to structure the data layer however you wish, there
are some emerging standards emerging. The two worth mentioning are Qubit’s
Universal Variable (I like this one, it covers most eventualities) and the more
formal W3C Customer Experience Data Specification (weird name – data layer’s
are not just about custom experience).
I should also mention Google’s Enhanced Ecommerce data layer specifications,
needed if you want to implement Enhanced Ecommerce via Google Tag Manager.
Implementation process
Once your requirements document is done, it’s time for the implementation work.
At this point you need to have a discussion with your development team, showing
them your requirements and explaining what you want.

How the data layer gets implemented depends on what platform your website is
built on. If it is a common platform, chances are you can get a plugin or extension
to get you started, which can then be tailored to your needs.

This website is build on WordPress, and I use DuracellTomi’s Google Tag


Manager For WordPress plugin, which includes a simple data layer.
If you use the Magento ecommerce platform then Qubit’s Universal Variable
plugin is a good starting point. There are also plugins for Enhanced Ecommerce.
I would stress, however, that none of these are likely to fit your needs exactly. You
WILL have to do some development work in order to get the data and structure to
match your requirements.

Common implementation mistakes


Once the data layer is implemented, it is crucial that you test it using the inspection
methods outlined in this article. It is very easy to make a mistake in the JavaScript
code.

The most common mistakes I see are:

Placing the data layer at the bottom of page and/or below your tag
management tool
This means that your marketing tools load before your data layer. Without the data
layer, the marketing tools won’t have any data and will either not do anything, or
start tracking incorrect values.

Missing commas
1 var dataLayer = {
2 "productId": "1234",
3 "productName": "Xbox One"
4 "productBrand": "Microsoft",
5 "productPrice": 449.99
6 }
The missing comma after “Xbox One” means this data layer is invalid.
Unescaped characters

1 var dataLayer = {
2 'productId': '1234',
3 'productName': 'Xbox One',
4 'productDescription': 'This'll break the data layer',
5 'productBrand': 'Microsoft',
6 'productPrice': 449.99
7 }
Remember to escape any characters in strings that could cause problems. The
apostrophe in the product description value terminates the string early. This data
layer is invalid (the syntax highlighter used on this page also spots the mistake).
To correct either use quotation marks instead of apostrophes to surround variable
values, or escape the characters with a backslash.

1 var dataLayer = {
2 'productId': '1234',
3 'productName': 'Xbox One',
4 'productDescription': 'This\'ll break the data layer',
5 'productBrand': 'Microsoft',
6 'productPrice': 449.99
7 }

Strings for numbers or vice versa


Strings are not numbers and numbers are not strings. In the data layer below
product price has been accidentally set as a string (JavaScript interprets anything in
quotation marks to be a string).
1 var dataLayer = {
2 "productId": "1234",
3 "productName": "Xbox One"
4 "productBrand": "Microsoft",
5 "productPrice": "449.99"
6 }
You should check with your marketing tools what they expect. Google Enhanced
Ecommerce expects revenue figures in string format (which is unusual) and does
the conversion to a number server-side. If you passed a number value to Google
Analytics as the value of a transaction instead of a string, your reports would show
zero revenue. Bummer.

Commas in numbers
This can happen when the thousand separator is left in a number.

1 var dataLayer = {
2 "productId": "1234",
3 "productName": "Expensive Xbox One"
4 "productBrand": "Microsoft",
5 "productPrice": 1,449.99
6 }
It can also happen when dealing with foreign currencies where a comma is used
instead of a decimal point.

1 var dataLayer = {
2 "productId": "1234",
3 "productName": "Xbox One"
4 "productBrand": "Microsoft",
5 "productPrice": 449,99
6 }

Automating testing
To avoid the mistakes in the previous section you should use software that
automatically validates your data layer against your specifications. If you built
your requirements document in Data Layer Doctor then you’re in luck – there’s a
testing tool built right in.
The video below shows an example of testing Google Analytics Enhanced
Ecommerce code with Data Layer Doctor’s chrome extension (now released).
Wrapping Up
Phew! If you read the entire article well done!

If you skipped to the summary without reading the entire thing then I suggest you
bookmark this page so you can come back later.

In essence, I believe the data layer is a crucial and often overlooked aspect of web
development. The digital marketers need it to speed up their marketing tag
deployment times and ensure they are making decisions based on accurate data,
and yet it is often left out of system builds.

If you are having a new website built then you need to get your requirements to the
project management team immediately. If you already have a website then you
need to talk to the development team and enquire how long it might take to get one
implemented for you.
Without a data layer tag management tools are a waste of money and under-
utilised. With a data layer they become a powerful asset for collecting data that
could lead to exponential business growth.

I hope this article has given you a better understanding of what the data layer is,
and the lingo you need so you can have sensible conversations about getting one
implemented for your business.

If you enjoyed this article and found it useful, please share it.

I learned loads! Check out this complete introduction


to the data layer for digital marketersCLICK TO TWEET
I would also encourage you to sign up for Data Layer Doctor and give it a try. It
will speed up the data layer implementation and management process

S-ar putea să vă placă și