Skip to content
Menu
← Guide libraryTracking and journey events · Analytics resolution guide

Abrasim tracking and analytics guide

Cross-Domain, Subdomain or Payment Journeys Break the Session

Keep permitted journey evidence connected across domains and payment steps.

By Published Evidence reviewed

For
E-commerce Lead, Developer or Analytics Lead
Decision to make
Reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect.
Scope boundary
The tracking route described here and its production tests. Rebuilding the whole platform is outside this guide.

What the problem looks like and why it affects the business

If users move from the main site to a booking, application or payment domain and return as a new session or referral, the journey can split exactly where commercial intent becomes strongest.

Bottom line: Acquisition sources lose credit, checkout abandonment is misdiagnosed and returning payment traffic can make the processor look like the channel that created demand.

Use this guide to keep permitted journey evidence connected across domains and payment steps. It is written for e-commerce leads, developers or analytics leads. Confirm budget approval with the e-commerce, digital product or revenue owner. Scope: The tracking route described here and its production tests. Rebuilding the whole platform is outside this guide. Check commercial figures against the authoritative source, keep correlation separate from causation and collect only data that serves the decision.

What you should be able to decide

Use the evidence to decide what to keep, correct, investigate, pause or retire. The task is to reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect.

What to expect in the working pack

The Cross-Domain Journey Reconciliation Pack contains six XLSX sheets to complete as you follow the method:

  1. Decision charter records the decision about “cross domain subdomain or payment journeys break the session”, its authority, economic or service exposure, scope and evidence threshold.
  2. Metric contracts prevents labels from hiding different populations, periods, exclusions or meanings.
  3. Collection and lineage traces permitted records and events from source through transformation and destination.
  4. QA and reconciliation keeps expected results, observed results, discrepancies and evidence classifications separate.
  5. Issues and actions converts verified problems into owned, reversible work with acceptance gates.
  6. Decision and learning log preserves the decision, confidence, limitation, review date, observed outcome and reopen trigger.

Open the pack before Step 1. Record the task to reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect. Use stable IDs such as DEC-001, MET-001, LIN-001 and TST-001 to connect the decision to its sources and tests. Update the sheets as you work so the audit trail does not depend on memory.

What evidence distinguishes the real cause

One dashboard cannot establish the cause. To keep permitted journey evidence connected across domains and payment steps, compare relevant operational, customer, CRM, finance and platform evidence using authorised sources.

EvidenceWhat it distinguishesMinimum record
Domain journey mapWhere users cross ownership boundariesSource domain, destination, navigation method, return path and owner
Tag and stream parityWhether each owned step uses the intended implementationTag ID, stream, cookie domain, environment and page coverage
Linker evidenceWhether continuity information survives movementOrigin URL, destination URL, linker presence, redirect chain and form behaviour
Referral evidenceWhether processors or owned domains overwrite acquisitionSession source, referral domain, return event and configuration
Transaction reconciliationWhether the completed journey remains connected to one accepted orderTransaction ID, order source, timestamps, session evidence and exceptions

To keep permitted journey evidence connected across domains and payment steps, label each material item VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION. A verified item has an authoritative source or reproducible test; it does not make the conclusion universally true. Explain inferences and alternative causes. Keep proposed controls separate from existing ones, and mark missing authority, access or evidence as requiring validation.

Establish the metric contracts before interpreting movement

Use the definitions below in Metric contracts to keep permitted journey evidence connected across domains and payment steps. Agree any changes with the accountable owners. These are working definitions, not universal benchmarks.

MeasureWorking definitionEligible populationPeriodSourceExclusions
Journey continuity rateEligible cross-domain test journeys retaining the intended session continuity divided by eligible test journeysApproved cross-domain testsRelease test windowURL, cookie and analytics evidenceJourneys where consent or policy prevents continuity
Processor referral rateEligible return sessions attributed to a payment or owned utility domain divided by eligible return sessionsEligible return sessionsProduction review windowGA4 acquisition evidenceGenuine external referrals
Transaction linkage rateAuthoritative transactions matched to one eligible analytics purchase journey divided by sampled authoritative transactionsAuthoritative transaction sampleMature transaction cohortOrder system and analyticsTransactions outside the approved match boundary

For “cross domain subdomain or payment journeys break the session”, capture data freshness, sampling, thresholding, cardinality, missing values and late-arriving outcomes wherever they could change the decision. A platform can correctly process the data it received while the organisation still has the wrong definition, an incomplete population or an unsafe conclusion.

How to fix it step by step

Step 1: Charter the decision and the exposure

Write the exact decision before discussing a dashboard, event or metric: Reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect. Name the accountable authority, the economic or customer exposure, the scope boundary and the latest useful decision date.

Use in the working pack: Decision charter.

Required output: A charter for “cross domain subdomain or payment journeys break the session” with a stable Charter ID, named authority, scope, evidence threshold and a condition for stopping or escalating.

Decision gate: Agree who can authorise this task before continuing: Reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect.

Step 2: Preserve the current evidence before changing it

Capture the reports, source records, definitions, dates, filters, exclusions, versions and meeting or workflow evidence that currently produce the symptom. Map every domain, subdomain, embedded provider, redirect and return route in the real purchase or application journey, including JavaScript and form navigation.

Use in the working pack: Decision charter and QA and reconciliation.

Required output: A dated current-state record of “cross domain subdomain or payment journeys break the session” that another reviewer can reproduce without relying on screenshots alone.

Decision gate: For this investigation, treat missing source access, unexplained transformations or changed historical reports as visible limitations, not permission to infer the missing evidence.

Step 3: Define the measures and their boundaries

Define which owned domains require continuity and which third-party domains should remain external; verify common tag and stream configuration where applicable. For each retained measure, write the name, definition, eligible population, period, dimensions, source of truth, exclusions, owner and version.

Use in the working pack: Metric contracts.

Required output: Metric contracts for the decision to reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect, with distinct definitions for unlike measures.

Decision gate: Reproduce each measure from authorised evidence. A platform display cannot, by itself, support the decision to reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect.

Step 4: Trace source, collection and transformation

Configure and test cross-domain behaviour, cookie scope and unwanted referrals without treating an exclusion list as a substitute for journey continuity. Link the originating record or permitted event through every material transformation and destination. Record consent or lawful-use state when personal information or identifiers are present.

Use in the working pack: Collection and lineage.

Required output: A source-to-decision lineage for “cross domain subdomain or payment journeys break the session” that exposes broken, duplicated, delayed, transformed or non-comparable evidence.

Decision gate: Pause work on cross domain subdomain or payment journeys break the session wherever the source records and transformations cannot explain the reported value.

Step 5: Test contradictions and negative cases

Run clean-browser journeys across consent choices, devices, direct entry, redirects, payment success, cancellation, retry and delayed return while preserving URL and network evidence. Use a bounded sample that includes normal records, exceptions, missing values, delayed outcomes, duplicates and a case expected to fail. Record expected and observed evidence separately.

Use in the working pack: QA and reconciliation.

Required output: Reproducible tests for “cross domain subdomain or payment journeys break the session” with source evidence, destination evidence, discrepancies, disposition and retest ownership.

Decision gate: Include failed and exception cases when investigating cross domain subdomain or payment journeys break the session. Evidence that passes only the easiest route or hides important contradictions is insufficient.

Step 6: Choose, own and release the correction

Turn each verified gap into an action with severity, affected decision, evidence reference, owner, dependency, rollback trigger and acceptance gate. Reconcile the final transaction or accepted outcome, record unmatchable populations and release only when redirects preserve required parameters and attribution limits remain visible.

Use in the working pack: Issues and actions.

Required output: Prioritised actions for “cross-domain, subdomain or payment journeys break the session”, with definition, collection, source, operating and decision-use changes recorded separately.

Decision gate: The owner must accept the corrected evidence for its intended use: Keep permitted journey evidence connected across domains and payment steps. Confirm its limits before release; technical completion alone is insufficient.

Step 7: Record the decision and later learning

Record the decision about “cross domain subdomain or payment journeys break the session”, who made it, which evidence was used, the confidence and every known limitation. Assign the action and schedule a review after enough time has passed for the relevant outcome or guardrail to be observed.

Use in the working pack: Decision and learning log.

Required output: A recorded decision that can be checked against this acceptance condition: Required domain transitions preserve permitted continuity, processors and owned utility domains do not overwrite acquisition, redirects and forms pass tests, and sampled outcomes reconcile without claiming perfect identity.

Decision gate: A changed report does not resolve “cross domain subdomain or payment journeys break the session”. Close the work when the owner accepts the evidence for the decision and schedules a later outcome review.

Who must be involved

ResponsibilityMinimum role
Accountable decisionE-commerce Lead, Developer or Analytics Lead with authority for the affected decision
Metric meaningBusiness or functional owner who can accept the definition and exclusions
Source and transformationAuthorised system, analytics or data owner who can reproduce the lineage
Commercial or service reconciliationFinance, CRM, sales, service or operational owner appropriate to the claimed outcome
Privacy and controlInformation Officer, privacy, security or legal authority when personal information, protected groups or material control consequences are in scope
Independent challengeA person sufficiently independent of the original design or performance incentive to test contrary evidence

The six value paths cross functional budgets, evidence and ownership; diagnosis therefore needs cross-functional authority, access and independent challenge, whether led internally or externally. A capable internal team can lead when it has the required authority, source access, domain competence and ability to challenge the original assumptions. Escalate or use qualified external support where material evidence is contested, privacy or legal judgement is required, system access is fragmented, or the same incentives that produced the measure could suppress contrary findings.

Worked example

Orders are reported as referrals from a payment gateway. The team finds that the outbound link carries continuity information but an intermediate redirect strips it. The redirect is corrected, payment success and cancellation are retested, and unmatched orders remain visible instead of being forced into a source.

This is a hypothetical method example, not an Abrasim client result, benchmark or performance promise.

How to verify the data can support the decision

To check whether the correction supports the task to reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect, test collection, definitions, reconciliation, decision use and later outcomes separately. A firing tag, populated report or better-looking dashboard is insufficient:

  • Collection gate: the permitted event or record needed for “cross domain subdomain or payment journeys break the session” is observed with the expected fields and consent or lawful-use state.
  • Definition gate: the metric can be reproduced from its contract, population, period, exclusions and version.
  • Reconciliation gate: representative normal and exception records agree with the authoritative source within an approved, explained tolerance.
  • Decision gate: the accountable owner can interpret the measure, its confidence and its limits and can choose an authorised action.
  • Outcome gate: after the relevant lag, the action and later customer, operational, commercial or risk evidence are reviewed separately.

Accept the work only when: Required domain transitions preserve permitted continuity, processors and owned utility domains do not overwrite acquisition, redirects and forms pass tests, and sampled outcomes reconcile without claiming perfect identity.

Use at least one negative case. Adding a payment processor to unwanted referrals can hide the visible symptom while the user and session still split across the journey.

Record failed tests for “cross domain subdomain or payment journeys break the session” rather than deleting or overwriting them. Reopen the decision when the definition, source, transformation, ownership, material market condition or observed relationship changes. Roll back a release that duplicates outcomes, hides an unknown population, breaks a control, exposes personal information or removes an evidence path needed for this decision.

How to keep the problem from returning

  • Retest every domain and return path after checkout, redirect or consent changes.
  • Keep domain ownership and tag parity in the release inventory.
  • Monitor processor referrals and transaction linkage as separate controls.
  • Review metric contracts, lineage and decision use at the recorded review-by date and after material system or operating changes.
  • Retain source evidence and version history long enough for the authorised review while following approved access, retention and deletion controls.
  • Keep implementation acceptance, operating adoption and later business movement as separate records.

Primary sources and evidence boundary

Primary guidance was reviewed at the 30 August 2026 source cutoff:

The sources above establish controls relevant to “cross domain subdomain or payment journeys break the session”; they do not prove Abrasim client outcomes or the cause of a specific organisation's performance. POPIA, privacy, employment, financial and sector-specific decisions remain with qualified authorised owners.

Where definitions, sources, ownership or commercial consequences remain contested, Repair journey continuity and attribution inputs. You can use this guide internally. Seek support when the decision needs cross-team access, independent challenge or assurance over a high-risk change.

Use the method with AI

A prompt to help you work through this guide

Use this prompt to organise your analysis. Share only evidence you are authorised to provide to that model. A person must remain responsible for the decision, privacy limits and final action.

Copy and adapt

You are helping me apply the Abrasim tracking and analytics guide: “Cross-Domain, Subdomain or Payment Journeys Break the Session”.

Situation: cross domain subdomain or payment journeys break the session
Decision to make: Reconcile linker settings, referrals, cookies, domains, consent and payment returns without pretending identity is perfect.
Scope boundary: The tracking route described here and its production tests. Rebuilding the whole platform is outside this guide.

Use only the evidence I provide. Do not invent facts, benchmarks, sources, outcomes, customer research or legal conclusions. Keep VERIFIED, OBSERVED, INFERRED, PROPOSED and UNKNOWN separate. Ask focused questions when the evidence or authority is missing.

Help me work through this method by returning:
1. An evidence table with claim, source, date, confidence and limitation.
2. The strongest competing explanations, including what would disprove each one.
3. Decision options with trade-offs, dependencies and the cost of waiting where evidence supports it.
4. The next smallest evidence-gathering action, its accountable owner and acceptance test.
5. A proceed, change, validate, defer or stop recommendation that a named human decision-maker can review.

Treat the attached Abrasim working pack as a blank working record. Do not fill missing rows with plausible data. Flag privacy/POPIA, security, accessibility, safety and authority issues. Cite primary sources for external claims and show uncertainty. End with the conditions that would make us change course or stop.

My organisation-specific evidence and constraints:
[Paste evidence, links, dates, decisions and limitations here]

Working rule: AI can help organise evidence and expose questions; it cannot establish truth, approve risk, make the business decision or replace qualified legal, privacy, security or accessibility review.

When the evidence crosses teams

Get the right teams involved in the decision.

The six value paths cross functional budgets, evidence and ownership; diagnosis therefore needs cross-functional authority, access and independent challenge, whether led internally or externally.

Repair journey continuity and attribution inputs