Fixing New vs Returning Drift in Cross-Channel ROAS Reporting

Why “new vs returning” drifts and why it breaks cohort ROAS

“New vs returning” looks like a simple dimension, but in cross-channel reporting it’s one of the easiest labels to corrupt. The problem isn’t that analysts don’t know what “new” means. It’s that identity gets rewritten across tools and time: browsers lose cookies, devices change, users authenticate later, and CRMs backfill histories after the fact.

When those shifts happen, a customer can slide between “new” and “returning” depending on the platform you’re looking at. That turns cohort ROAS into a moving target: your “new customer” cohort appears to perform worse over time, not because performance changed, but because the cohort membership did.

The three main causes: identity changes, cookie loss, and CRM backfills

1) Identity changes across channels

Most ad platforms, analytics tools, and CRMs each maintain their own identity graph. Even if they all track the same person, they often do it with different keys:

• Ad platforms: click IDs, device IDs, modeled conversions
• Web analytics: first-party cookies, client IDs, user IDs (if implemented)
• CRM: email, account ID, lead/contact IDs

As soon as a user signs up or logs in, your system may start using a stable user ID. But ad and analytics platforms might still treat earlier sessions as anonymous. If you later stitch those sessions to the logged-in identity, “new vs returning” can change retroactively depending on where the stitching happens.

2) Cookie loss and browser restrictions

Cookie loss is not just “some traffic becomes unattributed.” It actively distorts your cohorts:

• A returning customer on a new browser profile looks “new.”
• A returning customer on a mobile app vs web looks “new” in web analytics.
• Shorter cookie lifetimes compress the lookback window, inflating “new” counts.

This creates a common ROAS reporting trap: you optimize spend based on apparent “new customer” efficiency, but you’re actually paying to reacquire people you already had—just without a surviving identifier.

3) CRM backfills and delayed identity resolution

CRMs and downstream systems often backfill data after key events:

• A lead becomes a customer later, and historical touchpoints get re-associated.
• Offline conversions import after a delay, updating earlier periods.
• Duplicate contacts get merged, rewriting “first seen” dates.

Backfills are usually correct from a customer-record perspective, but they’re brutal for cohort ROAS if your reporting logic assumes that cohort membership is immutable after day 0. Without guardrails, the same revenue can migrate from a “new” cohort to a “returning” cohort weeks later.

How drift shows up in cross-channel ROAS

Teams typically notice drift as one (or more) of these symptoms:

• New-customer ROAS steadily deteriorates even when blended ROAS is stable.
• Channel-level new vs returning splits don’t reconcile between ad platforms and analytics.
• Historical dashboards keep changing, especially after CRM syncs or offline uploads.
• Prospecting looks inefficient because “new” is inflated by cookie resets and device switching.

One subtle but important amplifier is time alignment: if spend is booked by spend date but conversions are later reclassified by updated identity, the “new vs returning” breakdown becomes even noisier. If you’re seeing inconsistent ROAS windows, it’s worth also addressing date alignment; this is closely related to fixing the spend vs conversion date mismatch for reliable ROAS reporting.

A practical framework to stop cohort membership from moving

Step 1: Define “new” once, in business terms

Start with a definition that survives tool boundaries. For cohort ROAS, the most durable anchor is usually:

• New customer = first paid transaction date (or first activation event) for a deduplicated person/account.
• Returning = any subsequent transaction/activation after that first date.

This sounds obvious, but many stacks quietly use “first website session,” “first cookie,” or “first time seen in GA4” as a proxy. Those are identity-dependent and will drift by design.

Step 2: Pick a canonical identity key and freeze it

Choose the primary key that decides cohort membership across all reporting. Common choices:

• Account ID (B2B and subscriptions)
• Customer ID from billing (often the cleanest)
• Email hash (only if governance allows and it’s consistently captured)

Then implement a rule: once a canonical customer ID is assigned to an event, the event’s cohort classification should not change in historical reporting—even if later merges happen. Instead of rewriting history, record merges as a separate lineage table (old IDs → new ID) and decide how far back you’re willing to restate metrics.

Step 3: Separate identity resolution from performance reporting

A lot of drift happens because identity resolution is treated as a “live enrichment” step that continuously updates old rows. Instead:

• Maintain an event log that is append-only.
• Maintain an identity map that can evolve.
• Materialize reporting tables on a schedule, with versioning (or snapshots) so you can explain changes.

This is where marketing data infrastructure matters. A platform like Funnel.io is useful not because it magically fixes identity, but because it helps standardize and deliver channel data into an analysis-ready source of truth where you can apply consistent cohort logic, transformations, naming harmonization, and KPI calculations across channels.

Step 4: Introduce a “newness confidence” flag

Instead of forcing every conversion into a binary bucket, add a second dimension that reflects how solid the classification is:

• Confirmed new: tied to canonical customer ID with first purchase date
• Likely new: no prior customer record, but identity is cookie-based
• Unknown: missing identifiers or conflicting signals

This prevents your ROAS decisions from leaning too hard on the noisiest slice. It also makes it easier to see when browser changes or CRM sync delays are reshaping your “new” pool.

Step 5: Set explicit restatement rules for backfills

Backfills will happen—offline conversions, late CRM updates, merges. The fix is policy, not wishful thinking. Decide and document:

• Restatement window (e.g., metrics can change for 14 days, then freeze)
• Which fields are restatable (revenue, attribution, cohort labels)
• How restatements are communicated (dashboard annotations, changelog)

This is essentially a data contract for marketing performance metrics. If you’re building data products across tools, it’s worth formalizing this approach similar to a practical data contract across CRM, ERP, and billing, even if you’re not using AI agents—because the underlying issue is the same: consistent definitions and controlled change.

What “fixed” looks like in dashboards

Once you implement the framework, you should see:

• Stable historical “new vs returning” counts (outside your chosen restatement window)
• Less divergence between channel reports and warehouse reports, because the warehouse becomes the cohort authority
• More credible cohort ROAS curves, where changes reflect performance—not reclassification

The goal isn’t perfection; it’s predictability. When cohort membership stops moving underneath you, cross-channel budget decisions get simpler, and the conversations shift from “whose number is right?” to “what should we do next?”