at.js cookies
Information about at.js 2.x and at.js 1.x cookie behavior.
at.js 2.x cookie behavior
For at.js version 2.x (up to, but not including, version 2.10.0), only first-party cookies are supported. Just like in at.js 1.x, the first-party cookie, “mbox,” is stored in clientdomain.com, where clientdomain is your domain.
at.js generates a session ID and stores it in the cookie. The first response contains any activity information, as well as the TNT or PC ID generated by the Target servers. at.js then writes the TNT/PC ID to the cookie.
The AMCV_###@AdobeOrg first-party cookie is always set by the Experience Cloud ID Service, although the ECID is passed in Target requests.
Support for third-party cookies and cross domain tracking
Cross-domain tracking makes it possible to see sessions on two related sites, but with different domains, as a single session. You could create a Target activity that spans siteA.com and siteB.com and the visitor would remain in the same experience when they crossed domains. This functionality ties into at.js 1.x third-party and first-party cookie behavior.
at.js 1.x cookie behavior
For at.js versions 1.x, the cookie behavior depends on whether it is a first-party cookie, a third-party cookie with a first-party cookie, or a third-party cookie alone.
When to use first-party or third-party cookies
Your site setup determines which cookies you want to use. It is helpful to understand how Target works when trying to understand first-party and third-party cookies. See How Adobe Target works for more information.
There are three main use cases for cookies:
-
One domain.
All of your testing will take place within one top-level domain (
www.domain.com,store.domain.com,anysub.domain.com, etc.).Use only first-party cookies. This is the default.
-
Users cross domains and you want to track and test their behavior across these domains.
Example: A user comes to your site to shop but checks out through Yahoo stores. Three approaches (work with your account representative to determine the best approach):
-
Enable first- and third-party cookies.
-
Enable third-party only (very rare, but has the benefit of keeping the at.js cookie out of your domain).
-
Enable only first-party cookies and pass
mboxSessionparameter when crossing domain.The
mboxSessionparameter must be passed to a landing page with at.js referenced. It cannot be an intermediate redirector page.
-
-
You are using only adboxes or Flashboxes on a third-party site.
Two approaches (work with your client services manager to determine the best approach):
-
Enable first-party and third-party cookies.
First-party and third-party cookies are required for Flashbox and dynamic creatives.
-
Enable only third-party cookies.
This approach is only for the rare case where adBox implementations are used without on-site targeting.
-
First-party cookie behavior
The first-party cookie is stored in clientdomain.com, where clientdomain is your domain.
at.js generates an mboxSession ID and stores it in the cookie. The first response contains the offer, as well as the JavaScript to store the mboxPC ID generated by the application, in the cookie.
AMCV_###@AdobeOrg first-party cookie is always set with the Experience Cloud Visitor ID.Third-party cookie behavior
The third-party cookie is stored in clientcode.tt.omtrdc.net and the first-party cookie is stored in clientdomain.com, where clientdomain is your domain.
at.js generates an mboxSession ID. The first location request returns HTTP response headers that attempt to set third-party cookies named mboxSession and mboxPC and a redirect request is sent back with an extra parameter (mboxXDomainCheck=true).
If the browser accepts third-party cookies, the redirect request includes those cookies, and the offer is returned.
If the browser rejects third-party cookies, the redirect request does not include those cookies, and default content is displayed for all locations on the page. Because there are no cookies set, the same process above happens again on every page request.
Third-party and first-party cookie behavior
The third-party cookie is stored in clientcode.tt.omtrdc.net and the first-party cookie is stored in clientdomain.com, where clientdomain is your domain.
at.js generates an mboxSession ID. The first location request returns HTTP response headers that attempt to set third-party cookies named mboxSession and mboxPC, and a redirect request is sent back with an extra parameter (mboxXDomainCheck=true).
If the browser accepts third-party cookies, the redirect request includes those cookies, and the offer is returned.
Some browsers reject third-party cookies. If the third-party cookie is blocked, the first-party cookie still works. Target attempts to set the third-party cookie, and if it cannot, then Target can only track on the client’s specific domain. Cross-domain tracking does not work if the third-party is blocked, unless the mboxSession is appended in the link that crosses domains. In this case, another first-party cookie is set and synched with the prior domain’s first-party cookie.
Cookie settings
The cookie has several default settings. You can change these settings if needed, with the exception of the cookie duration. Consult your account representative when changing cookie settings.
mycompany.com.clientcode.tt.omtrdc.net, using the client code for your account.The cookie remains on the visitor’s browser two years from his or her last login.
The deviceIdLifetime setting is overrideable in at.js version 2.3.1 or later. For more information, see targetGlobalSettings().
The cookie keeps a number of values to manage how your visitors experience campaigns:
Impact on Target for Safari visitors due to Apple WebKit tracking changes
Keep the following in mind:
How does Adobe Target Tracking work?
clientcode.tt.omtrd.net domain.What is Apple’s approach?
From Apple:
“Intelligent Tracking Prevention is a new WebKit feature that reduces cross-site tracking by further limiting cookies and other website data.”
“This is what’s called cross-site tracking and the cookie used by example-tracker.com is called a third-party cookie. In our testing we found popular websites with over 70 such trackers, all silently collecting data on users.”
How Safari handles cookies:
- Third-party cookies that are not on a domain the user accesses directly are never saved. This behavior is not new. Third-party cookies are already not supported in Safari.
- Third-party cookies set on a domain the user accesses directly are purged after 24 hours.
- First-party cookies are purged after 30 days if that first-party domain has been classified as tracking users across sites. This issue might apply to large companies that send users to different domains online. Apple has not made it clear how exactly these domains will be classified, or how a domain can determine if they’ve been classified as tracking users cross-site.
From Apple:
Machine Learning Classifier: A machine learning model is used to classify which top privately-controlled domains have the ability to track the user cross-site, based on the collected statistics. Out of the various statistics collected, three vectors turned out to have strong signal for classification based on current tracking practices: subresource under number of unique domains, sub frame under number of unique domains, and number of unique domains redirected to. All data collection and classification happens on-device.
However, if the user interacts with example.com as the top domain, often referred to as a first-party domain, Intelligent Tracking Prevention considers it a signal that the user is interested in the website and temporarily adjusts its behavior as depicted in this timeline:
If the user interacted with example.com the last 24 hours, its cookies will be available when example.com is a third-party. This allows for “Sign in with my X account on Y” login scenarios.
- Domains that are visited as top level domain won’t be affected. Sites like OKTA for example
- Identifies domains that are sub domain or sub frame of current page across multiple unique domains.
How will Adobe be affected?
Apple’s WebKit tracking changes breaks opt-out support.
Target opt-out uses a cookie in the clientcode.tt.omtrdc.net domain. For more details, see Privacy.
Target supports two opt-outs:
- One per client (the client manages the opt-out link).
- One via Adobe that opts the user out of all Target functionality for all customers.
Both methods use the third-party cookie.
Customers can choose their profile lifetime length for their Target accounts—up to 90 days. The concern is that if the account’s profile lifetime is longer than 30 days, and the first-party cookie gets purged because the customer’s domain has been marked as tracking users cross-site, behavior for Safari visitors will be affected in the following areas in Target:
Target Reports: If a Safari user enters into an activity, returns after 30 days, and then converts, that user counts as two visitors and one conversion.
This behavior is the same for activities using Analytics as the reporting source (A4T).
Profile & Activity Membership:
- Profile data is erased when the first-party cookie expires.
- Activity membership is erased when the first-party cookie expires.
- Target does not function in Safari for accounts using a third-party cookie implementation or a first- and third-party cookie implementation. Note that this behavior is not new. Safari has not allowed third-party cookies for awhile.
Suggestions: If there is a concern that the customer domain might be marked as one tracking visitors cross-session, it’s safest to set the profile lifetime to 30 days or fewer in Target. This ensures that users will be tracked similarly in Safari and all other browsers.