Cross-Domain Tracking Through a Vendor Booking Engine and Payment Provider
Voyage Trails runs a marketing site at www.voyagetrails.com and a booking engine at book.voyagetrails.com. The booking engine is a subdomain but is built and hosted by a vendor. The team uses one GA4 web stream for the marketing site, and the vendor has placed the same Measurement ID on the booking pages. Users move from www to book, then to a payment provider at pay.securegateway.com, and back to book to finish. The team sees 22% of bookings attributed to the pay.securegateway.com referral and a spike in direct traffic. Campaign-tagged ads to www lose credit after the booking flow. The vendor says it cannot change its pages. The team proposes adding pay.securegateway.com to the cross-domain configuration in GA4.
1. Why is adding `pay.securegateway.com` to GA4's cross-domain configuration the wrong first move, and what should be configured instead?
Read the worked answer
Cross-domain configuration works by adding the linker parameter (_gl) when a tagged page links to another domain in the list, so the receiving tagged page can continue the same session. You do not control the payment provider's pages, and the provider is unlikely to run your GA4 tag or preserve the linker. Adding the domain to the list does not make the vendor's pages measured; it can create false confidence.
The payment provider is a referral exclusion case, not a cross-domain case. Exclude pay.securegateway.com from referrals so that when the user returns to book.voyagetrails.com, the session is not restarted and credited to the payment provider. Separately, make sure www.voyagetrails.com and book.voyagetrails.com are both in the stream's domain list and both carry the same Measurement ID, so the linker actually works between your own pages. Test the full path in DebugView.
2. The team sees 22% of bookings attributed to the payment provider referral and a spike in direct traffic. Explain the mechanism and the checks you would run.
Read the worked answer
Mechanism: the user starts on www with a campaign, moves to book, then to the payment provider. When the provider redirects back, the browser has no campaign parameters and the referrer is the provider. GA4 starts a new session and attributes it to the provider referral, or to direct if the referrer is stripped. The original campaign is lost, and the booking looks like it came from the payment step.
Checks:
- Confirm the booking subdomain is in the cross-domain list and that
_glis present on the link from www to book in DebugView. - Confirm the payment provider is in the referral exclusion list and that the exclusion is saved on the correct data stream.
- Inspect the return URL for retained
utm_*or_gl; if the provider strips them, the exclusion prevents the false referral but cannot restore the original campaign unless you pass a first-party identifier or use a server-side callback. - Compare
session_startsource/medium for booking completions against the ad platform's reported conversions; a large direct or referral block is the symptom to track.
Do not 'fix' this by adding UTMs to the provider return URL unless the provider supports it.
3. If the vendor's booking engine cannot be changed, what measurement design would you recommend to keep campaign attribution through the booking flow?
Read the worked answer
Assume you cannot modify the vendor's pages. Put as much continuity as possible on the pages you control: keep www and book in the same GA4 stream and cross-domain list, ensure the linker is present on every outbound link to book, and exclude the payment provider from referrals. On the booking engine, use the vendor's supported GA4 integration if it can use the same Measurement ID and respect the linker; if it cannot, accept that the booking completion may be a separate session.
To recover campaign truth, pass a first-party booking or lead ID and the original campaign identifier into the booking flow (URL parameter or server-side), then join booking completions to the original session in BigQuery or the CRM. Use a server-side measurement endpoint if the vendor allows a postback. Report two metrics: on-site behavior in GA4 and booked revenue in the booking system or CRM, joined by ID. That is more defensible than forcing last-click credit inside GA4 when the vendor breaks the session.