Tracking User Agents in Adobe Analytics & Google Analytics

May 27, 2020
Lead Platform Analyst

As your organization progresses in its digital analytics maturity, you might find yourself confronted with the need to work with user agent data. Advanced segmenting, custom bot filtering, or recreating out-of-the-box device reports are some of the possible use cases for this data.

Before we dive in, let’s first establish—what is the user agent?

The user agent (UA) is part of the HTTP header and gets populated whenever a request is made from a client (e.g. your browser) to a server (e.g. a web server). It contains information about the browser and the operating system of your device.

When you visit a website, your browser, the client, sends a request to the server. The server then sends a response (hopefully “200 OK” and not “404 Not Found”) and the website renders.

As you can imagine, there are many different possible combinations of operating systems and devices. Despite the vast amount of possible user agents, there is a common format for web browsers. According to Mozilla, the common format looks as follows: 

User-Agent: <product> / <product-version> <comment>

If you are a non-technical reader, conduct a quick Google search to find the user agent of the current device-browser combination you’re using.

Image showing Google search results for what's my user agent

Why is the User Agent Relevant for Digital Analytics? 

The short answer: To build segments and analyze metrics across different devices. 

If you’re an analyst and work with digital analytics solutions like Adobe Analytics or Google Analytics, chances are you’ve analyzed traffic and conversion metrics across different device types like Mobile, Tablet, or Desktop.

image showing visits by device type report in Adobe Analytics

Adobe Analytics - Visits By Device Type

image showing users by device category report in google analytics

Google Analytics - Users By Device Category

In order to populate these reports, digital analytics platforms group the various UAs into user-friendly buckets. It’s a mapping exercise that involves a huge, well-maintained database.

Adobe Analytics leverages the service device atlas to achieve this for its users. Google Analytics doesn’t mention the technical details behind their device categorization in their official documentation, but we could assume they leverage an in-house solution.

"Adobe Analytics & Google Analytics capture the user agent out-of-the-box, but only surface a curated version of data to the analyst."

How to Collect the User Agent

In general, the UA can be retrieved via JavaScript. The information is stored in the userAgent property. 

Visit any website and open your browser’s developer tools. Navigate to the console and type in navigator.userAgent to return the full UA string.

image showing navigator.userAgent in the Chrome Developer Console

The developers and analytics engineers amongst you might already know what needs to come next. For the non-technical folks—now that you know how to retrieve the user agent via JavaScript, it is a good idea to store that information in a variable that can easily be referenced across your analytics implementation. 

If you’re using the Adobe stack, you can store the information in a Launch data element. If you’re using the Google stack, you can store the information in a custom Google Tag Manager (GTM) variable.

How to Collect the User Agent in Adobe Analytics 

We have two options to collect the user agent in Adobe Analytics. Option A is implementation via Adobe Launch. Option B is implementation via a processing rule. Both options are straightforward and achieve the same thing.

While there’s no optimal version from a results point of view, the method of choice depends on your individual situation.

The benefit of approach A is that you can validate the hits in your debugger before you approve and publish your Launch library. Another benefit is you only have to set up a rule once, whereas with processing rules you have to copy the rule into each individual report suite. The downside of approach A is that mistakes can occur over time—rules and data elements could get modified or deleted.

The benefit of approach B is that you can leverage Adobe’s out-of-the-box dimension and you don’t need to involve your analytics engineer to start collecting the data. The downside of approach B is that you can’t debug your changes and you can irreversibly mess up your data. That’s why in the past, you had to pass an exam to be provisioned for processing rules.

Version A: With Adobe Launch

Step One: Pick & Enable an eVar in Adobe Analytics

image showing how to set up an eVar in Adobe Analytics

If you don’t intend to set this eVar on every hit, save yourself time and go with the “visit” expiration. This way, its value persists throughout the visit and the eVar can be associated with non-pageview events like form submits, video views, or purchases in reporting. If you need a refresher on eVar allocation and persistence, check out our guide on configuring eVars.

Step Two: Create a Data Element in Launch

Use the “Core” Extension to create a “JavaScript Variable” data element. 

Insert the variable path window.navigator.userAgent and save your changes.

image showing how to create a data element in adobe launch

Step Three: Map the Data Element to an eVar in Your Global Pageview Rule

Now we can go ahead and map the data element to an eVar in our global pageview rule. Since we set the eVar to expire after the visit, any subsequent interactions on the page can still be associated with this eVar. 

image showing how to map a data element to an eVar in Adobe Launch

Save your changes and build the library. 

Step Four: Validate your Changes

Once the library is successfully built, visit your site and debug your changes. You should now see the user agent populated in eVar20. 

image showing how to view the analytics request in the adobe experience platform debugger

Version B: with a Processing Rule

If you don’t have the time or the knowledge to fix this on the implementation side of things, you can leverage processing rules. Processing rules allow you to set, modify, or delete the value of a collected dimension (eVar or prop) before it gets populated in the reporting interface.

If you haven’t worked with processing rules yet, I encourage you to read the official documentation before you set up your first rule. Once you are familiar with how processing rules work, I recommend you test it out in a dev or staging report suite first to ensure it's working as expected. Then, you can copy it into your production report suite.

Step One: Pick & Enable an eVar in Adobe Analytics

Similar to the implementation via Adobe Launch, this is still the first required step. If we don’t enable the eVar, we won’t be able to use it in the reporting interface.

image showing how to set up an eVar in Adobe Analytics

Step Two: Find Processing Rules in the Report Suite Manager

Navigate to Admin > Report Suite Manager and highlight the report suite you’d like to modify. Then, proceed to Edit Settings > General > Processing Rules.

image showing process rules in Adobe Analytics

Step Four: Click to Add a New Rule

image showing creating processing rules in Adobe Analytics

Step Five: Configure the Processing Rule

In the condition, we want to make sure that the user agent is set. Keep in mind that the field you see here is the out-of-the-box dimension Adobe Analytics collects, but doesn’t show in the reporting interface. 

Next, we simply overwrite eVar20 (which is always empty at this point) with the user agent. 

image showing configure processing rules

Save your changes and wait a few hours. Then, you can validate the data in the reporting interface. 

How to Collect the User Agent in Google Analytics 

Step One: Pick & Enable a Custom Dimension in Google Analytics

In your Google Analytics property settings, enable a new, session-level custom dimension. While the session-level custom dimension works for most scenarios, consider the hit-level custom dimension if you have a user-ID view enabled. That way, you will gain visibility into all devices used in a single session.

image showing where to add custom dimensions in Google Analytics

Step Two: Create a Custom GTM Variable

Head over to GTM and create a new user-defined variable. Choose the “JavaScript Variable” type and insert the variable path window.navigator.userAgent.

image showing custom JavaScript variable in Google Tag Manager

Save your changes.

Step Three: Map the GTM Variable to Your Custom Dimension

Now we can map the GTM variable to our custom dimension. You can either do this in your Google Analytics settings variable, or on a per-rule basis.

image showing mapping variables to custom dimensions in Google Tag Manager

Save your changes.

Step Four: Validate Your Tag

Debug your changes and validate that data is actually being sent to the custom dimension.

image showing preview mode to view the Google Analytics request in Google Tag Manager

Publish your changes and wait a few hours. Then, proceed to validate the data in Google Analytics. 

Tracking User Agent to Enhance Data

Storing the user agent as an additional context in your digital analytics solution can truly benefit advanced analytics use cases like device-specific segmenting or custom bot filtering. If you have the time and the resources to enhance the data collection, you can leverage JavaScript to send the user agent to a custom dimension in Google Analytics or to an eVar in Adobe Analytics. Adobe Analytics users can alternatively also leverage a processing rule to achieve the same thing.