Data Layer Forensics: Commerce Edition

October 13, 2014 | Dorcas Alexander

Troubleshoot commerce analytics by taking a "data snapshot" the moment tracking occurs. Use our code and handy checklist to detect hard-to-find issues.

Something is wrong with your commerce analytics data, but you’re not sure exactly what. You’ve checked the tracking code and it looks fine. That means the problem is probably coming from the server side.

Server-side code takes transaction details — like products, quantity, and price — and places them where your analytics tracking code can read them.

If the transaction details don’t make sense, you’ll have problems such as transaction revenue with no products, or products with no revenue. If some details are malformed or missing, the tracking code may fail entirely.

We frequently use Google Tag Manager (GTM) to send commerce data to Google Analytics, which means servers are putting transaction details in the data layer. Our GTM tags read what’s in the data layer and track accordingly.

Step 1: Take a Data Snapshot with Our Code

How can you know whether or not the data layer was correct? You can capture the contents of the data layer by firing an event and a transaction at the same time, using the same rule in GTM.

Here’s our code that captures the commerce portion of the data layer:

function() {
	var generalString = 
		"General--ID:" + {{transactionId}} +
		",AFF:" + {{transactionAffiliation}} +
		",TOT:" + {{transactionTotal}} +
		",TAX:" + {{transactionTax}} +
		",SHI:" + {{transactionShipping}} +
	var productString = "";
    var numProducts = {{transactionProducts}}.length;
    for(var i=0; i 0) {productString = productString + "|"};
		productString = 
			productString + 
			"P" + (i+1) + 
			"--SKU:" + {{transactionProducts}}[i].sku + 
			",NAM:" + {{transactionProducts}}[i].name + 
			",PRI:" + {{transactionProducts}}[i].price + 
			",QUA:" + {{transactionProducts}}[i].quantity;
    return generalString + productString;

The first part of the code captures the details of the overall transaction, while the second part captures all the product details. Each macro (in curly brackets) refers to a data layer variable or array, which you need to define in GTM in order to use this code.

We put the code into a custom JavaScript macro in GTM, and then deliver it as the event label of our GTM tag that fires at the same time we track a transaction. Our event tag is set up as follows:


The event label contains a macro named “transaction datalayer” which is where our code delivers the details.

The macros named “pageSite” and “transaction type” that you see in our event action refer to other details we have in our data layer. You may have different details you prefer to track there and can fill the event action as you see fit.

Test first, then publish a new version of your GTM container. You want to make sure your transaction tracking is still working, in addition to your new event tracking. Then step back and wait a day or two for the new event data to accumulate.

Step 2: Examine the Data with Our Checklist

After you have a day or two of event data, it’s time to look for potential issues. You will probably need to load the data into Excel to examine it most efficiently.

Here’s our checklist to get you started:

1. Cross-check Transaction IDs – Are all the transaction IDs from your event data also in your commerce data? “Empty” transactions with no total, no tax, no shipping, and no products will not be added to your GA commerce data but will appear in your events.

2. Check for Required Fields and Formats – For non-empty event transactions that do not show up as commerce transactions, is there evidence that points to why they failed? Required fields must not be missing, and numeric fields must not contain currency symbols or commas. It’s also easy to break the data layer syntax if your product names and other fields contain unescaped apostrophes.

3. Do All Values Make Sense? – For example, we discovered that one of our clients was passing the address as the shipping cost. Google tried to be helpful by converting “1234 Elm Street” to “$1,234.00” in shipping!

4. Check Transaction Totals in Event Data – You may find that some transaction totals do not equal the sum of product prices (plus tax and shipping if you include that in your totals). We’ve found cases where the total is zero even though prices are non-zero, and vice-versa. There may be an explanation, such as coupon codes or free offers. Ideally, though, what you pass into GA as product revenue should line up with your transaction revenue.

5. Compare Totals in Event vs. Commerce Data – Make sure the transaction totals from the data layer (passed to your event data) are the same as the transaction totals in your commerce data.

You may uncover other anomalies in your commerce data once you start investigating with this behind-the-scenes look at the data layer. Or you may find explanations for things that looked strange on the surface, but turn out to be normal (and simply not tracked, such as free items or promotional offers).

How confident are you in your commerce analytics data? What issues do you suspect and are itching to prove? Do you have other techniques for this type of commerce investigation? Please share in the comments.