Quick tip: Tracking Server & SSL

(I mentioned two weeks ago that I sometimes blog because I want to learn and/or remember things. This is one of those articles.)

Whether you are a regular reader or just generally interested, I’m sure you know that most (if not all) analytics tools these days work by sending “tracking calls”, “hits”, “beacons”, or whatever you want to call them. They are usually simply GET or PUT calls to some cloud infrastructure.

In the Adobe Analytics universe, we call them “tracking calls”, and they are sent to “tracking servers”, of which in our case there are currently some in the US, in EMEA, and in Singapore. Some DNS trickery makes sure a visitor’s browser always tries to send the tracking calls to whichever tracking server is closest.

So far, so good.

Ch Ch Ch Changes

The details behind the tracking architecture have changed a lot since I joined Omniture in 2008. At the time, there were two data centres (San Jose and Dallas), and you had to specify which one “was yours”.

Then along came Regional Data Collection, and we moved from 2o7.net to omtrdc.net. The latter brought with it the DNS trickery I mentioned before and also separated tracking from processing.

Then things got simpler in 2014: all report suites from that point on have unique IDs, so it was no longer needed to specify the data centre at all, leading to universal tracking server settings of the form [my domain].sc.omtrdc.net.

As an example: my blog uses adobeags055.sc.omtrdc.net.

Implement

If you implement today, be it via Javascript alone (really?), using a tag manager, or an SDK, you have to make one single choice:

Do I want standard 3^rd-party cookies, or do I want the tracking calls to seemingly go against my own domain (and therefore have 1^st-party cookies)?

The question is fortunately no longer as big a decision as it used to be, mainly because with the People Core Service, you can get around some of the limitations of standard tracking. But there are other reasons, so…

1. 3^rd-party — the easiest in terms of setup. All you have to do is set the “Tracking Server”. Leave “Tracking Server Secure” empty!
2. 1^st-party — involves more work. It’s recommended that you enroll in the Adobe Managed Certificate Program, wait while Customer Care do their part, implement the two CNAMES they give you (on your DNS server!), and then set both, “Tracking Server” and “Tracking Server Secure” to whatever you set up in your DNS.

The Correctly populate the trackingServer and trackingServerSecure variable article in the help section has some more information. Note that the important bits in the notes are indeed important.

Troubleshooting & onwards

Since most web sites these days are served via HTTPS (as opposed to HTTP, and if yours is not, it really should be!), tracking calls, too, have to be using HTTPS.

That matters because with HTTPS, browsers will check certificates.

For 3^rd-party cookie tracking, there should be no problem.

The tracking requests go against an Adobe-owned infrastructure, which comes with certificates and everything.

However, if you have so far only tracked HTTP pages and are used to the systems being pretty relaxed regarding the FQDN of your tracking calls, you’ll have to re-learn. The certificate is for *.sc.omtrdc.net, which is why the tracking server has to be like shown above.

For 1^st-party cookie tracking, the Adobe servers have to be able to reply with a valid certificate for your domain. You can either procure certificates yourself (10 licenses currently), or use the Adobe Managed Certificate Program mentioned above.

So how do you know certificates are in place? Or what if you think they’re not?

The easiest way to check whether everything is good is to deploy on a test page, then load that page. If the tracking works (you’ll see an HTTP status 200 in your browser’s network tab), all is good.

If instead of the status 200, you see something like “failed”, copy the tracking call — the complete URL, paste it into your browser address box, hit enter.

In my case, the tracking server is wrong (there’s an extra “ssl.” in there). Fixing the URL (removing the “ssl.”) also fixes my issue.

If you’re using 1^st-party tracking, you’ll likely get the same error, but the solution is different (that is if you’re 100% sure your tracking server is correct!): wait for the certificates to be in place on the Adobe infrastructure. This used to always happen on every 2^nd and 4^th Thursday every month, but your CSM or Customer Care can tell you more.