Edge Nodes, Data Centres & other Updates

(aka: the URL is ok like that)

In the context of ageing of technical information, obsolete blog articles, and “updating for success”[tm], this is a follow up to the 2013 article Data Centres, which really is out of date by now.

It extends and partly supersedes other articles, such as Debugging – the URL, or Cookies, IDs, and the Experience Cloud (this one not so much, but it has a great example of my crystal ball skills in it, so I must mention it).

It will also be obsolete in due course, but for now, you can trust this one.

“Reports & Analytics”

In the original postings, I mentioned some things that have different names today, or that have been superseded by something better.

First: there is no really good reason to use the “Reports & Analytics” UI anymore. Virtually everything that you would want to do with Analytics can and should now be done in a “Workspace.”

My colleagues in product management and engineering have done stellar work on Workspaces, I think, and if you follow Jen Lasser and/or Ben Gaines, you’ll see they are far from finished.

So: use Workspace!

Data Centres

In 2013, I told you that Adobe Analytics data was distributed across a bunch of data centres (4, to be precise). That was in 2013. The DCs in San Jose and Dallas have since been decommissioned, and we got a new one, somewhere in Oregon in the USA.

At the time, I wrote “You can easily find out where your data is.”

That is no longer true, at least not the “easily” part.

The original DCs had specific URLs, but these days, they do not really matter anymore. Just looking at the URL of the Reports & Analytics interface in your browser will tell you if you’re on the London DC (“www3.omniture.com” or “sc3.omniture.com”), but rumour has it that this URL will change.

In Workspace — the UI that you really should use for Analytics — you can’t see it at all.

Does it matter as much as it did? I think, technically, it doesn’t.

It may or may not matter legally, of course.

Regional Data Collection & Tracking Servers

All tracking in Analytics uses “Regional Data Collection” (RDC) these days.

For you as an implementer, that means your tracking server will be pretty simple: <company>.sc.omtrdc.net

As an aside, the URL for your Target edge server is similarly simple: <clientcode>.tt.omtrdc.net

No more something.102.2o7.net, somethingelse.d3.sc.omtrdc.net or somesuch.

Even if your tracking server setting points to an old-fashioned address like that, it will still be routed via RDC, meaning the tracking calls will go to the geographically nearest node, which will forward them to whatever your DC is.

You heard that right: the d3 (or d1, or d2) part of the tracking call URL is not necessary.

But you can still filter for b/ss when you are looking for Analytics tracking calls.

And I learned that the “ss” stands for “SuperStats”, the name of SiteCatalyst Analytics before it all became a thing.

I also learned today that the “b” stands for “beacon”. That makes sense!

The whole s.dc/s.trackingServer setup is now a lot easier, because most people do that setup in Launch, rather than using some variables in the s_code.js or AppMeasurement.js file.

Edge Nodes

For Target, visitors’ browsers communicate with so-called “edge nodes” around the world.

As with RDC, the browser will try and connect with an edge node somewhere close. All of those edge nodes listen to the same name (<clientcode>.tt.omtrdc.net), but if you look at the reply for your Target calls, you can now see which edge node actually answered.

If you’re using at.js v2, it would look like this:

Why would you need to know? Well, sometimes, edge nodes are not updated as quickly as you’d like them to be, which means when you debug Target, it might make sense to look at which edge node you’re on. Most times, you probably won’t care.

Debugging — the URL

There are now things in the Analytics tracking call URL that weren’t there in 2013. And sometimes, the URL doesn’t contain any data at all!

I wrote it above, but a reminder: the FQDN should and will almost always be of the form <company>.sc.omtrdc.net if you’re on 3^rd-party cookie tracking, or something you defined yourself (like om.jan-exner.de), if you’re on 1^st-party cookies.

The /b/ss/ stays, as does the number after that. But you’ll often see a 10 rather than a 1.

If you see a 10, then “server-side forwarding” is enabled and working, meaning Analytics sends all captured data straight over to Audience Manager.

The Report Suite IDs stay where they were, and so does the version. If you are using DTM or Launch to deploy Analytics, the version will have two parts, though, such as in this call:

https://ags055.sc.omtrdc.net/b/ss/ags055jeprod/10/JS-2.17.0-LAQ5/s78490806159886?AQB=1&ndh=1&pf=1&callback=s_c_il%5B1%5D.doPostbacks&et=1&t=20%2F6%2F2020%2013%3A25%3A46%201%20-120&d.&nsid=0&jsonv=1&.d&sdid=0B00972445E4E686-5F0C1715B59E1220&mid=67434125277890687802580641147116240113&aamlh=6&ce=UTF-8&pageName=bikes&g=https%3A%2F%2Fwww.jan-exner.de%2Fbikes&r=https%3A%2F%2Fwww.jan-exner.de%2Fbikes%2Ftaival&cc=CHF&ch=bikes&events=event1&aamb=j8Odv6LonN4r3an7LhD3WZrU1bUpAkFkkiY1ncBR96t2PTI&v3=default&c4=D%3Dv4&v4=Jan%20Exner&v6=default&s=1500x1000&c=24&j=1.6&v=N&k=Y&bw=710&bh=852&mcorgid=BE5121AA565821017F000101%40AdobeOrg&AQE=1

The JS-2.17.0 is the Analytics code version, whereas the LAQ5 is the version of “Turbine”, the code generator behind Launch.

You can still see the random number starting with an s.

And why would you sometimes see no data on the URL at all?

Internet Explorer used to have a limitation on the length of a URL. It would not load any content if the URL was 2049 characters or longer. To work around that, the Analytics Javascript sends very long tracking calls as POST requests (which IE can do), which means the content is payload, not URL parameters.

And that’s it for this update, happy analysing!