Your Attribution Dashboard Can’t Fix Broken Events
Before debating models and reporting windows, make sure the behavior underneath the report is being captured correctly.
- Analytics Architecture
- Attribution
- Data Quality
- Event Tracking
- MarTech
Most attribution problems aren’t actually attribution problems. They’re event integrity problems.
A campaign looks wrong. A channel looks underreported. A lifecycle step doesn’t match what the team expected. A funnel report starts creating more arguments than answers.
The default response is usually to debate the dashboard: attribution model, reporting window, source of truth, platform configuration, channel taxonomy.
Sometimes that’s the right place to look.
But a lot of the time, the problem is further upstream.
The event is missing. Or duplicated. Or delayed. Or misnamed. Or attached to the wrong user, session, account, lifecycle stage, campaign, or timezone.
The reporting layer isn’t necessarily wrong. It may just be faithfully visualizing a distorted event stream.
Attribution Is Downstream from Instrumentation
A dashboard can tell you that a conversion didn’t happen according to the data it received. That doesn’t necessarily mean the conversion didn’t happen.
Maybe the event never fired. Maybe it fired twice, once from the browser and once from the server, without a shared identifier to deduplicate it. Maybe a user crossed an authentication boundary and the event ended up attached to a different identity. Maybe the timestamp describes when the event was processed rather than when it occurred.
Those are different problems with different solutions. None of them gets fixed by changing an attribution model.
And that’s why this matters: if the behavioral data underneath the report is inconsistent, the dashboard can make the problem easier to see, but it can’t make the signal trustworthy.
Look at the Events Before You Look at the Report
When the numbers don’t line up, I’d rather start by following a few actual user journeys through the tracking system than spending another hour debating the dashboard.
A useful first pass is surprisingly straightforward:
| Question | What could be going wrong? |
|---|---|
| Did it fire? | Missing events, broken triggers, or paths nobody instrumented |
| Did it fire once? | Duplicate browser/server calls, repeat submissions, or missing deduplication |
| Did it arrive on time? | Queues, retries, delayed delivery, or mismatched event and processing timestamps |
| Is it the right event? | Inconsistent names, changed payloads, or lifecycle stages that mean different things in different places |
| Does it belong to the right entity? | Lost session context, incorrect user or account associations, or identity changes during the journey |
| Did the context survive? | Missing campaign parameters, incorrect timezones, or metadata dropped along the way |
You don’t need to inspect every event in the system to learn something. Pick a meaningful conversion path, follow it end to end, and compare what the application actually did with what the downstream platforms received.
A tag firing successfully isn’t the same as an event being correct. The name, payload, identity, timing, and delivery path all matter.
Event Observability Is Part of the Growth System
This is where I notice a lot of growth systems needing more than reporting.
They need some level of observability into the events themselves: what is firing, when it’s firing, how it’s structured, whether the payloads are consistent, and how those events move across sessions, accounts, campaigns, and lifecycle states.
That doesn’t mean every team needs custom internal tooling or a giant data platform. Start with the events that actually drive decisions. Make their contracts clear. Have a way to inspect what was emitted and what arrived downstream. Give someone ownership of fixing the problems that inevitably surface.
I’ve written before about how tracking shortcuts become architecture and why not every product event belongs in the marketing stack. This is another part of the same problem: before deciding what data to send or how to interpret it, you need confidence that the data describes what actually happened.
None of this eliminates the need to think carefully about attribution models. Those decisions still matter. But they belong on top of trustworthy instrumentation, not in place of it.
If product behavior is going to drive marketing decisions, event integrity has to be treated as part of the growth system itself.
Otherwise, teams end up optimizing against a picture of user behavior that may already be distorted before it ever reaches the dashboard.