GA4 cross-domain tracking helps preserve a measurable journey when someone moves between websites that cooperate with the same analytics setup. For a business that sends visitors to a booking portal or a separate checkout, the useful question is specific: what can you actually verify before, during and after that handoff?
A booking button click shows an attempted departure. An event received from a booking platform may show a completed reservation. A payment return page shows that a browser came back. These observations answer different questions. Combining them under a single “conversion” label can make an incomplete journey look much more certain than it is.
This guide provides a domain journey map, a verification sequence and acceptance tests for those boundaries. For decisions about booking links, embeds and clinic website structure, start with online booking for clinics. Here, the focus is whether a particular implementation supports the measurement you want to use.
Method and limits: Public Google and vendor documentation was checked on 8 October 2026. Every worked business, domain and test observation below is fictional. No live GA4 property, booking integration, payment transaction or client implementation was tested for this guide. The companion files are planning and recording templates, not evidence that a website has passed.
Decide which claim your evidence can support
Before opening settings, write the decision the measurement must inform. “Which landing pages send people to our booking portal?” requires less evidence than “Which campaigns produce completed bookings?” A third question, “Which bookings become paid, attended appointments?”, requires operational records beyond browser navigation.
Use four separate evidence levels in your measurement plan:
- Handoff observed: the source website recorded an action intended to open another site.
- Destination activity observed: permitted measurement exists on the receiving site and records its activity.
- Continuity verified: the relevant source and destination observations retain the intended analytics identifiers under the tested conditions.
- Business outcome verified: an authoritative system confirms the defined booking or payment outcome.
Each level needs its own test. Destination activity without continuity can still be useful, but it cannot automatically answer which source visit produced it. Continuity without an outcome signal can describe navigation, but it cannot prove that a reservation exists. A successful business transaction can also occur without an observable browser return.
Write the reporting label at the same time as the requirement. For example, use “booking handoffs” when the available signal is a button event. Use “verified online reservations” only when the event definition, supported integration and reconciliation justify that phrase. Keep “paid” and “attended” separate unless those states are explicitly established.
Give unresolved evidence a visible status. “Unsupported by this integration” is more useful than an empty cell someone later interprets as zero. “Not tested” is different again: it means the capability may exist, but nobody has completed the agreed check. This vocabulary prevents optimistic settings from turning into unsupported business claims.
Map transitions, including the journeys that do not return
Build the map around a visitor’s route rather than a list of suppliers. One supplier can operate several hostnames, and one page can contain an embedded application from a different origin. Record the starting hostname, receiving hostname, navigation mechanism, responsible team and last observable step for every transition.
The following example describes an entirely fictional equipment workshop. Its public website and reservation site cooperate with one approved measurement setup. Its payment provider does not expose a supported browser tagging option in this scenario.
| Transition | Control and access | What the test must establish | Limit to record |
|---|---|---|---|
| workshop.example to reserve.example | Owned source; cooperating destination | Fresh link navigation, destination collection and identifier continuity | Booking completion still needs a separate signal |
| reserve.example to pay.example | Source accessible; payment page untagged in this scenario | Checkout handoff and supported payment behaviour | No claim about activity inside the payment page |
| pay.example to reserve.example | Receiving site accessible | Return collection, elapsed time and referral treatment | Return alone does not verify payment |
| Payment completed; browser closes | Operational system has the outcome | Reconciliation identifies the outcome independently of the return page | A browser journey can end before the business process does |
We plan and run B2B marketing across search, ads, content and email for Canadian companies.
Make alternate routes explicit. Include mobile and desktop buttons, links opening new tabs, direct arrival at the booking site, cancellation, an unavailable appointment, authentication and any payment failure path. Do not assume a desktop header button represents a mobile widget or an email link.
For each row, name the person who can investigate it. “Vendor” is too vague if the issue could involve a website redirect, a consent configuration or a booking platform’s event delivery. Assign ownership by boundary: the website developer owns the outgoing route, the receiving platform owner confirms supported behaviour, and the measurement owner decides what the evidence permits in reports.
A useful map also records where measurement deliberately stops. Mark account pages, intake forms and other sensitive areas as excluded where appropriate. That makes the boundary a design choice the team can preserve, rather than a gap somebody later tries to fill by collecting everything.
Check the actual vendor integration before choosing a setup
Owning the source website does not grant access to the destination. A “Google Analytics integration” label might describe page measurement, a vendor-generated outcome feed or a limited reporting feature. Ask for the documentation matching the exact integration name and current plan.
Jane illustrates why that distinction matters. Its standalone Google Analytics guide describes a booking-site setup with a separate property and measurement ID, and also points readers to Google’s cross-domain documentation. Those instructions need clarification if your objective is Google’s same-stream browser linking. Do not assume that two separate measurement IDs will become one continuous journey simply by adding domains in Admin.
Jane separately documents a Google Tags integration for Legacy or Thrive plans, with Account Owner access. Its comparison of the two integrations describes different data, including transaction values and treatment or service information in the conversion integration. These are documented capabilities; this guide has not verified them in an account. The comparison also describes broader conversion capture when cookie consent is absent. Verify the actual data flow and applicable consent controls before enabling it. The vendor description supplies no exemption from consent or privacy requirements.
For a clinic, the field list is a decision point. Do not enable a feed carrying health or personal information into analytics. Ask whether the supported integration can restrict its payload to approved, non-sensitive fields. If it cannot meet that requirement, keep those outcomes in the operational system and use the narrower measurement available on the public website.
Send the platform owner a short, concrete questionnaire:
- Which exact integration is available in this account, and who can administer it?
- Which pages or business outcomes does it measure, and which remain outside its coverage?
- Can the documented browser implementation participate in the intended web stream and handle incoming linker information?
- What fields leave the platform, and can prohibited or unnecessary fields be suppressed before transmission?
- How are consent choices applied, and how are retries, cancellations and repeated confirmation views handled?
- What authorised test environment and diagnostic evidence are available?
Request a dated response that identifies the integration rather than a general assurance that tracking is supported. A vendor-generated event might provide an outcome without making intermediate pages observable. Conversely, a visible confirmation page might provide a page view without proving the underlying booking state. Keep these as separate rows in the capability record.
If the answer remains uncertain, proceed with the source-side handoff measurement and an explicit reporting limit. There is no benefit in describing a booking funnel that the integration cannot actually observe.
Configure only the domains that can participate
Google’s current cross-domain setup instructions require the same G- measurement ID from the same web data stream on participating pages. The documented Admin route is Data streams, the web stream, Configure tag settings, then Configure your domains. Add the intended domain conditions and save. Google requires Editor access or above for the setup.
Before making that change in your own authorised environment, write down the current configuration. Record the property, web stream, exact hostnames and who controls each installation. A property name such as “Main Website” is not enough to distinguish a production stream from a similarly named test setup.
Use the narrowest domain conditions that cover the approved journey. Review the hostname the actual button opens, including regional or white-label variations. Test an intended match and a deliberately unrelated hostname against your proposed rules. This is especially useful where a broad matching condition could include another tenant or an unrelated destination.
Review subdomains too. Shared branding and a common parent name are not sufficient evidence that cookie settings and measurement behaviour are consistent. Record the existing cookie-domain configuration and test the actual handoff before deciding whether further configuration is necessary. Cookies remain scoped by domain; cross-domain linking does not let a page freely read another domain’s cookies. Check cookie availability separately from consent, and record browser restrictions without weakening them to obtain a pass.
Keep one owner for custom exceptions. Google’s developer guidance prefers the Analytics Admin route for GA4, but documents manual linker options. A custom linker configuration can override configured domain settings. Treat such an override as a developer-owned exception with a reason, a complete domain list and regression tests.
Do not add an inaccessible payment or booking hostname merely because it appears in the customer journey. First establish what that platform supports. The map can include an unmeasured destination without pretending it participates in browser continuity.
Keep personal and health information outside the measurement plan
A clean event name is not enough. Google’s PII guidance explains that page URLs and titles can transmit identifying information, and that both paths and parameters need attention. Review automatically collected fields as well as custom event parameters.
For this workflow, keep names, email addresses, phone numbers, appointment notes, health details, patient identifiers and private booking tokens out of analytics. Do not use them in campaign labels, URL fragments, page titles or the evidence worksheet. A value that looks like an opaque code may still be a reference to a person’s record.
Use generic labels such as “booking_handoff” and “primary_button” only where their surrounding context is also appropriate. For clinic journeys, check whether a service name, page path or title reveals sensitive treatment information. Replacing a patient name with an identifier does not make an otherwise sensitive payload suitable for a marketing report.
Do the review before collection. List the fields expected to leave each system, the purpose of each field and the person responsible for approving the list. Ask the developer or vendor to show how unwanted data is excluded at its source. If a platform supplies more than the permitted fields and cannot reduce them, that is a reason to narrow the integration.
Google’s data-redaction feature can help with email patterns and specified query parameters in web streams, but it works on a best-effort basis and does not cover Measurement Protocol or Data Import. Use it as an additional check, not as a substitute for controlling the payload.
Keep the test evidence small as well. Record “identifier matched” rather than pasting complete cookies or decorated URLs into a shared worksheet. If restricted diagnostic material is needed temporarily, keep it in an approved location with appropriate access and retention. A publicly shareable acceptance log should contain decisions and sanitised evidence references, not customer data.
Make consent a test condition on both sides
A continuity test needs a stated consent condition. Google’s consent-mode documentation distinguishes basic implementations that block tags until consent from advanced implementations that can send measurements without cookies while consent is denied. Consent mode adjusts tag behaviour; the organisation remains responsible for obtaining and applying the relevant choices.
Create separate test cases for a permitted consented journey, a denied journey and a changed choice. Record the expected collection behaviour for each. Do not use one successful consented test as evidence that the denied path behaves correctly.
Check the receiving platform independently. A preference chosen on the first website is not proof that the second has received, understood or applied it. Ask how the consent solution supports that transition, then inspect the resulting behaviour in an authorised test. A tag that fires before the destination’s default consent state is established needs investigation.
For a denied test, success means the implementation follows the agreed consent design. It does not mean that identifiers remain linkable. Do not force continuity by copying identifiers into custom parameters, using fingerprinting or treating a server-side route as an exemption. If measurement is intentionally unavailable, record that limit.
Also separate missing debug evidence from missing transmission. Google’s DebugView guidance notes that client-side privacy controls or absent consent for Analytics cookies can prevent events from appearing there. An empty DebugView alone cannot establish that no request left the browser.
A practical sign-off therefore has two parts: the consent owner confirms the intended behaviour, and the technical owner checks the implementation against it. Keep a failed privacy condition open even if the marketing reports otherwise look plausible. Useful measurement depends on respecting the boundary, not on maximising the number of observable steps.
Trace one fresh journey from the source to the destination
Start with a short, consented control journey in an authorised non-production environment where available. Record the browser, device, route, start time and applicable timeout. Close unrelated test tabs so you can distinguish this run from another person’s activity. Use dummy business records that the platform permits, without adding personal or health information.
Open the browser’s network tools before navigating. Chrome documents how to inspect requests in its Network panel guide. Enable Preserve log to retain requests across page loads, then follow the route through intermediate responses. Record the initial request, each redirect and the final destination, using sanitised summaries in the worksheet.
Google’s verification sequence includes checking that the receiving page loads and that the navigation carries the _gl linker parameter. Its troubleshooting guidance identifies stripped parameters, JavaScript navigation and interrupted click propagation as possible failure points. Use those as hypotheses to investigate, not as a diagnosis inferred from a missing report row.
The linker check must use a fresh action. Google’s developer documentation states that linker parameters expire after two minutes and are added at click time. A copied decorated URL opened much later is therefore a different test. Do not distribute a saved linker URL as a reusable test fixture.
Next, compare the measurement state on each participating side. A developer can use the Google tag’s documented get API to inspect client_id and session_id for the intended GA4 target where the integration exposes that capability. Record whether the values match, without storing the values in the public worksheet. An unavailable value is not a match.
Check emitted events as well. A setting value or matching cookie does not establish that the destination sent the intended observation to the intended stream. The get API can return a manually assigned field, so compare its result with permitted event evidence rather than treating the API response alone as proof. For the permitted test, confirm an expected source event and destination event, then inspect the corresponding debug evidence where available. Retain separate results for identifier continuity and event receipt.
Finally, test the return route. Do not assume that a successful outbound transition validates the reverse direction. A return can arrive through a different hostname, after a different delay or through a different mechanism. Record those differences rather than combining both directions into one “cross-domain passed” checkbox.
This sequence creates a useful ladder of evidence: navigation happened, permitted measurement existed, identifiers behaved as expected, and the intended events were observed. Stop at the first unsupported step. The next repair belongs to that boundary, even if later events happen to appear elsewhere in the property.
Define session continuity without demanding an impossible result
Specify the time conditions before evaluating a session. Google documents a default timeout of 30 minutes of inactivity and permits a different web timeout. A session ID is not globally unique by itself; Google’s session guidance recommends combining it with a user identifier when analysing sessions outside Analytics.
For a quick control run with permitted cookies, a shared measurement setup and an active session, your acceptance rule can require the intended identifiers to remain consistent across the participating domains. For a run with an inactivity gap beyond the configured timeout, a new session can be expected. Do not extend the timeout merely to make every test look continuous.
Separate the practical checks into three columns: same measured browser identity, same eligible active session, and expected session acquisition source. These can fail independently. An attribution label that looks correct does not prove that the source and destination shared a session. Matching session identifiers do not establish that a booking event is semantically correct.
Use a clean test profile and a documented entry route when acquisition matters. Previous activity can complicate interpretation. Avoid adding campaign labels to an internal booking handoff just to make the next hostname easy to find; use the journey log and safe event parameters for diagnostic separation instead.
When reviewing reports, compare the same scope. Session acquisition and first-user acquisition answer different questions. Write down the dimension you inspected, the date range and any filters. If the reporting evidence is not yet available, leave that portion pending while preserving the browser evidence. Do not convert a provisional technical result into a claim about all historical traffic.
Handle payment referrals separately from payment outcomes
A payment provider can appear in a return journey without being a participating analytics domain. Google’s unwanted-referral documentation identifies third-party payment processors as a common use case. Its settings can prevent specified referrers from being treated as traffic sources; they do not supply observations from inside the provider’s pages.
For an untagged processor, record the boundary honestly: activity is observed before departure and again on an eligible return, with an unobserved interval between them. Add a narrowly justified unwanted-referral condition only after checking that the hostname represents a payment handoff rather than a legitimate acquisition source.
Keep a control case from a legitimate referring site. It should remain recognisable after the payment-related change. Broadly suppressing referral information can make an acquisition report look tidier while removing useful sources. Also remember that the change does not rewrite the evidence from earlier test runs or establish that old source labels have disappeared from every report.
Payment success needs its own authority. Stripe’s hosted Checkout fulfilment documentation explains why an application cannot rely only on the landing page: a customer may pay without reaching it, and some payment methods complete later. That principle is useful when designing analytics acceptance criteria, even if your business uses a different processor.
Ask the application owner which operational state confirms payment, when that state becomes final for the chosen method and how retries are handled. A generic return parameter or a visit to a success-looking URL is insufficient on its own. Keep the operational confirmation in the appropriate system; expose only the minimal permitted analytics outcome where supported.
Include two negative tests: returning without a confirmed payment and completing a permitted test payment without returning. The first must not become a paid outcome. The second demonstrates why browser-return counts and operational payment counts should not be expected to match perfectly.
Use acceptance criteria that another person can reproduce
Each case needs a precondition, action, expected observation and verdict. Use not_tested, pass, fail or blocked. A blocked case requires a reason and an owner; it is not a partial pass. Keep fictional example observations in a separate file so they cannot be mistaken for completed checks.
| Case | Action and precondition | Acceptance evidence |
|---|---|---|
| Fresh cooperating-domain link | Use the actual button during an eligible active, consented session | Destination works; intended events and identifier continuity are verified |
| Redirect variant | Repeat through every documented intermediate hostname | Each hop is accounted for; final measurement agrees with the approved design |
| Mobile, form or new-tab route | Use each supported navigation mechanism separately | The actual route meets its own expected behaviour |
| Iframe and restricted-cookie route | Test the actual embedded flow and a browser with the documented storage restrictions | Only supported signals are accepted; cookie-based continuity and completion remain unverified when evidence is unavailable |
| Consent denied or changed | Apply the approved denied state or revoke a previous choice | Collection follows the consent design; continuity is not forced |
| Payment return and no return | Use authorised test transactions for both paths | Payment truth is determined independently of browser return |
| Inactive return | Exceed the configured inactivity timeout before returning | A possible new session is interpreted against the timing evidence |
| Repeat or cancelled outcome | Refresh, revisit, cancel or retry a supported test flow | The outcome definition prevents false or duplicate success claims |
| Privacy review | Inspect permitted outbound data throughout the synthetic journey | No personal or health information is transmitted in the reviewed fields |
Do not turn the matrix into an indiscriminate browser-testing project. Prioritise the routes customers actually use, then include a small set of failures likely to change the conclusion. A mobile booking widget, a redirect and a payment return may deserve separate cases even when all desktop text links already work.
Have someone other than the person making the change replay the important cases where practical. Give them the preconditions and expected behaviour, not an instruction to confirm that tracking is fixed. Their job is to produce a defensible verdict, including a failure or blocked status when the evidence requires it.
Record the tested scope precisely. A result from one browser and one route does not certify every browser, device, vendor configuration or future release. If an operational test environment is unavailable, document that blocker and retain the narrower browser-only conclusion.
Diagnose the first broken boundary
The direct link works, but the branded short route fails
In a fictional test, the main reservation URL passes while the short booking address fails. Compare the two navigation traces and look for the first difference. The short route may involve a hostname absent from the configuration or a redirect that changes the URL. Assign the evidence to the owner of that hop and rerun both routes after the repair. Do not change unrelated event definitions to compensate.
The text link works, but the booking widget does not
First establish whether the widget navigates, submits a form or remains inside an iframe. These mechanisms need different checks. Browser same-origin restrictions limit what a parent page can inspect in a cross-origin frame. A supported vendor callback may be needed to observe an internal widget outcome; adding a domain condition does not create one. If a callback is available, the developer should verify its documented sender and outcome meaning. An iframe loading or sending a generic message does not establish completion. Keep outcome visibility blocked when the vendor supplies no permitted, validated signal.
For form-based transitions, Google’s developer reference documents a distinct decorate_forms linker option. Have the developer confirm the applicable implementation before changing it. Preserve the form’s business behaviour and test validation errors as well as successful submissions. Analytics must not make an otherwise usable booking path fail.
Booking-click totals fall after the domain configuration changes
Check whether the old metric depended on enhanced-measurement outbound clicks. Google states that links to configured cross-domain destinations do not produce those automatic outbound click events. This can explain a measurement change without establishing a customer-behaviour change. See Google’s outbound-click tutorial.
If a handoff count is still needed, give it an explicit, independently tested event definition. Check for overlap with the existing click implementation before enabling it. Keep the label at “handoff” even if the button says “Book now”; the label on a button does not prove what happened on the next site.
Continuity passes, but completed bookings are still unavailable
This is a capability boundary, not necessarily a broken linker. Ask what authoritative success signal exists, whether it is permitted to leave the platform and whether its meaning has been validated. If the answer is “none”, keep the completion field unsupported. Adding more page views cannot manufacture a booking record.
One completed action appears more than once
List every producer of the outcome: a website event, a platform integration, a derived Analytics event and any server-side delivery. Then examine refreshes, back-button navigation and delivery retries separately. Give one owner responsibility for the event’s counting rule. Duplicate investigation belongs with the event-definition and duplicate-event repair owners; it does not require redefining a valid domain journey.
The linker looks absent or redacted in a report
Inspect navigation evidence separately from analytics fields. Google’s redaction documentation notes that some parameters, including _gl, have their values masked. A masked value in collected data is not evidence that navigation lost the parameter. Equally, a parameter seen in navigation is not proof of successful destination collection. Test both stages before choosing a repair.
Work through a fictional investigation
Suppose the fictional workshop sees reservation-site traffic but cannot explain how it relates to its public website. The owner initially asks to label every booking button event as a completed reservation. The measurement lead instead writes two questions: did the browser reach the cooperating site with continuity, and did that site confirm a reservation?
The planning map identifies two routes from workshop.example to reserve.example. The desktop button uses a direct link. The mobile button goes through go.example. A later payment step uses pay.example, which is outside the hypothetical browser integration. These are invented hostnames, not addresses to test.
The first illustrative observation is that the desktop route retains the expected identifiers and produces the expected destination event. That supports a narrow statement about this imagined control run. It does not yet support a completed-booking metric. The fictional platform owner has not supplied a validated success signal.
The second illustrative observation is that the mobile route reaches the reservation site but loses continuity. The imagined navigation record shows the divergence at the intermediate redirect. The team assigns that boundary to the redirect owner and keeps the mobile case open. It does not average the desktop and mobile results into an overall percentage of “correct tracking”.
The third illustrative observation concerns payment. A returning test browser produces a page event, but the pretend operational record still says the payment is pending. The team refuses to count that page as a paid reservation. Later, an imagined successful payment without a browser return appears only in the operational record. Both cases demonstrate why return traffic is a partial view.
The final fictional decision is deliberately limited: the desktop handoff is suitable for the stated navigation question; mobile continuity needs repair; booking completion remains unverified; payment status belongs to the operational record until a permitted outcome integration is validated. The report labels follow those decisions.
This is the kind of useful result the worksheet should produce. It identifies what can inform a decision now, what requires a technical change and what depends on vendor capability. It does not promise perfect attribution or turn an incomplete implementation into a marketing success story.
Use the companion templates without importing invented evidence
Download the GA4 cross-domain tracking kit (ZIP) for the blank templates and fictional examples described below.
The companion set contains a domain-journey CSV, an acceptance-test CSV, blank and fictional versions of each, a JSON field dictionary and a README. It is intentionally small enough to maintain in a spreadsheet. The files do not connect to GA4, send events or change a website.
Start with the blank journey file and add one row per transition. Use the fictional file only to understand the level of detail. Replace examples with your approved hostnames and capability evidence; keep private URLs and personal data out of the worksheet.
Next, copy the acceptance cases that fit the journey. Set evidence_type to planned and status to not_tested; clear observed, evidence_ref and tested_at_utc. Replace fictional hostnames and capability references in the journey map with approved ones. Fill in preconditions before testing. Put actual observations in a separate column after the action has been performed, with a sanitised evidence reference and a named role responsible for follow-up. A missing observation cannot justify a pass.
You can also start the two blank worksheets by copying these complete headers into separate text files and saving them as UTF-8 CSV:
transition_id,source_host,destination_host,mechanism,control,measurement_relationship,consent_expectation,observable_limit,capability_evidence_ref,owner
test_id,transition_id,evidence_type,precondition,action,expected,observed,status,evidence_ref,tested_at_utc,owner
The companion dictionary explains consent expectations, timestamps and evidence types. Their fictional observations are labelled fictional_example and never use a live pass verdict. Local synthetic checks of template structure do not test Google’s collection, vendor behaviour, browser consent or report processing. Those implementation tests still need to be performed in an authorised environment.
Make the configuration change visible in reporting
When a repair changes what is observable, create a dated annotation in the team’s reporting record. Describe the affected routes and event labels. “Mobile redirect repaired” is more informative than “tracking improved”, because it tells the next analyst which comparisons need care.
Keep a small before-and-after inventory of definitions. If the earlier report counted outbound clicks and the later report counts a custom handoff event, document the difference before comparing totals. If completed reservations only become measurable after a new integration, the earlier absence is unknown coverage, not proof of zero demand.
Choose denominators that belong to the same observable population. A count of consented website handoffs and a total of all operational bookings may each be useful, but dividing one by the other does not automatically produce a booking completion rate. Direct arrivals, telephone bookings, return visits, cancellations and unobserved journeys can make the populations different.
For the first review after a change, present the evidence in three separate lines: what changed technically, what collection is now verified, and what business interpretation remains provisional. This gives the owner a usable explanation without crediting the repair with additional customers that have not been independently established.
Close the investigation with a usable measurement decision
End with a short decision record rather than a screenshot of settings. State which routes were tested, what business questions they can support, which conditions remain blocked and who owns each unresolved boundary. Include the test date and the relevant configuration version so a future change can be compared against it.
Keep responsibilities clear. The lead-event specification owns what counts as a real enquiry or completed booking. The tag-management owner controls deployment and overlapping event producers. The broader GA4 audit assesses whether the property’s numbers are fit for decisions. This cross-domain record supplies boundary-specific evidence to those owners without replacing their work.
Schedule a new check when a relevant dependency changes: booking vendor, hostname, redirect, consent platform, widget, payment route or tag configuration. Rerun the affected cases and at least one previously passing control. A supported integration today can behave differently after the route or configuration changes.
The deliverable should let a business owner say, in plain language, “We can measure these handoffs under these conditions; these completed outcomes are independently confirmed; these parts remain unknown.” That is enough to support a narrower, honest report while the remaining work proceeds.
Ask Canada Create to review your domain journey and measurement requirements.
