Debugging – the URL

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:,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&

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:,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 (, but it can also point directly to the Adobe tracking servers (, 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.


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.


German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Posted in Javascript, Principles
16 comments on “Debugging – the URL
  1. […] actual tracking call being made. You will notice the characters “/b/ss/” in the call URL. What comes next is the […]


  2. […] we can see looking at the tracking call in a debugger, this call transports the pageName, props, eVars and three events ‐ prodView, […]


  3. […] then use your favourite debugger and check the data being sent in the tracking call by looking at the URL — really not that different from how you would debug on the […]


  4. […] mentioned in the articles about the URL & the configuration part of the s_code.js file, tracking calls can now go to […]


  5. […] I have tried to explain what the URL looks like in the articles about debugging here, here, here, here & especially here. […]


  6. […] can check whether you’ve done it right by looking at the URL of the tracking call that your browser makes. If you can see your list of rsids then everything […]


  7. […] (tl;dr — best way is to look at the URL) […]


  8. […] Usually, troubleshooting web analytics is relatively easy. Because it all happens in broad daylight, you can check what a site is tracking using a debugger. Just look at the URL. […]


  9. […] you can very easily see what happens, which makes this the perfect spot to debug by looking at the URL (do I have to repeat that I use Charles for that? Or did I mention that […]


  10. […] how you can actually see the tracking request in there? The full URL is right there! […]


  11. […] create a “tracking beacon”, essentially a GET request with various parameters in the URL that’ll return an empty image. That’s why this “beacon” is often called an […]


  12. […] you looked at the URL of a tracking request the last time, did you see how long it was? A thousand characters are not […]


  13. […] There are a couple of moving pieces in this machinery you just built, meaning you should test it until your dreams are filled with cookies, plugins and form elements. You do remember how to debug, don’t you? Look at the URL! […]


  14. mitchellt2 says:

    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…?


  15. […] can easily find rsid and tracking server by looking at the URL of any tracking call. See Debugging – the URL for […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: