The Definitive Guide To First-Party Cookies In Adobe Analytics
Death of the 3rd party cookie is imminent and with Google’s decision to delay blocking of 3rd party cookies in its widely popular browser Chrome, has given marketers the much-needed time to rewire their implementations. Google Chrome, commanding about 70% market share (2021, Desktop as per netmarketshare.com) is an important part of the web analytics equation. Below is a quick comparison of the cookie pool and timeline.
In this article, we are going to cover how cookies influence your web analytics. We have compiled a guide with foundational steps to make your analytics implementation robust and examine the implications of a 1st party universe. We would be focusing on “Adobe Experience Cloud” solutions like “Adobe Analytics” and “Adobe Experience Platform” in this article.
If you are looking for an overarching strategy, insights related to audience sharing, and tactics that brands can take to embrace this shift, refer to this detailed article here.
How Cookies Influence Your Analytics?
Your Adobe Analytics implementation heavily leans on cookies. Many brands only think about advertising and audience sharing when we talk about 3rd party cookies. They seldom think about their analytics implementation, as cookies are hidden beneath multiple layers. In your Adobe Analytics implementation, cookies dictate the below:
- Visitor identification on the site and across domains
- Persistence of data like across sessions (Ex: campaigns, traffic sources)
- Computation of stitched customer profiles
How Are Cookies Created in Analytics Implementation?
Cookies are typically set using two methods. #1 JavaScript code (client-side) by your tracking library (AppMeasurement or HCode/s_code.js) and #2 using HTTP headers (server-side). Regardless of the method, a cookie needs to be set under a domain. Depending on the domain, it is classified as 1st (same domain as the website), or 3rd party (different domain).
Once this cookie is set, a random ID is set to identify the visitors, which is sent in every beacon call to Adobe Analytics. This data is sent to (Adobe) server at a specific address. This is called as the “Tracking Server” (or ModStat) which is nothing but an end point to collect analytics data. The random ID is valid for 2 years on a rolling basis (except for safari browsers where it is only valid for 7 days).
This “Tracking Server” address can be something like “<your-site>.112.2o7.net” or “<your-site>.sc.omtrdc.net”. But this address can also be customized like “<your-site-name>.metrics.com” or “<your-site-name>.data.com” which is more friendly and will not be blocked by ad-blockers. This approach is done by creating a type of alias at the network level called a “CNAME”.
Generally, you work with your web/network team to accomplish this. The CNAME points to an Adobe end point like *.112.2o7.net or *.sc.omtrdc.net, but this will not be explicitly visible. A CNAME plays an important role in your Adobe Analytics implementation. Adobe recommends using a CNAME as a global best practice.
Guide for Identifying, Assessing, and Planning for Migration
Depending upon your technical architecture and the implementation method, you could be in the any of the below three buckets. Talk to your web/analytics dev team to know about the version or implementation method.
Bucket #1: H-Code or Pre-VisitorAPI.js ID Implementation
If you happen to be in this bucket, then you might be using Adobe Analytics as a standalone solution. Here a cookie named “s_vi” (vi – visitor identification) is used to identify the visitors. These cookies can take both 1st party or 3rd party avatars depending on the tracking server that you are using.
How to Identify the Type of Your Cookie?
- It depends on the “Tracking Server” settings present in the “HCode (s_code.js)” or the “AppMesurement” library (initial versions of Adobe Analytics tracking library without VisitorAPI.js).
- If your “Tracking Server” ends with “<your-site>.*.2o7.net”, then your analytics is implementation is powered by 3rd party cookies. You can also check the domain of the “s_vi” cookie using the Chrome developer tools (under “Applications” tab) and it will be set under “*.2o7.net” indicating that it is a 3rd party cookie.
- If your “Tracking Server” ends with “<your-site>.metrics.com” or “<your-site>.smetrics.com”, then your analytics uses 1st party cookies. (This is when you use CNAME as discussed above).
- If you check the domain of the “s_vi” cookie using the Chrome developer tools (under “Applications” tab) and it will be set under your site’s domain, which makes it as 1st party.
What Should Be the Next Steps if I Am in This Bucket?
- This is a legacy method of visitor identification, and you should migrate as soon as possible regardless of your expansion plans. Here are possible plans and the next steps:
About Nextrow
NextRow Digital is an Adobe Silver Partner and an expert in implementing Adobe technologies. We have the right skillsets and processes to support your complex needs ranging from IT teams to marketers. Grow your business with the help of Adobe Analytics experts at NextRow!
To learn more about our Adobe Experience Platform offerings, visit our website.
To learn how NextRow can help with Adobe Analytics assessments, planning and integrations, contact us at +1-847-592-2920 or marketing@nextrow.com.
Bucket #2: VisitorAPI.js Implementation or “Adobe Experience Cloud ID Service”
Many of you would be likely in this bucket. This enables Adobe Analytics to be used as an integrated solution with Target, Audience Manager etc. An additional library (VisitorAPI.js) or an extension in Adobe Launch is required to implement this. It uses a 1st party cookie named “AMCV_{YOUR-ORG-ID}” where the visitor ID (called “ECID”/“MID”) is stored and used in analytics calls. This cookie is always set in the 1st party domain.
But this service also uses a 3rd party cookie named “demdex” which houses a 3rd party ID called the “UUID”. The “UUID” is used by Adobe to identify users across domains and across the entire web. The “UUID” is synced with advertising solutions like Google, TradeDesk to target users across the web. The “ECID” is used in internal Adobe solutions.
Example, if your business owns two sites, www.cars.com and www.bikes.com, then a person browsing the sites (from same browser) is identified the same across both domains (thanks to the 3rd party cookie accepting Chrome browser!). The actions taken by the visitor on both sites can combined and used for targeting the visitor precisely across the internet (here it sounds a little creepy!). With the sunset of 3rd party cookies, you will not be able to do this!
How to Identify the Type of Your Cookie?
- Here, irrespective of your tracking server settings, the AMCV cookie (main visitor id cookie) is always set as 1st party cookies.
- The demdex (cross-domain id) cookie is always set as 3rd party cookie.
- If you are using a CNAME, then the only difference is the cookie is set using HTTP headers (server-side).
- You can check the domain of the cookies using the Chrome developer tools (under “Applications” tab).
What Should Be the Next Steps if I Am in This Bucket?
- Cross-domain tracking and advertising use cases based on 3rd party cookies would be worst hit in this bucket. There would be visitor count and profile rests when Chrome rolls out the update. Preparation and planning are recommended. Here are couple of options to minimize the impact:
Bucket #3: Implementing Futuristic Adobe Experience Platform
You should consider yourself lucky if you are starting here. Possibly you are starting anew with customer analytics or trying Adobe Experience Platform in a new site/LOB. Here the data collection is powered by an open library called “alloy.js” and available as “Web SDK” extension in Adobe Launch (Tags).
Visitor identification is powered by “Adobe Identity Service” which is the evolution of the previous service that we saw. This brings the focus only on 1st party tracking. 3rd party cookies and tracking are not enabled by default (but available as an option for those who still want to use it).
From here there is only one way to go, which is “strengthening your first-party strategy”. Let’s have a look:
Key Factors to Consider During Migration
Visitor Identification in analytics can be a complex task and especially with 3rd party cookie sunset around the corner, it is imperative to understand the details for better planning and migration. Below are some of the key things to watch out if you are planning for migration, irrespective of the bucket:
Visitor Migration
If you are changing anything related to visitor identification, you need to enable “ (a.k.a grace period)” to prevent visitor cliffing (a visitor id reset for all your visitors). Failure to do so will have ramifications in visitor reporting and profiles which are irreversible.
Ad-Blockers
If you are using a CNAME, then chances of your tracking calls blocked by ad-blockers and other privacy solutions are almost negligible. On the other hand, a 1st party implementation without a CNAME would take a hit.
Apple ITP
With ITP 2.0, safari browsers in desktop and mobile have a cookie expiration period of 7 days. This is true if you use a CNAME as well. When you use “Adobe Identity Service”, you have the option to Bring-your-own-ID which could potentially help you to circumvent the 7-day expiry.
Cross-Domain Tracking
This is a sticky wicket, especially with the sunset of 3rd party cookies. Start leveraging the services to start building the ID syncs now so that there are no big surprises when the time comes.
Privacy
User privacy and choices should be respected at any cost. Even though this is not in the scope of this article, it is imperative to call this out explicitly and Adobe services do a good job of providing tools for implementing this. Please check the respective documentation for details.
CNAME
This is a recommended global best practice to get maximum value from your analytics data. Adobe runs a managed certification program, which is free for Adobe customers to encourage migration to CNAME based tracking.
Conclusion and Next Steps
It is time to have a look under the hood and determine the next steps. Like we discussed above, this much needed time can be used for technology planning, implementation and change management which are the clear ways to stay ahead of the game!
