Debugging – the URL

(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:


http://om.jan-exner.de/b/ss/jexnertest,jexnerrollup1/1/H.25.4/s51094577372802?AQB=1&ndh=1&t=9%2F3%2F2013%2010%3A13%3A57%202%20-60&fid=4FF49202A8B0289C-2CA8EC2D754E51EB&vmt=4CCFE053&ce=UTF-8&ns=janexnerinc&pageName=berichte%3Ab130228.php&g=http%3A%2F%2Fwww.jan-exner.de%2FBerichte%2Fb130228.php%3Fic%3Dhph&r=http%3A%2F%2Fwww.jan-exner.de%2F&cc=GBP&ch=berichte&events=prodView%2Cevent7%2Cevent2&products=%3Bb130228%20-%20Liverpool&c1=DE&v1=berichte%3Ab130228.php&v2=D%3Dc42&c6=berichte&v6=D%3Dc6&c9=b130228.php&v9=D%3Dc9&c10=b130228%20-%20Liverpool&v10=D%3Dc10&c11=article&v11=D%3Dc11&c14=D%3Ds_vi&c15=9%3A00AM&v15=D%3Dc15&c16=Tuesday&v16=D%3Dc16&c17=Weekday&v17=D%3Dc17&c18=%3C%200.5&c19=D%3Dc18%2B%22%3A%22%2BpageName&c20=hph&v20=%2B1&c23=Blog%20View&c24=1033&c25=D%3Dc40%2B%22%3B%22%2Bc41&v25=D%3Dc25&c26=D%3Dc41%2B%22%3B%22%2BpageName&v26=D%3Dc26&c27=D%3DpageName&c28=Less%20than%207%20days&v28=D%3Dc28&c33=7&v33=D%3Dc33&c38=home&c40=home&c41=http%3A%2F%2Fwww.jan-exner.de%2FBerichte%2Fb130228.php%3Fic%3Dhph&c42=undefined&c45=unset&v45=D%3Dc45&h1=top%7Cberichte&s=1920x1200&c=24&j=1.8.5&v=N&k=Y&bw=1050&bh=631&p=Shockwave%20Flash%3BiTunes%20Application%20Detector%3BGoogle%20Update%3BAdobe%20Acrobat%3BAdobeExManDetect%3BPicasa%3BInforbit32Ex%3BInfotriever%3BMicrosoft%20Office%202010%3B&pid=home&pidt=1&oid=berichtlisteh1&oidt=1&ot=A&oi=1&AQE=1


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:

http://om.jan-exner.de/b/ss/jexnertest,jexnerrollup1/1/H.25.4/s51094577372802

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.112.2o7.net, 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.

The 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.

The tiny 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.

The H.25.4 is the version of the Javascript library. If you are tracking with one of the AppMeasurement libraries / SDKs, that value will be different. It will always contain a version, though. As an example, the Android library v1.2 would transmit JAVA-1.2-AN.

Finally, the 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.

Data

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.

• AQB=1 & 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.
• ndh=1 – set to 1 by the Javascript core library. Essentially tells the collection servers that this call has been made by Javascript (as opposed to a hardcoded call or some other way of tracking)
• 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.
• g & r – the URL and HTTP referrer of the page that is being tracked. You can overwrite r by setting s.referer.
• oi, ot, pid, pidt, oid & 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 s_vi cookie.

You can see a lot more parameters on the URL above: pageName of course, a lot of cX & vY parameters representing propX & eVarY, events, 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.