A customer finds your business, clicks through to a booking service or hosted checkout, and completes a purchase. Your website has done its job. But if measurement breaks at the handover, your reports may show the journey in fragments or miss the completed booking altogether.
Before changing your marketing budget, check what happens when customers leave your domain. Three problems need different fixes: a missing completion event, a broken connection between two measured websites, and a payment service appearing as a referral source.
This guide explains how to choose the right approach in Google Analytics 4 (GA4), what to ask your provider, and how to test the result.
Start with the symptom, not the setting
Compare one controlled booking or order with what your systems record. Use the booking platform or order system to establish whether it actually completed, then investigate the measurement gap.
- The booking exists, but GA4 records only the button click. Check whether a completion event is available and implemented. Joining domains will not create that event.
- GA4 receives activity from both sites, but the journey appears disconnected. Investigate cross-domain measurement and whether the destination uses your intended tag.
- A payment provider appears as a traffic source. Check whether it is merely an intermediate step in an existing purchase journey before considering unwanted-referral settings.
These problems can coexist. Removing a suspicious referral is not evidence that the booking itself is now measured correctly.
Map the complete customer route
Follow the actual route on mobile and desktop. Record the website address at the service page, booking selection, payment step and confirmation. Include redirects and any return to your own website.
A useful working example is a training business whose course page sits on its own domain, whose booking runs on a provider’s domain, and whose payment authentication briefly visits a bank. Those are three different roles: selling the course, accepting the booking and processing payment.
For each step, establish who controls the page, whether it runs your GA4 measurement ID, and what proves completion. Ask the provider specifically about the hosted pages customers use. A GA4 integration elsewhere in its product does not establish that this route supports it.
Also distinguish a new top-level website from a booking tool embedded inside your page. The address bar alone will not reveal every embedded domain.
Choose the right measurement approach
Use cross-domain measurement when both websites can be measured together
Google’s cross-domain setup guidance requires the same G- measurement ID from the same web data stream on participating pages. With consent, the linker parameter _gl passes measurement identifiers between domains so activity can remain connected.
For the usual GA4 configuration, open Admin, then Data streams, select your web stream, choose Configure tag settings and Configure your domains. Add conditions matching the participating domains and save. Check the actual destination hostname rather than assuming it matches the provider’s main website.
Agree the intended setup with the provider first. Avoid a broad rule covering unrelated merchants on a shared platform. You want your customer journey measured, with an integration scoped to your business.
If a developer has already configured the linker in code or Tag Manager, ask them to check for conflicting settings. Google’s technical linker documentation explains that a linker configuration can override the domains configured in Analytics. Editing the visible list may therefore leave the behaviour unchanged.
Use unwanted referrals for intermediate services that did not acquire the customer
A hosted payment page can be part of buying from you without being the source that introduced the customer. Google’s unwanted-referral guidance explicitly gives third-party payment processors as an example.
The setting is List unwanted referrals within the web stream’s Configure tag settings. Add narrowly matched conditions for verified intermediate domains. This tells Analytics to ignore the matching referrer as a traffic source; it does not install a tag on that service or connect otherwise separate user identifiers.
Keep genuine discovery sources visible. A directory, partner website or booking marketplace may introduce new customers as well as handle transactions. Blanket exclusion could hide useful acquisition information. Review the role of the particular route before adding its domain.
Google also explains why returning users can still be attributed to a previously excluded domain: earlier referral attribution can carry forward. A remaining referral row is therefore not, by itself, proof that the new setting failed.
Recognise when the provider cannot support the journey you want
If the provider cannot run your measurement ID on its booking pages, adding its domain to GA4 does not give you access to activity there.
Ask what supported alternatives exist: a documented completion integration, an export of confirmed bookings, or a return to a confirmation page on your website. Establish what each option actually proves. A return-page visit is useful only if the implementation reliably distinguishes a successful booking from cancellation, failure or someone opening the URL directly.
When completion cannot be measured reliably, report the outbound booking click as an earlier action and use the provider’s confirmed-booking records separately. Make the limitation explicit in reporting. Avoid presenting clicks as completed bookings or claiming individual attribution that your integration cannot establish.
This is a useful point to involve a developer. A clear measurement boundary is better than a dashboard that quietly overstates what happened.
Treat embedded booking tools as a separate integration
A booking form inside an iframe may look like part of your website while running on another origin. Browser storage rules can differ from those for a customer navigating directly to that website. MDN documents these restrictions on embedded cross-site content.
Do not assume that ordinary cross-domain link configuration solves an embedded tool’s measurement. Ask its provider how the embed communicates completion and supports analytics under current browser restrictions. Test the embedded route and any standalone booking-page route separately.
You do not need to implement the Storage Access API simply because the tool uses an iframe. The provider’s supported integration should determine the approach.
Keep booking starts separate from completed bookings
Write down the business action your completion event represents. For a paid course, that might be an accepted booking with successful payment. For a consultation, it might be a reserved appointment rather than an initial request awaiting approval.
A button click proves that someone tried to start the route. It does not prove the provider accepted a booking. Ask your implementer to show which confirmed state triggers the completion event, and to test successful, cancelled and failed journeys.
There is also an easy reporting trap after joining domains. Google’s enhanced-measurement documentation says links to configured cross-domain destinations no longer trigger its automatic outbound-click event.
If your existing booking-start report depends on that event, review it alongside the change. You may need a deliberately configured booking-start event. Its absence after configuration should not automatically be interpreted as fewer people trying to book.
Test the handover through to completion
Use a fresh test journey through the real customer route. Agree how to identify and remove test bookings from operational reporting, and use a provider-supported test payment route where available.
- Establish the starting point. Record the landing page, intended acquisition source, device, browser and consent choice. Keep those conditions consistent when comparing before and after.
- Use the real link or form. Do not jump straight to the booking website. Cross-domain verification needs the handover customers actually make.
- Inspect the destination. Where cross-domain measurement is configured, check that
_glis added and the page still loads. Have your developer verify that the destination tag consumes it and measurement identifiers remain connected. The parameter’s presence alone is insufficient evidence. - Complete the booking. Check that the provider records success and that the agreed completion event reaches the intended GA4 property. Compare the event with the confirmed business outcome.
- Test the alternatives. Cancel, fail payment where the test environment permits it, and revisit the confirmation page. Investigate false completions or repeated events.
- Repeat across relevant routes. Cover mobile and desktop, embedded and standalone booking where offered, and the consent choices your implementation supports.
If the linker disappears, Google’s troubleshooting guidance identifies redirects that remove parameters and scripts that prevent normal click handling. A developer can inspect the network requests to find the failing handover.
Google’s DebugView guidance recommends enabling debug mode for your test device through Tag Assistant or preview mode. Use it to inspect events and parameters. Privacy controls or lack of Analytics-cookie consent can prevent events appearing there, so an empty view needs interpretation.
DebugView also performs limited attribution analysis. Use acquisition reports to assess processed attribution rather than treating a live debugging screen as the final answer.
Check what the booking route sends to Analytics
Confirmation URLs and page titles sometimes contain customer details. Check those alongside event parameters before extending measurement to another site.
Google’s guidance on personally identifiable information requires ordinary Analytics collection to avoid identifiable information such as email addresses and personal mobile numbers. It specifically warns about information appearing in URL paths, query parameters and titles.
Keep customer names, email addresses, phone numbers and booking notes out of ordinary GA4 event parameters. Use the booking system for customer records. Test with dummy details, and verify existing consent controls still behave as intended after the integration changes.
Ask for evidence you can use
A useful handover from your agency or developer should include the measured domains, the completion definition, the configuration changes, and evidence from a successful test. It should also describe what happens when a customer cancels or declines optional measurement.
Record the change date. Google’s Analytics configuration checklist notes that many collection settings make data available only from configuration onwards. Do not expect a new integration to reconstruct previously uncollected booking activity.
Compare new reporting with confirmed bookings over a clearly defined period. Investigate differences rather than expecting every operational booking to appear in browser analytics. Separate measurement repairs from genuine changes in demand before judging campaign performance.
BuzzBoost’s analytics and reporting work and web development and integrations connect these checks across your website and supporting systems. If you cannot tell where booking measurement breaks, talk to BuzzBoost about reviewing the route and agreeing what your reports should reliably measure.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
