How Adobe Target Uses Cookies in Web SDK (alloy.js)

[#1]

by @chrismdavis  & @surebee 

Introduction

This post is meant to be a companion to a previous post on the impact of third-party cookie deprecation on at.js implementations. With Web SDK (alloy.js) being the future of Adobe Experience Cloud implementations, having a similar guide felt to be beneficial to the Target community. One big advantage of the Web SDK is that it does not rely on third-party cookies, which are planned to be deprecated by Google.*

... *(at least they were when we started writing this post)

Cookies Set by Web SDK

The key difference between Web SDK and legacy implementations of Experience Cloud solutions can be boiled down to one word: unification. Legacy implementations all rely on individual JavaScript libraries for each solution (e.g., at.js for Target, AppMeasurement.js for Analytics, Visitor.js for ECID Service, DIL.js for Audience Manager). Each library also has its own specific cookies associated with it. In a Web SDK implementation, solutions are enabled via a single JavaScript library (alloy.js). For the most part, these solutions all rely on the same cookies set by alloy.js, with some solution-specific exceptions.

Platform Level Cookies Used by Web SDK

Web SDK uses an orchestration layer called Konductor to forward requests from the Web SDK to upstream services, like Analytics, Target, and Audience Manager. The information from the different Adobe applications requested upstream are consolidated into a single response. Here's a breakdown of the various cookies that Konductor uses to make this all happen:

Cookie Name	First-Party	Third-Party	Usage
kndctr_{ims_org_id}_AdobeOrg_identity	✓	✕	Stores ECID and related information
kndctr_{ims_org_id}_AdobeOrg_consent_check	✓	✕	Signals server to look up user's consent settings on server side
kndctr_{ims_org_id}_AdobeOrg_consent	✓	✕	Stores user's consent settings on client-side
kndctr_{ims_org_id}_AdobeOrg_cluster	✓	✕	Stores Edge Network region serving the user's requests.

Target-Specific Cookies Used by Web SDK

These Target cookies will only appear if your implementation has the Web SDK's Target migration setting set to true or when the ECID Service migration idMigrationEnabled setting is set to true.

Cookie Name	First-Party	Third-Party	Usage
mbox	✓	✕	Target migration, contains IDs used by at.js implementations to facilitate migrations to Web SDK
mboxEdgeCluster	✓	✕	Target migration, helps facilitate migrations to Web SDK while keeping Target profiles in sync on at.js endpoints
AMCV_{ims_org_id}@AdobeOrg	✓	✕	idMigrationEnabled, used to facilitate migrations to Web SDK when legacy solutions have ECID Service (Visitor.js) in play, at.js relies on this library when Customer IDs are passed to Target requests by Visitor.js

Viewing Web SDK Cookies In Your Browser

You can view these cookies by opening your browser's developer console on a page running the Web SDK and navigating to Application > Cookies (dropdown menu) > yourdomain.com where you will see the cookies above (you will likely only have some of these cookies, depending on your implementation, not all of them are necessary for every implementation's use cases)

Example of some of the above cookies

Cross-Domain Tracking

At this point, you might be wondering, Web SDK doesn't leverage 3rd-party cookies – so, how can we track users across domains like at.js can be configured to do? Web SDK can share IDs in a couple of ways. For client-side web implementations, the methods to achieve this can be using the appendIdentityToUrl command.

Apple ITP Specific Considerations

Since the Web SDK cookies are placed client-side via the document.cookie API, all Web SDK cookies including Target specific ones continue to be impacted by Apple’s ITP 2.x policies per below, you can see the times these are shortened from here. Note that it is a fairly substantial reduction in some cases.

ITP Version	Release Date	CNAME Implementation	Max Age
2.1	Feb 2019	✕	7 Days
2.2	Apr 2019	✕	1 Day
2.3	Sep 2020	✕	1 Day
2.3	Sep 2020	✓	7 Days

CNAME Implementation Considerations

*Note: It is recommended to have a CNAME implementation to handle ad-blocking issues on your site. The CNAME set up with Web SDK is greatly simplified as it happens in one place and is applicable to all Experience Cloud solutions, without needing to do separate set ups for each solution.

As a result, Safari visitors to sites with Target implementations (using Web SDK) are impacted to the same extent that they would be in a legacy Target implementation in the ways shown below:

Affected Functionality	Impact
mbox Cookie Lifetime	Shortened Lifetime
Reporting	Increased Unique Visitor Counts
Visitor Profile and Activity Membership	Decreased Lookback Period

Last Thoughts

We hope this post has given you a greater understanding of how Web SDK implementations of Target leverage cookies set by the Web SDK, you can also reference documentation on Experience League or check out the rest of the Target Experience League forum for more info, tips, and tricks for your Adobe Target implementation!

***

Are you looking to optimize your website's performance and drive conversions?
Look no further than Adobe - the industry leader in A/B testing. With more A/B tests under our belt than any other organization in the world, we have the expertise and knowledge to take your online presence to the next level. Adobe Target is unrivaled in the industry, and with Adobe Consulting, you can have access to this powerful tool and the expertise behind it. Don't miss out on the opportunity to unlock the full potential of your website. Contact us today and discover how Adobe can help your business thrive. If you would like to understand how Adobe can help your business reach out to Adobe Professional Services.