The User-Agent (Part II)
23 Dec 2018 » Analytics Tips
This is the second part of the User-Agent mini series. I split the topic into 2 posts, as it was getting too long. If you have not read the first part, I recommend you start with it. I will now explain how Adobe uses the User-Agent HTTP parameter in the different tools.
There are two motivations behind this post:
- General knowledge. I have found very useful in the past to better understand a tool, even if I am not going to use the knowledge directly. It demystifies it.
- Debugging. I hope the following information will help you debug or understand your implementation, in case you are not getting the results you were expecting.
Adobe Analytics
Reports
There are two main places where you see the data derived from the User-Agent in Adobe Analytics:
- The “Visitor Profile > Technology” menu, with. In particular, “Browser”, “Browser Types”, “Operating System” and “Operating System Types”. These reports refer to all devices browsing your website.
- The “Mobile” menu, where all parameters are deduced from the User-Agent. As its name implies, this is only for mobile devices. Adobe added this separate menu because you can extract more information from the User-Agent of a mobile browser than from a desktop browser and mobile browsers become more common. For example, a desktop browser will not tell you the manufacturer of the desktop, but you usually get that in a mobile browser.
All the information shown in these reports comes from 3rd parties, which provide Adobe with a database with all the known User-Agents. You can think of it as a SAINT classification of the User-Agent. Therefore, keep in mind that obscure devices might never show up and a very new device may take a few days to be correctly recognised.
An important detail is that the actual value of the User-Agent is not available in any report. although it is available in the data feed. Should you want to have the full text in a variable (I recommend a prop) and play with it, you can use the dynamic variable “D=User-Agent”, and the collection servers will copy the value into the variable of choice.
Also, as I explained in the first part, Apple devices do not provide enough information to detect the hardware version, so all we get is the device name. Android devices are more transparent and provide enough details to know the device model.
Finally, all these dimensions, which you could consider as traffic variables, are available in the segment builder.
Bots
The next place where you will see the User-Agent is in the bots configuration and the bots reports. Let’s start with the configuration. It is per report suite and you can supply the list of User-Agents that should be considered as bots, so their visits do not show up in the reports. You should always select “Enable IAB Bot Filtering Rules”, unless you know what you are doing. Adobe pays to get this list and it includes all the typical suspects (e.g. Googlebot), so I see no reason not to use it.
Besides, it is not uncommon to have custom scripts or malicious bots, which scrape your website and are not included in the IAB list. Some time ago, these bots did not execute JavaScript, but now they do, so they will pollute your reports with bogus data. In this case, you can add them to the exclusion list and one of the options is excluding particular User-Agents.
There is one place, though, where the bot traffic shows up in Adobe Analytics, the bots reports:
Again, the User-Agent is not available in any bot report, but it is used to generate these reports.
Last resort identification
The last place influenced by the User-Agent is in the visitor identification. I do not think this is very relevant today, when all implementations should be using the ECID service. However, in legacy implementations, which still rely on the s_vi cookie, it can still be relevant. If all of the following conditions are met:
- There is no
vidparameter in the hit, which means you have not sets.visitorID(you should never use it anyway) - There is no
midparameter in the hit, because you are not using the ECID service - The analytics collection servers have not been able to set the
s_vicookie, usually because 3rd party cookies are blocked - There is no
fidparameter in the hit, typically because you are using a very old version of s_code.js
then Adobe Analytics will generate internally a unique visitor identifier based on a combination of the IP address and the User-Agent. The likelihood of this combination not being unique is fairly low, which makes it a good last resort to uniquely identify visitors and keep the visits and visitors metrics accurate.
Adobe Target
Target only uses the User-Agent to create audiences. You can find it, indirectly as usual, in the “New Audience” wizard, in the following rules:
- Mobile
- Operating System
- Browser
As with Analytics, Target gets a classification of the User-Agent from a 3rd party. Therefore, the same restrictions and limitations explained in the Analytics section apply.
Audience Manager
Very much like Target, AAM uses the User-Agent to create audiences. In this case, it is only available in the trait creation wizard. What makes it different from other tools is that you can directly match the User-Agent, using the key “h_user-agent” in a trait rule. I do not recommend you use the “==” operator. Instead, “contains” or “matchesregex” are better options. I gave an example of it in a post, where I explained how to detect an iPhone 6.
However, since I wrote that post, AAM has added platform keys based on User-Agent. Get the list of the most common keys and create the traits based on them. I would not recommend you use “h_user-agent”.
Server-side implementations
I have another series about server-side digital marketing. If you have followed it, you will have noticed that I make special emphasis on copying the User-Agent parameter from the client’s HTTP call. I hope it is clear why you need to do this. This HTTP parameter is key to some features of the Adobe stack. Now you also know what you will be missing if you do not make this copy.