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 3rd-party cookies, or do I want the tracking calls to seemingly go against my own domain (and therefore have 1st-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. 3rd-party — the easiest in terms of setup. All you have to do is set the “Tracking Server”. Leave “Tracking Server Secure” empty!
  2. 1st-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 3rd-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 1st-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.

[screenshot]
Tracking works as expected
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.

[screenshot]
Copy request URL
[screenshot]
Tracking failed due to certificate issue
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.

[screenshot]
Tracking is good
If you’re using 1st-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 2nd and 4th Thursday every month, but your CSM or Customer Care can tell you more.

4 thoughts on “Quick tip: Tracking Server & SSL

  1. Jan, I appreciate your viewpoint and these articles. I’ve been reading your articles for years and I thought it was about time I let you know, rather than simply be one of your many email open counts and site unique visitor counts. (I also show up as a “bounce” single page visit whenever I reread any of your dozens articles I have bookmarked for reference.)

    Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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