GA4 Cross-Domain Tracking: Set Up and Troubleshoot the Handoff

To connect a website visit with activity on a separate booking or checkout domain, both sites must support the same GA4 web stream and the intended cross-domain configuration. Adding a hostname in Analytics does not install a tag on that site or give you access to a vendor’s booking results.

For a cooperating pair of sites, the basic route is Admin → Data streams → your web stream → Configure tag settings → Configure your domains. Then test the actual link with a fresh browser journey. The receiving page should load, receive the linker information and send the intended measurement to the correct destination.

The useful test is more demanding than “the booking page opened.” You need to distinguish a working navigation, a connected measured journey and a confirmed booking. This guide follows one example through those checks, then shows how to investigate the common failures.

See the complete handoff before changing settings

Consider a fictional equipment workshop. Its public site is workshop.example; its reservation application is reserve.example. Both are assumed to support one approved web stream. The example uses placeholder labels rather than actual measurement IDs or browser identifiers.

Here is the expected trace for a correctly configured, consented, active-session journey:

Now change one detail. The mobile button goes through go.example, whose fictional redirect discards the query string. The reservation page still opens, but the linker information is gone. In this illustrative broken trace, destination collection uses a different browser identifier, C-B, and session S-B. The failure is at the redirect, even though the button and destination appear functional.

The proposed repair is to preserve the required linker parameter through that route and verify the destination’s handling. The expected retest restores continuity for the eligible short journey. It does not create a booking-completion event, repair unrelated historical data or prove that every mobile browser behaves identically.

These are annotated teaching examples, not captured browser results. No live GA4 property, vendor integration or cross-domain browser measurement was executed for this guide. The expected observations provide a concrete test to perform in an authorized environment; they should not be copied into a worksheet as completed evidence.

The distinction matters because the repair is specific. Replacing a missing linker with a manually typed campaign label would change the attribution input without fixing browser continuity. Renaming the booking click as a completed reservation would conceal the missing outcome evidence. Neither action addresses the broken handoff.

Does the journey need cross-domain measurement?

Cross-domain measurement is relevant when activity on separate domains belongs to the same intended customer journey and the participating sites can cooperate technically. A business website leading to its supported reservation application is a common example. So is a storefront leading to a separately hosted checkout.

It is not a way to measure every external website linked from your pages. A supplier directory, news article or unrelated partner site may be a legitimate outbound destination. Unless the sites share an appropriate measurement arrangement, your observable interaction may end when someone leaves your page.

Start by opening the actual destination through an approved test route and reading its hostname. The visible button label and vendor brand are insufficient. A desktop link may use a branded hostname while a mobile widget opens a vendor-hosted address. A regional booking route may use another hostname again.

Then ask what you control. Can you install or configure the intended tag on both sides? If the destination is a vendor product, does its supported integration use the same stream and accept incoming linker information? If the answer is unknown, clarify the integration before making the domain list longer.

Google’s cross-domain setup guidance requires the same G- measurement ID from the same web data stream on participating pages. Two streams in one property are not the documented substitute. A shared property name or a tag that merely looks similar cannot establish the required relationship.

For subdomains, inspect the existing cookie-domain configuration and actual behaviour. Sites under one parent domain can share an appropriate first-party cookie scope, but inconsistent configurations can still create problems. Avoid both blanket assumptions: that every subdomain needs a separate elaborate setup, or that shared branding guarantees continuity.

Write the decision in plain language. “Connect the public workshop site and supported reservation application during eligible browser journeys” is a useful scope. “Track everything involving reservations” is too broad to guide configuration or testing.

Check the installation on both sides

Before editing Analytics, identify the stream and destination that should receive the events. Confirm the exact G- ID against the approved stream details. Repeat that check on the public website and the receiving application.

Inspect what actually runs, rather than relying only on an installation field in a vendor’s settings. A content-management plugin might load one destination while a GTM container loads another. A page template may be missing its tag. A reservation application may use a separate installation on its confirmation view.

For a GTM-managed site, Preview can help establish which Google tag and event tags execute on the test route. Google’s Preview documentation explains how the debugging session exposes tag behaviour. A workspace setting is still a proposed configuration until the intended release reaches the relevant environment.

Do not solve uncertainty by adding another Google tag. First find the installation owner and active configuration. Two overlapping implementations can introduce duplicate observations and make a cross-domain investigation harder because the same page produces competing evidence.

If the installation is inherited or spread across several plugins, the Google Tag Manager audit guide covers that wider inventory. Keep this investigation focused on the source and destination needed for the handoff. You do not need to redesign every event before checking the route.

On the vendor side, request the exact integration documentation. “Supports Google Analytics” could mean a page tag, a server-generated outcome feed or a dashboard export. Those capabilities answer different questions. A vendor may report completed bookings without making every intermediate page available for browser measurement.

A useful vendor answer identifies the supported stream configuration, pages or outcomes covered, consent behaviour and available test method. If the vendor cannot support the intended browser linking, retain source-side handoff measurement and label the rest as unavailable. That is a valid implementation boundary, not a reason to invent a workaround.

Configure the approved domains

Once the shared-stream prerequisite is established, use Analytics Admin for the ordinary GA4 configuration. Google recommends this route rather than starting with a manual linker override in page code. You need appropriate editing access to the property.

1. Select the intended Analytics property.
2. Open Admin, then Data streams under Data collection and modification.
3. Select the relevant web stream.
4. Open Configure tag settings.
5. Choose Configure your domains.
6. Review existing conditions, add the required domain conditions and save the authorized change.

Before saving, compare the proposed conditions with the actual hostnames in the journey. Include the participating routes you intend to connect; avoid broad conditions that accidentally include unrelated hosts or other tenants of a vendor platform. A shared vendor suffix may cover much more than your own booking site.

Retain a short record of the previous conditions and the intended change. This need not become a large governance document. It should let the developer answer which domain rule changed if a previously working path behaves differently after release.

Check whether the installation already contains a custom linker setting. Google’s developer reference notes that such configuration can override domains entered through Admin. If two people maintain separate lists, editing the visible Admin list may not produce the effective configuration you expect.

Avoid copying Google Ads or Floodlight instructions into a GA4 setup just because they mention a Conversion Linker tag. The products have related linking mechanisms, but their configuration instructions are not interchangeable. Follow the GA4 route for the GA4 requirement and have the advertising owner handle any separate advertising measurement need.

A saved domain condition is the beginning of the test, not its conclusion. The application still needs to generate the right navigation, preserve necessary information through redirects and collect the destination observation under the applicable consent state.

Run one fresh, short control journey

Use a permitted test environment or an agreed production testing procedure. Choose a non-sensitive route that exercises the real handoff without creating an unintended booking or payment. Record the browser, device and consent condition so the result can be reproduced.

Keep the first run simple: source page, one ordinary booking link, destination page. Start within an active session and avoid a long pause between sites. Complex payment or authentication routes can follow after the basic transition works.

Inspect navigation as it happens

Open the browser’s network panel before starting and enable Preserve log. Follow the actual button rather than pasting the destination directly into the address bar. Inspect the initial navigation, intermediate redirects and final document request. Chrome’s Network panel guide explains how to preserve requests across page loads and inspect request details.

Look for the fresh _gl parameter on the navigation. It can be added at click time, so an undecorated link in the page’s static HTML is not enough to diagnose a failure. Compare what the browser actually requested with what the source link originally contained.

Do not save a decorated link and use it as a permanent test fixture. Google documents a two-minute validity period for linker parameters. A late replay is a different condition from a fresh click and can fail for reasons unrelated to the original configuration.

If the route has redirects, identify the last request that still contains the required information. In the fictional mobile example, that comparison points directly to the short-link redirect. Without the preserved log, the final page could leave you guessing whether the source never decorated the link or an intermediate service removed it.

Check destination collection separately

Confirm that the intended tag runs on the receiving page and that an expected destination event is sent to the intended stream. A correct-looking URL does not prove either fact. A destination can receive linker information while its measurement is absent, blocked or directed elsewhere.

Use the authorized debugging tools available for the implementation. In a Google Tag Manager setup, examine the relevant Preview event and tag state. In GA4, inspect the corresponding test-device events in DebugView where supported. Keep a network observation, tag execution and Analytics receipt as separate checks rather than calling all three “the tag fired.”

Google’s DebugView guidance notes that privacy controls or lack of Analytics-cookie consent can prevent visibility. An empty DebugView is therefore a prompt to investigate the collection and consent conditions, not proof that nothing left the browser.

Compare identifiers without spreading them around

Where the integration exposes the supported Google tag API, a developer can retrieve the GA4 target’s client_id and session_id on each side. The Google tag API reference documents these fields and also warns that manually set values can take precedence.

For a short, eligible control run, compare the intended browser and active-session identifiers, then corroborate them with the event evidence. Two unavailable values are not a match. A manually assigned value returned by the API is not independent proof that collection used the intended state.

Keep actual identifiers out of shared marketing sheets and public screenshots. Record “matched,” “different” or “unavailable” with a sanitized evidence reference. The example’s C-A and S-A are explanatory labels only; they are not values to paste into a tag configuration.

Repeat the reverse direction

If visitors return from the reservation application to the main website, test that route too. It may use a different hostname, new tab, redirect or button implementation. A passing outbound link does not validate the return by implication.

At the end of this control, you should be able to say exactly which parts were observed: navigation, destination event, browser continuity and eligible session continuity. Leave any unperformed check open. That specificity makes the next troubleshooting step much smaller.

Understand what a new session means

A continuous customer task does not guarantee one Analytics session. Someone can open a reservation page, leave for lunch and return later. The booking may still belong to the same human decision while the analytics session has ended.

Google documents a default session timeout of 30 minutes of inactivity, with a configurable web timeout. Its session guidance also explains that a session ID is not globally unique on its own. When analysing exported session identifiers, the appropriate user identifier is part of the context.

Set the timing expectation before interpreting the result. For the short control journey, continuity of the eligible active session is a reasonable test. For a return after the configured inactivity timeout, a new session can be expected. Extending the timeout solely to make a test pass changes the reporting definition instead of explaining the behaviour.

Separate three questions: did the intended measured browser identity persist, did the eligible active session persist, and what acquisition context is reported? A plausible source label does not prove matching identifiers. Matching identifiers do not establish that the business outcome event is valid.

Use a documented entry route when testing acquisition. Previous browsing activity can affect interpretation, so an unexplained browser history is a poor control. At the same time, do not clear or weaken privacy protections simply to obtain a desired continuity result. Test the stated conditions and preserve their limits.

Avoid adding fresh UTMs to an internal booking handoff to make the destination recognizable. That introduces new campaign information where the task is to preserve the existing journey. The UTM naming guide covers external campaign labels; hostnames and a sanitized journey log can distinguish this test without rewriting acquisition context.

Find where the working and broken routes first differ

Once a simple control works, compare the failing route against it. Change one meaningful condition at a time. A desktop text link and a mobile booking widget may differ in several ways, so identify the navigation mechanism before adjusting Analytics settings.

The direct link works; the branded short link fails

Inspect the short link’s destination and redirects. In the fictional example, the direct route reaches reserve.example with the fresh linker. The short route first reaches go.example, then redirects to the reservation page without its query.

The next action is to involve the owner of that redirect. Ask which parameters it preserves and whether the required measurement parameter can pass safely. Retest both the repaired short route and the original direct route. The control matters because a broad redirect rewrite could fix one path while changing another.

Do not append a saved _gl value to the short link. That would turn a per-navigation value into a reusable address and would not validate the actual linker process. The source should generate a fresh decorated navigation under the supported implementation.

The text link works; a JavaScript button fails

Ask the developer how the button navigates. Does it expose an ordinary destination link? Does a script construct the URL after a click? Does another listener stop the event before the linker can process it?

Compare the actual request with the ordinary-link control. If the decorated navigation never appears, investigate event handling and the navigation mechanism. If it appears and later disappears, move to the redirect or destination. Those are different repairs even though both can end with an unlinked destination visit.

Preserve the button’s accessibility and business behaviour while fixing measurement. An analytics change should not prevent keyboard navigation, create duplicate departures or delay a reservation path unnecessarily. Test the interaction itself alongside the measurement result.

A form submission crosses the domain

A form-based transition deserves its own case. Do not assume that a passing anchor link proves a form action receives the same treatment. The developer reference includes a distinct decorate_forms setting, and its applicability depends on the implementation.

Have the developer confirm the supported configuration rather than adding an undocumented setting to whichever tag is easiest to edit. Test a valid submission, a validation error and the actual resulting navigation. The error case should leave the business form usable and should not be reported as a completed booking.

If the form posts to an endpoint that redirects, inspect both stages. The first request can carry data correctly while the redirect constructs a new destination without the required context. Again, the first changed boundary is more useful than a generic verdict that cross-domain tracking is broken.

The destination receives the linker but uses different identifiers

Check the destination’s effective configuration, consent state and timing. Is it sending to the same stream? Did it receive a fresh value? Is a custom setting overriding the intended domains? Does the integration actually support incoming linker handling?

Also check whether multiple implementations are competing. One destination event might use the intended state while another producer sends its own event. Comparing only the first convenient request can hide the overlap. Identify the producer and destination for the observations used in the verdict.

If the supported vendor integration does not expose enough evidence, record the check as unavailable. A configuration field labelled Analytics is not a substitute for the missing diagnostic capability. Ask the vendor for a supported test or retain a narrower claim.

Treat an embedded booking widget as an integration

An iframe can display a booking application without the visitor visibly leaving the public website. That appearance does not make the frame’s internal pages part of the parent page’s accessible document. Browser same-origin protections restrict interactions between different origins.

First establish what the widget does. Some open a separate page, some keep the flow inside a frame, and some switch between the two. The measurement approach must follow the actual mechanism rather than the visual appearance of the booking button.

Adding the vendor domain to the cross-domain list does not create a completion callback or let the parent inspect private frame contents. A supported vendor integration may expose a safe outcome event. If it does, validate its documented meaning and sender, and ensure the permitted payload excludes unnecessary personal information.

A generic message, frame load or resize is not booking acceptance. The widget may load correctly and then show no availability. It may send several messages while the user moves between steps. Count the defined business outcome only when the supported signal actually represents it.

Test storage-restricted browser conditions separately. A frame can behave differently from a top-level destination even when it uses the same vendor. Do not bypass browser protections, copy identifiers into arbitrary fields or assume that server-side delivery removes the privacy obligations.

When the vendor offers no permitted, validated outcome signal, measure the observable handoff or widget opening and retain booking totals in the operational system. Report the coverage honestly. A limited, accurate measure is more useful than a complete-looking funnel assembled from unrelated events.

Keep consent behaviour visible in the test

Run the consented control first if it is permitted by the organization’s design, then test denial and any supported change of choice. The expected result for a denied path is that collection follows the approved consent behaviour. Persistent identity is not the success criterion for that case.

Google’s consent-mode overview distinguishes basic implementations, where tags are blocked until consent, from advanced implementations that can send cookieless measurements under denied states. Consent mode adjusts tag behaviour; it does not obtain a visitor’s permission or decide the organization’s legal obligations.

Check the receiving site independently. A choice on the first domain is not proof that the booking application received or applied it. Ask how the consent system coordinates the transition, which defaults apply on arrival and when any update is processed.

The test should expose timing problems. If the destination sends an unexpected request before its intended default state is established, investigate that sequence. A later consent update cannot demonstrate that earlier behaviour matched the approved design.

Keep denied and consented observations separate in the results. A passing consented journey cannot clear a denied-path defect. An intentionally unobservable denied journey should not be relabelled as a technical failure solely because it lacks matching identifiers.

If the team needs a privacy interpretation, involve its appropriate privacy adviser. The technical review can document fields, timing and behaviour, but a successful linker test does not certify compliance. Do not enable additional collection just to remove uncertainty from an analytics report.

Explain falling outbound-click counts after setup

One unexpected effect is easy to misread: a booking link may stop generating GA4’s automatic outbound-click event after its destination is configured for cross-domain measurement. Google’s outbound-click tutorial explicitly documents this behaviour.

If the old booking report depended on that event, its total may fall even though customers still use the button. Before concluding that demand changed, compare the event definition and configuration change date. The measurement system may simply have stopped treating that destination as an ordinary outbound link.

If a handoff count remains useful, define and test a separate explicit event for that interaction. Check the existing producers before adding it so that a custom click listener does not overlap with another implementation. Name the report “booking handoffs” or another description matching the event’s actual meaning.

Keep the old and new definitions visible during reporting transitions. Do not join an automatic outbound-click series to a custom handoff series as though the measurement were unchanged. Test which buttons each includes, whether new-tab and mobile routes are covered, and whether accidental repeat clicks are relevant to the question.

The event should not be promoted to a completed-booking metric just because the destination is now connected. Cross-domain setup changes continuity. The business acceptance signal remains a separate requirement.

Handle payment providers without inventing visibility

A payment provider may sit between two measured pages while offering no supported page tagging for your implementation. In that case, the observable browser journey has an interval you cannot inspect. Record departure and any eligible return, while relying on the payment system for payment status.

A provider can also appear as a referral when the browser returns. Google’s unwanted-referral guidance identifies payment processors as a common use case. The setting affects referral treatment; it does not add measurement inside the processor or create shared identity on an untagged page.

Use a narrowly justified condition for the actual provider hostname. Retain a control from a legitimate referring website so that the change does not accidentally suppress useful acquisition information. Do not apply a broad rule merely because a cleaner source report looks preferable.

Expect historical complications. A new setting does not prove earlier referral assignments were rewritten, and returning-user context can explain why a previously recorded source still appears. Investigate the time period and reporting scope before deciding that the configuration failed.

Payment completion needs independent confirmation. Stripe’s Checkout fulfilment documentation explains why a landing page cannot be the sole authority: someone can pay without returning, and some payment methods complete later. The same design question applies when evaluating another provider’s supported integration.

For an authorized test, include a return with no confirmed payment and a successful test payment without a browser return, where the provider supports those cases. The first must not become a paid outcome. The second shows why operational payment totals and return-page views can differ legitimately.

Do not create an extra purchase merely to align the numbers. Establish the authoritative state, the permitted outcome integration and the retry behaviour. If duplicate purchase or booking events appear, use the GA4 duplicate-event guide to investigate their producers without altering a valid domain connection.

Keep booking completion separate from the journey

A reservation application can support browser continuity yet expose no reliable success event. The cross-domain task can be working while the completed-booking metric remains unavailable. Treat those as separate conclusions. A broken handoff hides which campaigns produce bookings, which makes lead generation reporting by source unreliable.

Define what acceptance means for the business. A saved reservation, a pending request, a paid appointment and an attended appointment are different states. A confirmation-looking page may be displayed for more than one of them. The event must match the state the report claims to count.

Where a vendor provides an outcome integration, ask how cancellations, retries, refreshes and separate new bookings behave. A user revisiting a confirmation page should not automatically create another completed reservation. A genuinely new reservation should remain eligible to count under the chosen definition.

Compare outcome events with a permitted operational record for the test. Do not put the customer’s details into the analytics payload or shared test log to make reconciliation easier. Use an approved, minimal method managed by the application owner.

For a lead form, the accepted-enquiry tracking guide shows why the application acceptance signal is stronger than a click. A booking vendor may offer a different integration, but the semantic question remains: what exactly happened when this event was generated?

Also distinguish event occurrences from unique users and qualified business outcomes. One measured browser can make more than one legitimate reservation. An Analytics user count is not a roster of named customers, and an accepted request is not necessarily a qualified opportunity or completed sale.

Review privacy before capturing the whole route

Booking and checkout URLs can contain private references, names or sensitive context. Review automatically collected page locations and titles as well as custom event fields. A clean event name does not protect a payload whose URL includes personal information.

Google’s PII guidance covers page URLs, titles and campaign dimensions. Keep personal contact details, patient information, appointment notes and private booking tokens outside the analytics implementation and public evidence files.

Google’s data-redaction documentation describes a best-effort safeguard and its limits. It does not replace source-side control of the data. It also explains masking of certain parameter values, including _gl, so a masked collected value is not by itself proof that the browser navigation lost the linker.

A clinic or another sensitive service should review the integration’s field list before enabling it. A treatment label combined with other context can be more revealing than a generic booking-stage event. If the vendor cannot restrict an inappropriate payload, keep the operational outcome in the appropriate system and use narrower public-site measurement.

Platform selection and the patient-facing booking experience deserve their own discussion. The online booking guide for clinics addresses that journey. This guide’s cross-domain checks should not become permission to collect everything visible inside a booking application.

Keep troubleshooting evidence small. A sanitized redirect summary and a matched/different verdict often answer the technical question without retaining a full browser archive. If detailed diagnostic files are necessary, handle them within the organization’s approved access and retention controls.

Use a compact test set that catches real failures

After the basic control, choose variants that could change the conclusion. For the fictional workshop, the direct desktop link and mobile short route are distinct cases because the second introduces a redirect. A different text colour on the same link does not necessarily require a new measurement case.

Write the precondition and expected result before running the case. Then record the observation. This prevents a surprising result from being retrospectively described as the plan. A blocked case should explain which capability or permission is missing.

Ask a second person to replay the most consequential route when practical. Give them enough context to reproduce it, including the consent state and timeout expectation. Their task is to verify the behaviour, not to endorse the original implementer’s conclusion.

If only browser navigation can be tested, say so. That can still establish a redirect defect or a destination failure. It cannot establish Google receipt, report processing or the meaning of a vendor’s booking state without the corresponding evidence.

Use the templates as a place for real observations

The GA4 cross-domain tracking kit provides blank domain-journey and acceptance-test CSVs, clearly fictional examples, a field dictionary and a README. These are manual planning and recording files; they do not connect to Analytics or change the website.

Start with the blank journey file and add one row for each meaningful transition. Record source, destination, mechanism, supported measurement relationship and the point where observation stops. A direct link and a redirect can share a destination while deserving separate rows.

Use the blank acceptance sheet for execution. If adapting a fictional row, clear its illustrative observations and evidence references, set the case to planned and not tested, and enter your own preconditions. Never inherit a pass from an example file.

The existing kit has local structure and logic checks, but those checks cannot validate Google’s collection or a booking vendor. The distinction is the same as in the opening trace: a well-formed test plan helps someone perform the work; it is not evidence that the implementation passed.

Keep the final decision concise: which route worked under which conditions, what remains unavailable, and which owner handles the first unresolved boundary. That is enough for a developer to act and for a reporting owner to label the available measures correctly.

Leave the report with an explanation people can trust

After a real repair, record its date and affected routes. “Mobile short-link redirect now preserves the required parameter” explains more than “tracking improved.” If the definition of a handoff event also changed, document that separately so later comparisons remain interpretable.

Do not calculate a booking completion rate from populations that do not belong together. Consented website handoffs and all operational bookings can differ because of direct arrivals, telephone bookings, returning visitors and unobserved journeys. Each total can be useful without their ratio becoming a valid funnel measure.

Recheck the affected route when the vendor, hostname, widget, consent platform, redirect or tag configuration changes. Include a previously passing control so the change is assessed in context. A good result is tied to the implementation and conditions that produced it.

Cross-domain work is complete when the team can explain the handoff accurately and support the intended measurement claim. If you need help separating a broken connection from a missing outcome integration, contact Canada Create with the domains and route you need to understand.

Frequently asked questions

What is cross-domain tracking in GA4?

It connects a visit on one website with activity on a separate domain, such as a booking or checkout site, as one journey. Both sites need the same GA4 web stream and the intended cross-domain configuration. It does not install a tag on the other site or give you a vendor's booking results.

How do I add a domain for cross-domain tracking in Google Analytics?

In GA4, go to Admin, then Data streams, choose your web stream, open Configure tag settings and then Configure your domains. List the cooperating domains, then test the actual link with a fresh browser journey. The receiving page should load, receive the linker information and send data to the correct destination.

Can two GA4 data streams replace cross-domain tracking for one website journey?

No. Google's setup guidance requires the same G- measurement ID from the same web data stream on the participating pages. A shared property name or a tag that looks similar does not create that relationship.

Why is GA4 cross-domain tracking not working?

A frequent cause is a redirect that strips the query string, so the _gl linker never reaches the destination. In the guide's example, a mobile button passes through a short-link domain, the booking page still opens, and GA4 records a new browser identifier and session. Compare a working route with a broken one to find the first point where they differ.

What is the _gl parameter in GA4 cross-domain links?

It is the linker parameter GA4 adds to a link between approved domains so the destination can continue the same browser and session. If it is missing or removed on arrival, the destination starts a separate identity. Typing a campaign label by hand does not replace it.

Does Google Analytics cross-domain tracking show bookings made on a vendor site?

Only if the vendor's site runs the same web stream through a supported integration and accepts the incoming linker. Even then, a completed booking needs its own validated outcome signal. Renaming a booking click as a completed reservation would hide the missing evidence.

Do subdomains need GA4 cross-domain tracking?

Sites under one parent domain can share a first-party cookie scope, so they often do not need the same setup. Check the existing cookie-domain configuration and how it actually behaves, because inconsistent settings still cause breaks. Avoid assuming either that every subdomain needs extra work or that shared branding keeps the journey connected.

Is Google Analytics discontinued, or is GA4 still the place to set up cross-domain tracking?

Google Analytics continues as GA4, which replaced the older Universal Analytics. Cross-domain measurement is set up in a GA4 web stream's tag settings. Configure it only for sites that belong to the same customer journey and can cooperate technically.