Expand my Community achievements bar.

Join us January 15th for an AMA with Champion Achaia Walton, who will be talking about her article on Event-Based Reporting and Measuring Content Groups!

Tracking server in Adobe Analytics ExTags

Avatar

Level 1

I have observed that tracking server and secure tracking server in AA Extension in Tags is left blank. The beacon is still being sent to 

 https://mydevreportsuite.112.2o7.net/b/ss

Wondering if that is the way to configure the tracking server for third party domain implementation? For first party cookie implementation the tracking server looks like (https://metrics.mydomain.com/b/ss/)

Please suggest the the best practices on tracking server for adobe analytics implementation using Web SDK and AA Extension.

Also share your thoughts on best practices for AA implementation on a newly launched web site created via AEM.

 

 

 

 

8 Replies

Avatar

Level 4

Even through possible and there might be good reasons to do so, there is no need to run the AA Extension with Web SDK, as Web SDK is capable of sending data to Analytics by itself without using any other Extensions (such as Visitor ID Service). This also removes the questions regarding hostnames for data collection, as all calls are sent through AEP Edge Network: Adobe Experience Platform Web SDK and Edge Network overview | Adobe Data Collection

 

The other part: Adobe Analytics uses its legacy cookie (s_vi) and Visitor ID Service uses the demdex cookies on third party domains if CNAME method is not being applied in addition to first party domains. You can populate the values yourself in Tags if the defaults are not correct or if you're using the CNAME method. More on the cookie lifetimes and so on here: Adobe Analytics and browser cookies | Adobe Analytics

 

Personally I would recommend switching over to Web SDK fully, for multitude of reasons, first party cookies being one. Others are speed, unified library and data sending methods, being actively developed and improved and support for nearly all Adobe's implementation scenarios.

For AEM I have limited experience, but if you're using the ACDL that comes with it, pushing events to data layer should be a breeze and from there on it doesn't differ much from other implementations.

Avatar

Community Advisor and Adobe Champion

Yes, the Tracking Server and Tracking Server Secure are how you set your tracking server to your first party tracking server:

 

Jennifer_Dungan_0-1732805440917.png

 

You will also want to set this in your Experience Cloud ID Service:

Jennifer_Dungan_2-1732805738395.png

 

 

 

 

As for switching to WebSDK... while I agree on the points about the server-side cookie... there are a lot of debates about this topic... WebSDK comes with it's own set of complications, and if you aren't planning on sending data to other systems like CJA, the effort may not be worth it yet...  

 

If you already are using the client side tracking and need a quick win for first party cookies, changing your Tracking Server is an easy and low risk step that you can take.

 

 

 

As for a newly launched site on AEM.. the technology you use Client Site (AA Extension and AppMeasurement.js) or Server Side (WebSDK and Alloy.js), that is up to you... However, whether the site is AEM or other, I recommend working with your developers set up a proper Data Layer for getting the information that you need available. While AEM does have an analytics integration, I never found it worked all that well... but you might have better luck (however, what it provides is rather limited, so you would likely want more information than the out of the box connection provides anyway)

Avatar

Level 1

Thanks Jenifer..that helps!

 

The Tracking Server and Tracking Server Secure are how we set the tracking server to first party tracking server.

What if these config items are left blank? In that case the tracking server will be any default one and will be third party tracking server? I have observed this in one of the implementation - the tracking server left blank in Tags show like https://mydevreportsuite.112.2o7.net/b/ss in beacon. Your thoughts? 

 

Avatar

Community Advisor and Adobe Champion

I would assume leaving it blank would fall back to the 112.2o7.net third party variation if the settings are left blank... it's better than failing outright...  if the values aren't set, Adobe would have no clue what server they should use...

 

However, I have never left this value blank... if you are seeing a fallback to the "suite" default server, then it's likely that will happen in other cases... but I would recommend not trying to rely on that too heavily... just in case.

Avatar

Level 1

Thanks Jenifer again for your input.

 

eager to know some of the adverse impacts we may have on adobe analytics tracking with third party domain for our data collection server.In other words why first party domain is preferred over the hird party domain?

Avatar

Community Advisor and Adobe Champion

Some of the big factors are if you use first party cookies, you will set first party cookies.

 

Mind you, some of the cookies set are done via JS, some are done via the server... the server-set cookies will have a bit more authority. But at least on browsers like Safari, with the proper settings (first party, secure, etc) the cookies should last 7 days (as opposed to the third party cookies which can get wipes out by some browsers after 24 hours).

 

None of these cookies are as good as actual "server cookies" which are stored on the server instead of the user's browser (i.e. WebSDK), but any improvement is an improvement.

 

The other thing is that the 112.2o7.net server is that the files and tracking are a little less likely to be blocked by various tools, extensions and browsers directly... this is not 100% by any means... but the 112.2o7.net is a known tracking domain, and thus more likely to be blocked...  however, some tools look at patterns in the URLs and still block calls with /b/ss/ which will still exist when using your own tracking server....

 

One last thing, is just from a "resource request" perspective, having your tracking specific to your own server gives it a bit more "authority".... for that matter, in our org, we also host our Launch files locally (and not use the assets.adobedtm.com server)... but this does take a bit more effort. The tracking server is much easier.

 

Seeing as how first party tracking servers, and the SSL for them is a service provided by Adobe (and is technically included in your costs), I am not sure why anyone would choose to not use first party tracking servers.

Avatar

Level 1

Hi Jenifer ,I am still confused to list down the drawbacks of using the third party tracking server.Self hosting the analytics libraries has nothing to do with the tracking server. Can you help me compare both the approaches to tracking server ( third party tracking server vs first party tracking server)

Avatar

Community Advisor and Adobe Champion

All of my points except for 

for that matter, in our org, we also host our Launch files locally (and not use the assets.adobedtm.com server)... but this does take a bit more effort. The tracking server is much easier.

were specific to the Tracking Server, and the Tracking Server alone....

 

 

  • Cookies
    • Cookies set by the tracking server will be set to domain when using First Party Tracking Server
      • Example, the ECID is set by the server for your server, which gives it more authority 
    • Third party cookies will be set against the .2o7.net domain, first party cookies will be set against yourdomain.com
    • Third Party Cookies will be deleted after 24 hours by browsers like Safari, first party cookies will live for 7 days
  • Blocking (or potential blocking)
    • The 2o7.net is a know tracking server... this will be in almost every single blocking method out there
    • Tracking servers from your own domain will not have the same heavy handed approach (however, blockers that use pattern recognition for "b/ss" will still end up being blocked.... 
    • Having the tracking from your own server (yourdomain.com) gives it more authority as being a "part of your site"