Fix Cross-Domain Booking Attribution When Branch Pages Send Customers to Another System

The symptom: bookings appear to come from nowhere

A customer clicks “Book at Ahmedabad branch,” chooses a time on a vendor booking site and completes the appointment. The website report shows a visit, the booking system shows a completed appointment, but Analytics attributes the completion to a referral or a new session. Across many branches, this makes channel and location comparisons unreliable.

Google Analytics documents cross-domain measurement for journeys that cross domains. Without suitable configuration, the same person can be treated as separate users or sessions on different domains; configured measurement passes an identifier through the link or form flow. See Set up cross-domain measurement.

Diagnose before changing tags

Follow one test journey using a test booking, not a real customer record:

1. Start on a branch page with a known source/medium and branch ID.
2. Click the booking call to action and note the destination domain.
3. Complete the test flow to its confirmation page.
4. Inspect whether the transition creates a new session, a self-referral or an unassigned conversion.
5. Check that the measurement tag is present and correctly configured on every domain that should participate.

If the booking vendor does not permit tag configuration or does not support the required measurement, document that limit. Do not imply cross-domain tracking can be fixed entirely from the brand's website if the receiving system is outside its control.

Build a domain ownership map

List each customer-journey domain, the organisation that controls it, the tag owner, whether test access is available, and the event expected at handoff. For example: brand.in/clinic/ahmedabad → booking.vendor.example/clinic/ahmedabad → payments.vendor.example/confirmation. The example is illustrative; actual domains and vendor capabilities differ.

Keep branch identity as an explicit parameter or data-layer field where the implementation supports it. Do not infer the branch from the last URL alone if a customer can switch locations mid-booking. Decide which event represents the business outcome—booking started, booking confirmed or appointment attended—and keep those stages separate.

Common traps

• Configuring only the first domain and forgetting a redirect or payment domain.
• Testing the homepage but not the branch-specific booking route.
• Treating a vendor referral as proof of a new customer acquisition.
• Counting the confirmation page load more than once when a user refreshes it.
• Removing referral traffic broadly without fixing the underlying journey.

Acceptance criteria

A test booking retains the intended campaign attribution through the journey, the correct branch is attached to the event, the final event fires once under the documented rule, and test traffic is excluded from business reporting where appropriate. Repeat after vendor updates and website releases.

Sources and limitations

Cross-domain measurement depends on consent, tags, redirects and vendor support. Verify current Analytics behaviour in the actual property; this workflow does not guarantee user-level stitching in every browser or consent state.