A visitor can arrive from an ad, choose an appointment on another domain and complete a payment somewhere else. Each handoff creates a separate measurement question: whether the browser journey stays connected, whether the intermediary becomes a reported source and whether a real booking or payment is confirmed.
We review those questions separately so a cleaner acquisition report is not mistaken for complete conversion tracking. The worksheet and worked example below are original planning aids. Use them to organize evidence from your own setup before drawing a conclusion.
In this guide
- Separate the four measurement jobs
- Map the real route and the available control
- Understand the cross-domain prerequisites
- Use unwanted referrals for source treatment
- Define completion independently of the return page
- Complete a handoff evidence worksheet
- Worked example: a booking succeeds without a return
- Verify collection and reporting separately
Separate the four measurement jobs
| Job | Relevant evidence or control | Boundary |
|---|---|---|
| Label acquisition | UTMs or supported ad auto-tagging | Describes incoming campaign information |
| Connect eligible browser activity | Cross-domain measurement | Requires a supported setup across participating domains |
| Handle an intermediary referral | Unwanted-referral configuration | Changes source treatment, not completion evidence |
| Confirm the business outcome | Accepted booking or payment record and an appropriate event | Must reflect the agreed success condition |
Use our UTM and lead-source guide for the first job. Adding campaign labels to a booking link does not establish that analytics can recognize the same browser on the destination.
Map the real route and the available control
Write down each destination in order: landing page, booking selection, confirmation, payment and any return page. Record intermediate redirects too. A button label such as “Book now” does not reveal whether it opens a new page, an embedded experience or a scripted redirect.
For each step, identify who controls the page, whether your measurement can run there and what completion evidence the provider exposes. Classify capabilities as confirmed, unavailable or unverified. Treat a vendor integration label as a starting point for inspection rather than proof that every event and identifier is handled.
- For pages you control, document the existing measurement destination and permitted configuration access.
- For a hosted provider, review its current integration documentation and your account's actual settings.
- For an embedded experience, verify the provider-supported event interface. Do not assume the parent page can inspect the embedded form.
- For an inaccessible step, identify which outcomes can still be verified through permitted records.
This capability map prevents a common planning error: recommending a configuration change that the business cannot apply to the third-party destination.
Understand the cross-domain prerequisites
Google's GA4 cross-domain setup guidance requires the participating pages to use the same G- measurement ID from the same web data stream. Eligible navigation carries identifiers using the _gl linker parameter. A destination that removes that parameter can break the handoff. Consent and browser conditions still matter.
The Google tag developer guide describes a two-sided process: the source adds linker information and the destination reads it. A domain entered in an admin list cannot make an unsupported third-party page participate. The guide also explains that linker values expire quickly, so validate through fresh navigation rather than recycling an old decorated URL.
For GA4, Google recommends configuration through Analytics Admin for typical cases. Where an existing setup uses custom code or tag-level settings, record that fact before making changes. Two conflicting configuration paths can make a simple-looking adjustment difficult to interpret.
Use unwanted referrals for source treatment
Google's unwanted-referral guidance explicitly includes payment processors as a common use case. When a matching referral is ignored, that domain is not treated as the traffic source for the affected events. This can be appropriate when an intermediary is part of completing the original journey.
Referral handling does not install your measurement on the provider, join otherwise separate browser identities or confirm a purchase. It also does not recover missing historic activity. Review the actual domain and its role before proposing an exclusion; a genuine partner referral may be valuable acquisition information. Google also explains that an earlier attributed referral can still appear on later direct visits after exclusion, so continued appearances do not alone prove that the setting failed.
Google also describes automatic self-referral handling and valid configured cross-domain referrals. Avoid adding broad exclusions simply because a source looks unfamiliar. First establish the route that produced it and the question your report is answering.
Define completion independently of the return page
A person may finish a booking and close the provider tab before returning. Another may revisit a thank-you page without creating another booking. Define success using the strongest available business evidence, then determine how the existing event relates to it.
For appointments, distinguish selecting a time, submitting a request and receiving an accepted booking. For payments, distinguish opening checkout, attempted payment and the business's agreed completed-payment state. Preserve cancellation and refund context when interpreting later reports. Our lead-stage guide explains how stage definitions improve comparisons.
Where a provider offers a supported completion integration, inspect its actual behavior, ownership and duplicate-handling rules. Google describes Measurement Protocol as a supplement to existing collection, with its own implementation requirements. A server-side event route requires design and validation; it is not a shortcut around missing permissions or consent.
Keep customer contact details and private booking information out of URLs and campaign labels. Google's Analytics privacy guidance warns that personal information can leak through page addresses and ordinary measurement fields. A measurement plan should minimize what is transmitted and honor the applicable choices and requirements.
Complete a handoff evidence worksheet
| Checkpoint | Record for this journey | Decision supported |
|---|---|---|
| Destination and owner | Each domain, intermediate step and responsible party | Who can investigate or change it |
| Supported measurement | Existing tag destination or documented provider interface | Whether continuity is technically available |
| Handoff evidence | Fresh permitted navigation, redirects and relevant parameters | Where continuity needs investigation |
| Referral role | Acquisition partner, operational intermediary or unresolved | Whether referral treatment merits review |
| Completion authority | Accepted business status, timestamp and existing event path | Which outcome the event can substantiate |
| Exceptions | Abandonment, repeat visit, cancelled outcome or missing return | Limits on the reported conversion total |
Finish each row with an owner and next check. “Provider support needed” is a useful finding when the unresolved capability belongs to the provider. It is more actionable than promising complete visibility into an inaccessible step.
Worked example: a booking succeeds without a return
This example is illustrative. Its figures and observations are invented, not measured client results.
Imagine a service business with 30 booking-button clicks. The booking provider records 12 accepted appointments. Nine visitors reach the website's return page. The existing report counts that return page as the booking outcome and therefore shows nine.
The comparison identifies a definition gap: the return-page event represents returns, while the provider record represents accepted appointments. It does not establish that all 12 bookings belong to the same campaign, or that the other 18 clicks failed because of tracking.
Suppose the provider cannot run the required browser measurement but exposes a documented completion integration. The priorities are to retain the provider's accepted-booking count as operational evidence, clearly label the return-page metric and evaluate the integration separately. An unwanted-referral change alone would not produce the three missing return events or connect every booking to its original ad.
Verify collection and reporting separately
For an authorized test, record the starting page, consent state, navigation path and expected outcome. Google's cross-domain documentation also notes that configured cross-domain links are excluded from automatically measured outbound clicks. Recheck any report that previously depended on that click event.
Use the safe test guide to plan the event-receipt check, then review the applicable acquisition report and business records. If the route includes CRM outcomes, our CRM-to-ad-platform guide defines the next comparison.
For a self-review, download our free conversion tracking checklist after submitting the form. It is available as an immediate PDF download. Use it alongside the handoff worksheet to decide which evidence to gather before commissioning changes.