at.js cookies

Last update: July 17, 2023

CREATED FOR:

  • Developer

Information about at.js 2.x and at.js 1.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.

NOTE
For at.js versions 2.10.0 and later, both first-party and cross-domain cookies are supported.

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.

NOTE
For at.js versions 2.10.0 and later, both third-party cookies and cross-domain tracking are supported.

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:

  1. 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.

  2. 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 mboxSession parameter when crossing domain.

      The mboxSession parameter must be passed to a landing page with at.js referenced. It cannot be an intermediate redirector page.

  3. 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.

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.

NOTE
The AMCV_###@AdobeOrg first-party cookie is always set with the Experience Cloud Visitor ID.

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.

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.

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.

SettingInformation
Cookie namembox.
Cookie domainThe second and top levels of the domains from which you serve the content. Because it is served from your company’s domain, the cookie is a first party cookie. Example: mycompany.com.
Server domainclientcode.tt.omtrdc.net, using the client code for your account.
Cookie duration

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().

P3P policyThe cookie is published with a P3P policy, as required by the default setting in most browsers. A P3P policy indicates to a browser who is serving the cookie and how the information will be used.

The cookie keeps a number of values to manage how your visitors experience campaigns:

ValueDefinition
session IDA unique ID for a user session. By default, this lasts 30 minutes.
pc IDA semi-permanent ID for a visitor’s browser. Lasts 14 days.
checkA simple test value used to determine if a visitor supports cookies. Set each time a visitor requests a page.
disableSet if visitor’s load time exceeds the timeout configured in the Adobe Experience Platform Web SDK or at.js file. By default, this lasts 1 hour.

Impact on Target for Safari visitors due to Apple WebKit tracking changes

Keep the following in mind:

How does Adobe Target Tracking work?

CookiesDetails
First-party domainsThis is the standard implementation for Target customers. The “mbox” cookies is set in the customer’s domain.
Third-party trackingThird-party tracking is important for advertising and targeting use cases in Target and in Adobe Audience Manager (AAM). Third-party tracking requires cross-site scripting techniques. Target uses two cookies, “mboxSession” and “mboxPC” set in the 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.”

ApproachDetails
Intelligent tracking preventionFor more information, see Intelligent Tracking Prevention on the WebKit Open Source Web Browser Engine website.
Cookies

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.
Machine Learning to identify domains that are 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?

Affected FunctionalityDetails
Opt-out support

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.

Target activities

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.

Previous pageUpgrading from at.js 1.x to at.js 2.x
Next pageUser-agent and client hints

Target


Personalization & Experiementation Excellence with Recommendations and AI

Adobe Customer Success Webinars

Tuesday, Mar 4, 4:00 PM UTC

Adobe Target innovations, including GenAI, and best practices on AI-powered personalization and experimentation at scale.

Register

Connect with Experience League at Summit!

Get front-row access to top sessions, hands-on activities, and networking—wherever you are!

Learn more

Register now