Attribution infrastructure
Systems that decide which touchpoint gets credit for an outcome — under uncertainty, with incomplete data, and participants who benefit from the answer.
Most of my professional work sits in attribution — the problem of deciding which of several possible causes gets credit for an outcome. It is a measurement problem wearing an engineering problem’s clothes.
Why it is harder than it sounds
The honest answer to “what caused this?” is almost never available. There is no counterfactual: you cannot observe the version of the world where the touchpoint didn’t happen. So the system doesn’t discover the truth, it applies a rule — and the rule has to be defensible, consistent, and fast.
That makes the constraints unusual for backend work:
- The participants are not neutral. Everyone in the chain benefits from being assigned the credit, and some of them will structure their behaviour around whatever the rule rewards. Correctness has to survive that pressure.
- Data arrives late, out of order, and incomplete. The decision often has to be made before all of the evidence exists, and revised when it turns up.
- Deduplication is the real problem. When several parties can each present a plausible claim on the same outcome, deciding between them deterministically is most of the work.
- Being wrong is invisible. A system that mis-assigns credit returns a perfectly well-formed answer. There is no exception, no alert, no crash — just a number that is quietly incorrect. Almost all of the engineering rigour goes into catching that class of failure.
Why it stayed interesting
I took the work because it was large-scale backend, and stayed with it because the hard part turned out not to be the scale. It is the epistemics: what can you actually claim from the evidence you have, and how much of the answer is the data versus the rule you chose.
That question has become considerably more relevant to me lately, for reasons that have nothing to do with the day job.