Quick Tip – Debug server-side manipulations of the tracking call

I guess this post is pretty specific. It might have a target audience of a dozen or so. I hope the rest of you forgive me, but keep on reading, you might need this one day!

Setup

At a Swiss financial institution, we implemented an “internal visitor” detection using their reverse proxy. They are routing all tracking calls through a proxy in their own data centre so they can anonymise beyond what Analytics offers.

(Swiss financial institutions follow the rule that the IP address of a visitor to their site is PII and can therefore not “leave Switzerland”.)

So because they used a proxy anyway, we simple amended the setup to amend the tracking calls with a “c75=internal” if the visitor was inside their network, enabling them to segment internal versus external visitors easily.

So how on Earth do you test something like this?

Test

You can’t test it client-side, because the tracking request is amended after the browser has sent it out, right?

Actually, you can!

Have you ever seen a tracking request that came back with an HTTP status 302?

When someone comes to a tracked site for the first time ever, their first tracking call will not come with a visitor ID, because the system hasn’t had an opportunity to set one yet.

So the tracking servers reply with a 302 HTTP status, piggyback an s_vi cookie on top of that containing the visitor ID, then see whether the new call comes back with the cookie.

This accomplishes two things:

• the system can set a tracking cookie, or
• it can detect that setting a cookie failed

This is standard behaviour for Analytics, it has done that since the very early days. And it turns out that we can use it to debug modifications of the tracking call!

The 302 HTTP status obviously comes with a new URL that the browser should hit. That new URL happens to be the old URL with an added parameter that essentially tells the system “we’ve tried to set the cookie, don’t try again”.

That means: we get to see the tracking call that actually arrived at the tracking servers. And that call does include the modifications we made on the proxy!

Ha!

So, all you need to do is three steps:

• delete your cookies for the domain you’re testing,
• hit the site and watch the tracking call go out,
• note the 302 response and check the URL: does it include the things you added on the proxy? Does it have “c75” on it?

And that’s all there is to it.

Notes

Now obviously this technique has limits. It only works for modifications made between the browser and the receiving tracking server in one of the Adobe Analytics data centres.

That means it does not work for VISTA Rules or Processing Rules. For those things, you still have to use the good old “check the data” approach.

The other question is: should you actually modify tracking calls on your proxy? Is there any risk?

And the answer is yes, there are risks.

For one, modern tracking code (AppMeasurement.js) deals with the URL length limit imposed by some versions of Internet Explorer by sending very long tracking calls via POST rather than GET requests.

For those POST requests, the transparent proxy approach would likely be a bit too complicated. As long as you segment on Visit or Visitor level, it doesn’t matter, of course.

The other, much smaller, risk is that one day, the format of the tracking calls might change. I cannot say how much of a risk that is, but with the current install base out there, I think it is bordering on non-existent.