GA4 Cross-Domain Organic Conversion QA Checklist

01

Checklist

Scope.

• List every root domain in the conversion journey.
• Identify checkout, booking, payment, application, identity, support, and confirmation domains.
• Mark which domains the organization controls.
• Identify third-party domains that cannot run the same tag.
• Define the primary key events and business records.
• Record the expected navigation sequence.
• Identify redirects, iframes, embedded widgets, and return URLs.
• Mark consent boundaries and jurisdictions.
• Separate production, staging, and test domains.

Cross-domain measurement is needed when one user journey spans separate domains that would otherwise set separate identifiers. The scope should follow the actual journey, not the organization chart.

Property and stream.

• Use the same GA4 property and web data stream for domains that should form one journey.
• Confirm the same Google tag ID on every participating page.
• Record tag-management containers and deployment owners.
• Remove duplicate tags that send the same event twice.
• Verify production, not only a preview environment.
• Confirm no old or duplicate GA4 configuration creates competing behavior.
• Record server-side tagging or Measurement Protocol components.
• Preserve current settings before changes.

Google says cross-domain measurement allows activity across multiple domains to be attributed to one user. Without it, separate root domains can create new cookies, users, and sessions. ^[1]

Domain configuration.

• Open the web data stream’s tag settings.
• Add every participating domain under Configure your domains.
• Review automatically detected recommendations instead of accepting them blindly.
• Use conditions narrow enough to avoid unrelated domains.
• Record the date and administrator who changed the configuration.
• Check whether the tag is shared with other destinations that may inherit settings.
• Confirm staging domains are excluded or intentionally included.
• Recheck after platform migrations and new payment providers.
• Export or screenshot the controlled configuration.

The configuration defines where the linker should operate. It does not prove that each link and redirect preserves the identifier.

Linker parameter.

• Navigate through a real link from the source domain.
• Confirm the destination URL receives _gl.
• Test forms as well as links.
• Test desktop and mobile.
• Test consent-granted and consent-denied states.
• Test logged-in and logged-out flows.
• Test links opened in a new tab.
• Confirm the destination page loads normally.
• Confirm the parameter is read before it is removed or rewritten.
• Test after a fresh browser state.
• Record the source URL, destination URL, and timestamp.

Google documents _gl as the mechanism that passes identifiers between configured domains. ^[1]

The parameter is evidence that the linker attempted to pass state. It is not, by itself, proof that the destination accepted the state and preserved the session.

Redirects.

• Inspect every HTTP and JavaScript redirect.
• Confirm _gl survives the entire chain.
• Check CDN and application rewrites.
• Check canonical-host redirects.
• Check locale and device redirects.
• Verify payment-provider return URLs.
• Confirm query-string allowlists do not strip _gl.
• Test URL shorteners and marketing redirectors.
• Check HTTPS upgrades and www normalization.
• Confirm error and retry pages preserve the intended return path.
• Record each status code and final URL.

Google warns that redirects or servers rejecting arbitrary query parameters can remove the linker before the destination tag reads it. ^[1]

A redirect may work visually while quietly destroying attribution. The user reaches checkout, the business receives money, and the report credits the checkout domain for the stunning achievement of existing.

JavaScript and forms.

• Confirm navigation is triggered in a way the Google tag can decorate.
• Review scripts that call stopPropagation.
• Test single-page application routing.
• Test dynamically generated links.
• Test embedded forms and iframes.
• Confirm validation errors retain measurement state.
• Check browser console and network requests.
• Test forms submitted with GET and POST.
• Review custom click handlers.
• Test keyboard navigation.
• Confirm consent scripts load tags in the correct order.
• Verify failed JavaScript does not produce a different measurement path.

Self-referrals.

• Review session source and medium for the organization’s own domains.
• Review payment processors and booking providers.
• Distinguish configured cross-domain traffic from unwanted referrals.
• Add an unwanted-referral condition only when appropriate.
• Confirm referral exclusion does not hide a broken user journey.
• Compare referral counts before and after changes.
• Inspect landing pages for sessions attributed to internal domains.
• Review direct traffic increases after exclusion.
• Record which domains are excluded and why.

Google says traffic from a correctly configured cross-domain journey is not identified as referral when the destination contains the linker parameter. It separately allows unwanted-referral conditions that append ignore_referrer=true to matching events. ^[2]

Referral exclusion can prevent a source label. It does not necessarily preserve the same user and session. Hiding the symptom is not the same as repairing the journey.

Sessions and users.

• Start a clean browser session.
• Land through an organic test URL where safe.
• Move across every domain.
• Confirm one user identifier under the measurement design.
• Confirm the session does not restart at the boundary.
• Confirm engagement and page sequence remain coherent.
• Check DebugView and real-time tools.
• Recheck standard reports after processing.
• Repeat after the inactivity threshold.
• Repeat with a returning user.
• Check whether identity settings alter the validation report.
• Record browser, device, consent state, and test time.

GA4 defines sessions through session identifiers and inactivity rules. ^[4] A cross-domain break can inflate users and sessions even when the person experiences one continuous journey.

A single DebugView test demonstrates one path under one state. It does not establish the production success rate across browsers, consent choices, and payment flows.

Key events.

• Fire the key event once.
• Confirm value, currency, transaction ID, and item data.
• Prevent duplicate confirmation-page events.
• Test browser refresh.
• Test back-button behavior.
• Test failed and cancelled payments.
• Test offline completion where applicable.
• Reconcile with commerce or CRM.
• Test partial payments and refunds.
• Confirm test transactions are excluded.
• Verify the event appears under the expected domain and source.
• Check whether server and browser events duplicate each other.
• Preserve a known-good transaction ID for regression tests.

A correct session with a duplicated purchase event is still a broken revenue system.

Attribution.

• Record the reporting attribution model.
• Record the key-event lookback window.
• Compare event-scoped, session-scoped, and first-user dimensions.
• Confirm Organic Search is not replaced by the intermediate domain.
• Review direct and unassigned traffic.
• Document modeled data and late processing.
• Do not compare reports with different scope as though identical.
• Record changes to the attribution model.
• Review imported offline events and identity matching.
• Confirm currency-conversion rules.
• Preserve report name, dimensions, filters, and export date.

GA4 allows changes to the reporting attribution model for key events. ^[5] Unifying the journey does not eliminate model dependence. It merely gives the model a better chance of seeing one journey.

Google tag settings.

• Review Google tag destinations and configuration.
• Confirm which settings are inherited by connected destinations.
• Record administrators and change permissions.
• Check whether automatic event detection creates duplicate events.
• Review internal traffic definitions.
• Confirm domain changes reached the live tag.
• Test after publishing the container or setting.
• Keep rollback instructions.

Google’s tag-settings guidance explains that shared settings can affect connected destinations. ^[3]

Privacy and URL handling.

• Ensure _gl is not stored in canonical URLs.
• Prevent linker parameters from entering XML sitemaps.
• Avoid internal links that permanently preserve decorated URLs.
• Redact sensitive query parameters.
• Check logs and exports for unnecessary identifiers.
• Follow consent and privacy requirements.
• Review data retention.
• Avoid putting personal or payment data in URLs.
• Document the measurement basis where required.

Cross-domain measurement is an analytics configuration, not a bypass for consent or browser controls.

Regression testing.

• Add cross-domain QA to release checklists.
• Test after CDN, checkout, consent, tag, framework, DNS, and redirect changes.
• Alert on self-referral growth.
• Alert on sudden user or session inflation.
• Monitor conversion-rate breaks at domain boundaries.
• Preserve a known-good test transaction.
• Recheck after adding a new country or language.
• Recheck after payment-provider changes.
• Monitor duplicate transaction IDs.
• Assign an owner to anomalies.
• Preserve baseline reports and configuration evidence.

02

Completion criteria

The setup passes when all intended domains use the same stream and tag, configured-domain rules are correct, _gl appears on links and forms, every redirect preserves the parameter, the destination loads normally, and one continuous user and session is observed under the supported test conditions. Self-referrals must be absent, key events must fire exactly once with the correct values, Organic Search attribution must not be overwritten by an intermediate domain, and commerce or CRM records must reconcile with the analytics event.

Passing one clean browser journey is not enough. Preserve evidence for desktop and mobile, consent-granted and consent-denied states, the actual payment or booking provider, and at least one processed standard-report check after real-time validation. The acceptance record should identify the tester, timestamp, source URL, redirect chain, linker parameter, browser, device, consent state, transaction ID, event payload, session continuity evidence, business-record match, known limitations, and rollback owner.

The configuration should also have a named maintenance owner, monitoring for self-referral and duplicate-event regressions, and a repeatable test triggered by any tag, checkout, consent, CDN, framework, redirect, or domain change. A conversion path can cross three companies, two consent states, one payment provider, and a framework that believes query parameters are a personal insult. “We installed GA4” does not settle any of that.

References

Sources behind this record

1. Set up cross-domain measurement — Google Analytics Help (accessed August 3, 2026)
2. Identify unwanted referrals — Google Analytics Help (accessed August 3, 2026)
3. Configure your Google tag settings — Google Tag Manager Help (accessed August 3, 2026)
4. About Analytics sessions — Google Analytics Help (accessed August 3, 2026)
5. Change the reporting attribution model for key events — Google Analytics Help (accessed August 3, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.