When you’ve done as many analytics audits and implementations as we have, uncovering business-critical mistakes is par for the course. Here is a highlights reel of routinely uncovered Adobe Analytics issues with some tips – and good reasons – to address them in short order.
Documentation isn’t sexy – not by a long shot – but it’s absolutely critical for getting the most out of your analytics investment. Yet we often see it is overlooked, de-prioritized or utterly nonexistent!
Adobe offers you the ability to pass data into over 250 custom variables (75 props, 75 eVars, 100 events) all of which can have unique settings configured within the tool and also within your own data collection JavaScript. It is one of the most powerful features of the tool but can sometime result in a huge headache to keep track of.
Ask yourself this: do you (or someone in your organization) have a solid understanding of exactly how your data is being populated into Adobe Analytics? What about how that custom-built video-tagging plugin you installed actually works? Or the integration you’ve enabled with DoubleClick? If you’re using multiple report suites, how sure are you that all your data is being collected using the same standards?
If you bring a new analyst onto your team, or someone leaves, what are you going to do with all the knowledge of the custom side of your implementation? If something breaks – and it will, trust me – are you able to fix it?
An even more important question that is almost always overlooked: do you know why you’re capturing what you are and how you can use it within the tool?
Chances are, your documentation is lacking, and a solid variable map or solutions design document can go a long way to help answer some of these questions and get your analytics program back on track. A few things your Adobe service description document (SDD) should include:
Adobe offers you a ton of options for collecting your data, but the three basic methods for custom data collection are:
Each has their own purpose, but all too often we see clients relying exclusively on eVars to do everything. And while eVars are great, they have their place. When you’re designing your SDD, think through exactly what you’ll want to use your variables for. Often you’ll have a prop and an eVar collecting the same data, and that’s okay.
You’d be surprised how often we see this one. It is such a simple fix, but so often forgotten.
Adobe has automatic exit link tracking built into its s_code JavaScript files, through the s.linkInternalFilters and s.trackExternalLinks variables. Within your s_code the configuration will look something like this:
s.trackExternalLinks = true;
s.linkInternalFilters = “javascript:, cardinalpath.com, …”;
If you’re using this feature whenever someone clicks an <href> leading to a domain that isn’t defined in the s.internalURLFilters variable a tag will fire indicating where they are exiting to. If you haven’t set anything into the s.IntenrnalLinkFilters variable you will get an exit link tag firing on every click the user makes.
Why is this bad? Well, it’s costing you money as Adobe is on a pay-per-server call pricing structure. It’s an easy fix though, just double check in your s_code that all the domains where the code exists have been defined.
In addition to that, make sure you update your internal URL filters list within the admin console to match. Otherwise you will see your own site referring to itself within your traffic sources reports and potentially within the marketing channels reports as well.
This is one of my favorite issues to find and fix because it can have serious impacts on server call usage, data quality, and the user experience.
Let’s take the following example:
You are running an ecommerce site and have a faceted navigation implemented on your product gallery page. Every time someone filters for a specific product you want to fire a tag to capture what filters they’re using. When they select a filter, a custom link tag fires and drops the filter criteria into an eVar. Then the page refreshes as your server needs to update what is being displayed on the page.
The server call used to capture the filter really isn’t necessary in this case because you could just use the server call on the next page load to give you the same information. Small changes like that can add up and have a big impact on your contract – meaning you could use the budget saved there to fund a testing program instead.
One final note on efficiency – if you’re firing tags on clicks of buttons that take someone to another page where a tag is firing, STOP! You don’t need this tag and it actually may be reporting inaccurate data. I’ve seen up to 50% improvements in reported volume of actions when switching from firing a tag on click to passing the data through to the next page and allowing the page load tag to pick it up. Now, you could put a delay on next page load by 50 or 100 ms, but speed is critical when moving users through our sites and we should never collect data at the expense of the user experience.
Many browsers won’t send more than 2,000 characters in one request. If a request goes over the limit the data may not all be processed by Adobe.
There are simple ways around this, though. Use processing rules, or dynamic variables to shorten your image request down. So instead of this:
s.prop1 = “Cardinal Path: Training: Events: Chicago Cardinal Path Training Academy”;
s.eVar1 = “Cardinal Path: Training: Events: Chicago Cardinal Path Training Academy”;
Do this:
s.prop1 = “Cardinal Path: Training: Events: Chicago Cardinal Path Training Academy”;
s.eVar1 = “D=c1”; (c is adobe’s notation for a prop, v is used for eVars)
Adobe will then automatically mirror the variable over for you, saving 71 characters from your image request.
If you’re passing the page’s URL into a variable (you should be for debugging) don’t do something like:
s.prop1 = “window.location.protocol + “//” + window.location.hostname + window.location.pathname”;
Instead, use the following (g is Adobe’s own variable for the page URL)
s.prop1 = “D=g”;
Also make sure you’re not passing more than 100 characters into a prop and 225 into an eVar – otherwise you’ll see truncation as well. Sometimes this is unavoidable, but if you’re getting lots of truncated values in your data collection it may be worth splitting your data into multiple values.
As consumers become increasingly digitally savvy, and more and more brand touchpoints take place online,…
Marketers are on a constant journey to optimize the efficiency of paid search advertising. In…
Unassigned traffic in Google Analytics 4 (GA4) can be frustrating for data analysts to deal…
This website uses cookies.