(2020 update: some of the below is slightly outdated. You may want to read Edge Nodes, Data Centres & other Updates, which has all the latest information)
Today we’ll take a look at the different parameters that you can find in the URL of a tracking call when you debug. Some are vital for the system to work, others transport the data that you want to track.
Let’s look at an example:
That’s a pretty long & impressive URL. The page in this example is being used for a lot of testing. It is highly likely that the tracking calls on your site be a lot shorter.
Let’s dissect it.
The Important Stuff
Let’s start with the first part of the URL, the vital stuff:
The FQDN points to the tracking server that the browser should use. As we mentioned before, it can be a CNAME like above (
om.jan-exner.de), but it can also point directly to the Adobe tracking servers (
janexnerinc.d1.sc.omtrdc.net or similar FQDNs).
As far as I know,
/b/ss doesn’t mean anything, but it will always be on tracking URLs and can therefore be used in Charles or Fiddler to filter for tracking URLs.
jexnertest,jexnerrollup1 part tells us into which “report suite” the data should go. In this case, it will go into two report suites. The back end will basically send data into “jexnertest” and copy the same data into “jexnerrollup1”.
Note: Now this would be a good place to discuss how Adobe charges for Analytics, but let’s do that later. We’ll just say now that each report suite that you add will mean you use “secondary server calls” which cost money.
1 in the URL means that this is a standard server call. You might also see a
5 there, or even a
5.1, both usually on mobile sites. The collection servers use this to decide how they try to figure out visitor identification. For mobile hits, the system will try to use “subscriber ID” HTTP headers like “X-ASID” before it resorts to using cookies.
s51094577372802 is a random number, inserted so the browser doesn’t cache the request.
With the exception of the random number, all of the above is necessary for the system to know what to do with the tracking call when it receives it.
The parameters on the URL mostly transport data, but there are some that do not. We won’t go into the first category again, having mentioned them before. Instead, we’ll explain some of the non-data parameters.
AQE=1– these are markers at the beginning and end of the parameter list. The collection servers look for those two in order to determine whether they have received the complete URL or if it’s been truncated.
fid– the fallback visitor ID.
vmt– used in conjunction with so-called “visitor migration”.
ns– the “namespace” for your tracking. This parameter can be used by the collection architecture for load balancing, but as far as we know tracking works without it.
r– the URL and HTTP referrer of the page that is being tracked. You can overwrite
oidt– those are set for the Clickmap plugin. Regarding Clickmap, we recommend the excellent article by called How Clickmap does what it does.
vidn– the visitor ID, usually read from the
You can see a lot more parameters on the URL above:
pageName of course, a lot of
vY parameters representing
products and some of the built-in, automatic variables we mentioned before. All of those transport data and are not vital for tracking to function. Of course, without them there is no point tracking.
19 thoughts on “Debugging – the URL”
Thanks as always for this blog, I constantly use it as a reference. Today I came looking for more info about Click Map and the new Activity Map. Could you discuss the new Activity Map, perhaps point to some reference implementations if possible…?
Thank you! I use it as that, too 😉 Article on Activity Map is in the pipeline, but not quite ready yet.