Checkout changed domains. Did measurement keep the journey together?

A customer arrives through an ad, selects a product, and moves to a separate checkout domain. The purchase completes, but analytics now attributes the visit differently or appears to count a new user.

The website journey works for the customer. The measurement journey may still be broken.

Cross-domain measurement is designed to maintain continuity across participating domains under the implementation’s supported conditions. Google’s GA4 setup guidance describes passing information through a linker parameter and the required tag configuration.

Map the transitions first

List the marketing site, checkout, payment service, confirmation page, and any booking provider. Distinguish domains where your organization can configure measurement from services it does not control.

Record the navigation method at each boundary: ordinary link, form submission, redirect, embedded frame, or app transition. A configuration that works for one path does not automatically cover all of them.

For an embedded checkout, ask the provider for its supported integration. Do not assume that adding a domain name to a setting creates communication across an iframe.

Test the actual purchase route

Use an approved test transaction or staging flow. Begin with a tagged test entry, follow the normal route, and inspect the relevant measurement evidence at each transition.

Check whether the expected linker information is added and preserved where the implementation requires it. Redirects or custom navigation can alter the result.

The campaign-link guide covers URL preservation, but cross-domain QA also needs evidence that the destination uses the information appropriately.

Test supported consent states. Do not force continuity by bypassing the choices the implementation is supposed to respect.

Confirm the outcome separately

A continuous session is not proof that the purchase event is correct. Check the transaction identifier, value, currency, and the point at which the event is sent.

Also test a return visit to the confirmation page. The event should follow the implementation’s duplicate-prevention design rather than creating a new purchase every time the page is opened.

Keep a small reconciliation between the approved test order and the observed event. Avoid sending real customer details into debugging screenshots or shared logs.

Investigate referral changes with evidence

A payment or checkout domain appearing in a report may indicate a configuration issue, but changing referral settings alone does not prove that identity continuity has been repaired.

Review the journey from entry to outcome, then inspect the reporting scope. The GA4 acquisition guide explains why first-user and session dimensions can legitimately differ.

Document the original symptom, exact path, correction, and verified result. Retest after a checkout-provider release or domain change.

The final acceptance criterion should describe the whole supported journey: the customer reaches the intended destination, the implementation respects its required conditions, and the recorded outcome remains connected as designed.