(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
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
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
As an example: my blog uses
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…
- 3rd-party — the easiest in terms of setup. All you have to do is set the “Tracking Server”. Leave “Tracking Server Secure” empty!
- 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.
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 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.
9 thoughts on “Quick tip: Tracking Server & SSL”
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.)
Why, thank you!
It’s good to have feedback! Especially good feedback 😉
Very clear article!
Somewhat inspired by a recent call, as you might have guessed 😉
For 3rd party you say to “Leave “Tracking Server Secure” empty!” (with an exclamation mark)
I just checked our implementation, and sure enough… we are 3rd party and whoever implemented populated “tracking server secure” with [our domain].sc.omtrdc.net
Is that something I should remove? Would it be causing tracking problems? Why the explanation mark on your warning?
LikeLiked by 1 person
Sorry… why the EXCLAMATION mark on your warning?
I usually put an exclamation mark on things when I have stumbled over them at some point, sort of like making it really obvious for myself.
If you put the same thing into both, trackServer and trackingServeSecure, then you should be fine. As far as I know, the effect is the same as if you leave trackingServerSecure empty.
In the olden days, when we tracked against 2o7.net, we had different servers for HTTPS and HTTP. That is no longer the case with omtrdc.net, hence my advice.
But your setting should work just the same.