The order is real. The cause is a model.

Consider a fictional order, ORD-4821. We can reconstruct its chronology without pretending every event carries the same weight. The useful object is not a single “email conversion” row. It is a chain of source records with timestamps, identifiers, and confidence.

1. 01

   08:04 · Delivery accepted

   The receiving server accepts the campaign message. This proves acceptance at that boundary, not inbox placement or attention.

2. 02

   08:16 · Link requested

   The campaign link is requested. Scanner classification and surrounding browser activity determine whether the report calls it machine, uncertain, or likely human.

3. 03

   08:17 · Session begins

   A landing session carries campaign parameters and a first-party session identifier. The URL evidence survives even if the eventual purchase happens later.

4. 04

   08:21 · Identity resolves

   The visitor signs in. Under the workspace’s permitted identity policy, the browser session can now join the known customer profile with an explicit confidence level.

5. 05

   Next day · Direct return

   The customer types the store address on a laptop. Direct is the observed session source; a last non-direct model may still look back to email.

6. 06

   10:42 · Purchase recorded

   The commerce system emits ORD-4821 for 120 revenue units with a durable transaction ID. That is observed gross revenue, not yet channel credit.

7. 07

   Day six · Partial refund

   A 20-unit item is refunded against ORD-4821. Retained revenue is now 100 units, and every downstream attribution view should reconcile to that change.

The click itself also needs care. Link scanners and security systems can create requests that resemble engagement. The field note on email click tracking, bots, and human intent explains why a raw request should not become a high-confidence touchpoint automatically. The same caution applies one rung earlier: an open is an image request, not a reliable witness to attention.

The clean diagram assumes one person, one browser, and one uninterrupted trail. Real customers click on a phone, compare on a work computer, ask a partner, and purchase through an app. A first-party account ID can connect signed-in activity across devices when that use is disclosed, permitted, and consistently implemented. It cannot honestly connect activity that was never identified.

Keep unknown gaps unknown. A deterministic account join, a device-level identifier, and a modeled association should not share one undifferentiated “customer” label. Google Analytics, for example, documents User-ID, device ID, and modeling as separate identity spaces. The chosen reporting identity can change the journey a report appears to see.

This is why attribution depends on more than the email tool. Moosewave integrations preserve source events from the store, product, and customer systems, while the audience layer keeps eligibility and customer state distinct from a model’s channel credit.

Suppose the observed path is Organic Search → Email A → Paid Social → Email B → Direct → 100 units of retained order value. The table below applies familiar models to that same evidence. First-click, linear, and position-based views remain useful concepts in custom analysis, but Google Analytics retired those rule-based models from its attribution reports in November 2023. A report should say what it actually computes, not borrow a model name from an older interface.

Attribution models divide known credit. They are still valuable: teams need stable operational reporting, channel comparisons, and paths worth investigating. The mistake is treating a different allocation as a different sale, or a sophisticated allocation as proof of causality.

A seven-day click window asks whether a qualifying email click occurred during the seven days before purchase. A 30-day window admits more touches. It does not make the order larger or the older interaction more causal; it changes which records are eligible for credit.

Choose the window before opening the performance report. Ground it in the normal decision cycle and the message’s purpose: a same-day replenishment reminder, a weekly launch, and a considered subscription do not need identical windows. If 24-hour, seven-day, and 30-day views reverse the conclusion, show the sensitivity instead of choosing the flattering one.

The window belongs in the metric’s name, not in a hidden settings panel.

Also keep event time and reporting time straight. A December order can receive credit from a November touch if the window allows it. Google Analytics documents both event-time and interaction-time reporting because the chosen date boundary changes which side of a monthly report receives the credit.

Our example begins at 120 units and ends at 100 after a partial refund. A dashboard that keeps the original 120 indefinitely is measuring checkout value, not retained revenue. Preserve the purchase and refund as separate immutable source events, join them by transaction ID, and derive gross, refunded, and net values for the selected reporting date.

Deduplication matters just as much. A purchase confirmation page can reload, a server event can retry, and two analytics libraries can emit the same order. A durable transaction ID lets the measurement layer reject duplicates without deleting legitimate repeat purchases. Google Analytics likewise recommends transaction IDs to minimize duplicate key events and defines a refund event for full and partial refunds.

Decide whether the business question uses order date, refund date, or a maturation period, then state it. Finance may close a month one way while lifecycle teams use a rolling retained revenue view. Both can be valid if each report reconciles to the same commerce records and declares its timing policy.

Moosewave’s commerce connection keeps the source transaction and adjustments beside the message path, so attribution can be recalculated when the order changes rather than frozen at the thank-you page.

Now change the question from “which touch gets credit?” to “what happened because we sent?” Imagine 10,000 eligible recipients randomized before a campaign. The numbers below are illustrative, not a benchmark.

Suppose the seven-day last-touch report assigned 315 orders, or 31,500 net revenue units, to email. That does not contradict the experiment’s estimate of 90 incremental orders and 9,000 units. Attribution asks which observed orders meet a credit rule. The holdout estimates how many orders exceeded the baseline that would likely have occurred anyway.

The transparent arithmetic is only a point estimate. A real analysis needs uncertainty intervals and enough statistical power. Randomization must happen before exposure; treatment and holdout need the same eligibility rules and observation period; mandatory transactional messages should continue; and overlapping promotions can contaminate the contrast. Unequal allocation is acceptable, but the comparison must use rates or correctly scaled totals.

Analyze assignment, not only successful delivery or observed opens. Excluding hard-to-reach treatment recipients after randomization can break comparability. Record suppressions, delivery failures, cross-channel contact, and the number of observations; decide the success metric and duration in advance; and avoid repeatedly peeking until noise looks like a win. Google’s own lift documentation makes the same conceptual separation between standard attributed conversions and incremental conversions estimated from treatment and control.

A trustworthy report does not force every question into one heroic number. It shows observed orders and refunds from the commerce ledger, attributed revenue under a named model and window, and experiment estimates with their assignment, uncertainty, exclusions, and contamination notes.

In Moosewave, an order keeps its source identity while models produce versioned views. Change the attribution window and the allocation can be recomputed without rewriting the event history. Connect a refund and retained revenue updates. Resolve a signed-in identity and the path gains a confirmed join rather than a silent merge. Campaign, audience, and experiment membership remain inspectable.

The useful dashboard can therefore say, at the same time: “email received 31,500 units under seven-day last non-direct attribution,” “the store retained 100 units on ORD-4821,” and “the holdout estimated 9,000 incremental revenue units, subject to this interval.” Those statements do not compete. Together, they tell the operator what happened, how credit was allocated, and what the campaign may have caused.

Open the interactive Moosewave walkthrough to follow audience selection, sending, and outcomes through one connected workspace. The product should make it easier to ask a narrower question, not easier to overstate the answer.