Cross-Domain Tracking

The Experience Cloud ID (ECID) gives every visitor a single identifier, but that identifier only holds while the visitor stays on one domain. Not every journey does. A visitor might browse a car model on brand.com, click "book a test drive," and land on a completely separate domain that handles the booking. To the business this is one person, one journey, one conversion. To Adobe, by default, it is two different strangers. The visitor who left brand.com and the visitor who arrived on the booking site look like two unrelated people, and everything downstream suffers: visits and unique visitors inflate, the journey breaks in half, and the conversion gets credited to nobody in particular.

Cross-domain tracking is how you stitch that journey back into one. Before reaching for it, though, it is worth being precise about why the split happens, because that is the exact thing your Launch setup has to fix.

Why one visitor becomes two, even with identical tags

Here is the point that surprises people. Suppose you deploy the same tag setup on both domains: the same Experience Cloud ID extension, the same organization ID, and the Analytics extension pointing both domains at the same report suite. Everything is configured identically. The visitor is still counted twice. Identical setup does not produce identical identity.

The reason is where the identity actually lives. The ECID is stored in a first-party cookie named AMCV_, and that cookie is scoped to the domain that wrote it. A cookie written by brand.com is readable only by brand.com. So when the visitor lands on the booking domain, that domain cannot see brand.com's AMCV_ cookie, has no idea one exists, and does the only thing it can: it writes its own AMCV_ cookie with a brand new ECID. Same extension, same org ID, two different cookie values, two visitors. This is not an Adobe flaw, it is the browser enforcing domain isolation for privacy, and it applies to everyone. The whole job of cross-domain tracking is to carry one ECID across that boundary so the second domain reuses it instead of inventing a new one.

The mechanism: carry the ID in the URL

Since the cookie cannot cross the boundary, you carry the identity out in the open, in the one thing that does travel between domains: the URL. When the visitor clicks a link from brand.com to the booking domain, you append a parameter called adobe_mc to the destination URL. It carries three things: the ECID, your organization ID, and a timestamp. The destination page, running the same ID service with the same organization ID, reads that parameter as it loads and adopts the ECID instead of minting a new one. Both domains now agree on who the visitor is.

Doing it in Launch

Almost every real implementation lives in Launch, not hand-written code, so this is where the practical work happens. The two collection paths, AppMeasurement and Web SDK, solve the same problem in noticeably different ways.

The AppMeasurement path. The Experience Cloud ID extension handles identity and writes the AMCV_ cookie, but it has no built-in option for cross-domain links, and this is the gap people miss. Installing it on both domains gives you the same configuration, not the same ECID. To close the gap you add one rule: fire it on a page load event such as DOM Ready, and give it a Custom Code action that finds the links pointing to your other domain and rewrites each one through appendVisitorIDsTo() so the adobe_mc parameter is on the URL before the browser navigates away.

var crossDomains = ["booking-partner.com"];
var visitor = Visitor.getInstance("YOUR_ORG_ID@AdobeOrg");

crossDomains.forEach(function (domain) {
  // Skip if we are already on that domain
  if (location.hostname.indexOf(domain) === -1) {
    document.querySelectorAll('a[href*="' + domain + '"]').forEach(function (link) {
      // Decorate on mousedown, before the click navigates
      link.addEventListener("mousedown", function () {
        this.href = visitor.appendVisitorIDsTo(this.href);
      });
    });
  }
});

The Web SDK path. The Web SDK extension replaces both AppMeasurement and the ID extension, and the Edge Network manages identity. Here there is no custom code to write, because the extension already includes the action. You build a Core Click rule whose selector matches your outbound links (for example a[href]) with a condition limiting it to your other domain's hostname, and you attach the Web SDK "Redirect with identity" action. It appends the same adobe_mc parameter for you.

The constraints, and the mistakes people make

The parameter expires in five minutes. The timestamp inside adobe_mc is checked on arrival, and a parameter older than five minutes is ignored. This is deliberate: it stops a link that was copied, shared, or bookmarked from handing your identity to whoever opens it hours later. It works for a live click-through, not for a stale URL, so a redirect chain that stalls can quietly break the stitch.

It only helps a direct click-through. Decorating links carries identity when the visitor actually travels from one domain to the other by clicking. If the same person arrives at each domain separately, there is no link to decorate and nothing to carry. Historically a third-party cookie could sometimes bridge that gap, but browsers are steadily blocking third-party cookies, so leaning on them is no longer a plan. Carrying identity explicitly in the URL is the durable approach, and the fading of the third-party cookie is exactly why First-Party Cookies matters so much.

Decorate the right links, and only those. You append identity to links pointing at domains you own and want to stitch, not to every outbound link on the page. Spraying your ECID onto links to sites you do not control leaks identity where it does not belong. Configure the specific destination domains and leave everything else alone.

The same idea extends beyond web to web. Moving a visitor from a mobile app into a WebView uses the same adobe_mc handoff, with the app's identity service producing the parameter for the web page to read. The mechanics of the app side sit with the Mobile SDK, but the principle is identical: identity is passed on purpose, because the environment will not share it for you.

Step back and the real lesson is not about a query parameter or a rule. Cross-domain tracking is identity continuity in a world where the browser deliberately keeps domains apart. Identical tags on both sites are not enough, because the cookie that holds the ECID cannot cross the boundary, so you carry the identity across it yourself. That mindset only grows more important as third-party cookies disappear and every kind of identity has to be handled deliberately, which is exactly where First-Party Cookies picks up.