Real-time attribution: from 14 days to 60 seconds.
Most attribution platforms were built when daily batch was the only practical option. They've inherited that latency as a constraint. Here's why <60s closure changes the operator playbook — and the engineering it actually requires.
The latency every operator silently accepts
Ask any growth operator at a $10M GMV DTC brand when they last looked at their attribution dashboard. They'll say "this morning." Ask when the data they're looking at was actually generated. They'll say "yesterday." Probably the day before.
The standard stack — Triple Whale, Northbeam, Klaviyo's revenue dashboards, Looker — operates on overnight batch jobs. The pixel fires; the conversion lands in the data warehouse; the attribution model runs at midnight; the dashboard refreshes by 8am. Operators read at 9am. By 11am they're acting on insights from 36 hours ago.
For most of e-commerce history, this was fine. The ad auctions moved on a daily cadence; budgets were set weekly; campaigns ran for months. A 24-hour latency was inside the planning loop.
That stopped being true around 2022. The ad platforms moved to real-time bidding with hour-by-hour auction dynamics. Campaign performance volatility doubled. The 24-hour latency moved outside the planning loop. You're now optimising for yesterday's auction, against today's competitors.
What changes at 60 seconds
The most useful way to think about attribution latency isn't "how recent is the report" but "how recent are the decisions it enables."
At 24-hour latency, you can adjust budgets. That's it. By the time the data is available, the day's auction is over.
At 4-hour latency, you can adjust bids twice per day. That's a meaningful improvement, but the bidding system can still drift between your adjustments.
At 60-second latency, you can adjust bids inside the auction. The Google Ads bid that's running right now can be modified based on the conversion that just happened. The Meta CAPI conversion uploaded 90 seconds ago can change the audience model that's targeting right now.
This isn't a quantitative improvement. It's a qualitative shift in what the system can do.
The architecture problem
You can't get to 60-second attribution by speeding up a batch job. The architecture is wrong.
Batch attribution looks like this:
1. Pixel fires → event lands in event collector
2. Hourly job dedupes + writes to data warehouse
3. Nightly job stitches identity (cookie → customer)
4. Nightly job runs the attribution model
5. Dashboard refreshes from materialised viewEven if you compress each step, the structure is sequential and the slowest step is your floor. Most batch systems are floor-limited at 4 hours, optimistically.
Real-time attribution requires an event bus, not a data warehouse:
1. Pixel fires → event bus
2. Identity resolver subscribes → stitches inline → publishes resolved event
3. Attribution worker subscribes → computes all 7 models in parallel → publishes attributed event
4. Rollup service subscribes → updates per-channel aggregates → publishes rollup event
5. Dashboard subscribes to rollup events → live UIEvery stage is a subscriber to the previous stage's published events. There is no batch step. There is no "wait for the next cycle." The pipeline pulls events through as they arrive.
At Sumeru, this pipeline runs on BullMQ workers with self-throttling helpers. P95 from pixel-fire to dashboard-refresh is 42 seconds; P99 is 78 seconds. The slowest worker is the identity resolver, which has to do a Shopify customer-ID lookup for new visitors; everything else is sub-second.
The trade-offs honest engineering will admit
Real-time attribution is not strictly better than batch. Two genuine trade-offs:
1. Methodology rigour vs latency. Northbeam-grade Marketing Mix Modelling requires daily aggregation; you can't compute a Bayesian MMM posterior on a per-event basis. If your boardroom needs MMM, you want a measurement-grade tool. Sumeru's MTA-only approach is faster but not the same shape of attribution.
2. Operational complexity. A batch system has one failure mode: the job didn't run. A real-time pipeline has many: identity lookup timed out, the bus is back-pressured, the attribution worker is rate-limited, the rollup service has a stale cache. The reliability surface is larger.
The engineering response is to invest in dead-letter handling, idempotency keys, exponential-backoff retries, and per-stage observability. That's not free. It's worth doing only if the latency unlock justifies it.
When 60-second attribution is worth the engineering
Three operator profiles where real-time matters:
Paid-spend optimisation under volatility. If your ad auctions are competitive (most DTC, most B2B with high CAC), the auction shifts hour-by-hour. Real-time attribution lets your bid optimiser react inside the auction window, not after. Customers report 11–18% blended ROAS lift in the first quarter post-deployment.
Cart-recovery routing. A cart abandon at 14:32 should trigger a recovery message at 14:38, on the customer's preferred channel, with a tier-appropriate discount. By tomorrow morning, the customer has either bought elsewhere or moved on. Real-time attribution lets the recovery flow route through the highest-conversion channel this customer uses, not the channel everyone defaults to.
SEO decay-to-action. A top-10 page slips at 09:14. Sumeru detects it by 09:15, queues an AI refresh draft by 09:42, an editor approves at 11:08, the page republishes by 11:14. By Friday the position recovers. Batch attribution detects it Monday; the position is gone by then.
What this requires from the data plane
Real-time attribution is a system property, not a feature. You can't bolt it onto a batch pipeline. The data plane has to be event-driven from ingest to dashboard, with identity stitching happening inline, parallel model computation, and every stage observable.
Sumeru's runtime was built for this shape. The same event bus handles attribution, decay detection, automation triggers, and orchestration plans. The 7 attribution models all run in parallel — last-click, first-click, linear, time-decay, position-based, custom-weighted, model-blended — and the spread is surfaced to the operator, not collapsed into a single number.
The architectural decision compounds: if every product feature lives on the event bus, you don't have to re-implement real-time semantics per feature. Attribution is real-time, decay detection is real-time, automation triggers are real-time, audit logging is real-time. The runtime is one thing.
Where to start if you're evaluating
Three diagnostic questions before adopting any real-time attribution system:
- What's your current attribution latency? If you don't know, look at the dashboard's "last updated" timestamp during business hours.
- What's your tightest decision loop? If you're adjusting bids weekly, real-time doesn't help. If you're adjusting hourly, it changes everything.
- What's the cost of getting it wrong? If your blended ROAS volatility is <5%, real-time isn't worth the complexity. If it's >20%, it might be the highest-ROI engineering investment available.
The questions above are the ones we walk through on every Sumeru evaluation call. If two or three resonate, we're built for you. If they don't, a measurement-grade tool like Northbeam or a polished dashboard like Triple Whale is probably the better fit.
If you want to see real-time attribution against your own data, request a comparison — we run Sumeru alongside your current tool for 30 minutes and walk through where the allocations diverge. /contact or read the Revenue Attribution Engine page for the full architecture.