Methodology brief

The math is open. The machine is the product.

Anyone can compute a contribution value once. What we built is the system that computes them continuously, at scale, on live operations, records every prediction before anyone acts, and grades itself after. This page says exactly how, including the parts we refuse to claim.

01Two stages, kept separate.

The system does two different jobs and does not let them blur.

Measurement answers: over this trailing window, what did each part of the operation actually contribute to the outcome you declared, relative to its cost? That is an attribution of observed value, not a forecast.

Prediction answers: if you shift the spend, what happens? That is a model fit on top of the measured contributions, and it ships with its uncertainty attached.

Keeping them separate means a bad forecast never rewrites what was measured, and you can always check the measurement layer independently of any model we fit on it.

Fig. 2 · Measurement and prediction, kept separate; the record beneath both.

02Measurement: contribution by coalition.

We treat the units you can act on as players in a cooperative game: partners, segments, supply paths, and creative lanes in media; machines, interventions, prompts, or datasets elsewhere; whatever level the decision lives at. The value function is your declared outcome over the window, against cost. The contribution score for each player is its Shapley value: its average marginal contribution across orderings of the players.

Two properties matter in practice. The decomposition is exhaustive: by the efficiency axiom the parts sum exactly to the observed total, so nothing is invented and nothing is left over. And it is interaction-aware: a unit that only works when another one is present gets credited for that, which last-touch logic structurally cannot do.

Exact enumeration is used when the player set is small. Above roughly twenty players we switch to complementary contribution sampling, which scales to hundreds of interacting players and returns each estimate together with its sampling variance. That variance is not decoration; it feeds the intervals in section 04.

Overlapping segments are handled explicitly with intersection data rather than assumed away. And alongside the coalition family we run a second attribution family with different assumptions, Markov removal effects over path data, as a cross-check. Where the two families disagree, the disagreement is reported as a finding, not averaged into a single number.

In plain termsWe measure what each piece earned by asking what the whole would have delivered without it, every combination at once, and the pieces always add back up to your actual total.

03The move, and what we expect from it.

Every recommendation is a specific move: shift this, pause that. It comes with what we expect to happen, written down before you act. Then reality grades it, and the next recommendation is better for it. A trailing number tells you how the spend behaved, not which move to make next.

Under each recommendation is a response curve fit per unit on the measured contributions: contributed outcome against spend over the trailing window. The expected result of a move is read from the local slope at your current level, and the fit's uncertainty is carried into the range that ships with it.

When more than one outcome matters, the objectives are weighted the way you declare, not the way a model finds convenient, and the allocation recommendation is solved as a constrained optimization over the levers you actually control. Budgets, floors, minimums, and anything you fence off stay fenced off.

In plain termsThe read never says a unit is good or bad. It names a move, says what we expect it to do, with a range, and stands ready to be graded on it.

04Every number carries its interval.

Uncertainty enters twice and we carry both: sampling variance from the contribution estimator, and fit uncertainty from the response curve on the window. The interval printed next to an estimate is the combination, at a declared level. Working surfaces print 80% central bands so the ranges stay honest at a glance; formal reads run at 95% where a decision warrants it. The level is always stated on the surface that shows the number.

The refusalWhere the data is thin, the band is wide, and below a declared support floor the system prints "not enough data yet" instead of a number. A confident-looking estimate we cannot support is treated as a defect, not a deliverable.

05The loop is the asset. The record is its memory.

This is the part that is not in a paper, and it is the reason the system gets better on your data instead of just describing it.

Every analysis run is an ablation: same data, one thing changed or removed, difference measured. Every run is recorded with its inputs, settings, window, estimate, and band. When the system recommends a move, the predicted result is written down before anyone acts. Then the action that actually happened is logged, including "did nothing." Then the mature outcome is measured, against a holdout slice where the design allows one, and the prediction is graded against it. The grade feeds the next run.

Append-only. The log is never rewritten. Wrong predictions stay with their grades, because the misses are what teach the next run, and the record is how you know when to lean on the system and when not to.
Reproducible. Any past read can be re-run against the same inputs and settings and produce the same answer. Your team can audit any number back to its run.
Yours to model. The measured contribution dataset is handed back to you. Your team can fit their own models against it and disagree with ours. Model debates are healthy; the measurement layer is the shared ground.
Recommend mode. The system proposes, predicts, and grades itself. People make the moves. Authority to act directly is something the track record earns, at the pace you choose, never something the software assumes.

1Measuredecompose the window: contribution against cost, at every level you can act on

2Predictthe recommended move, with its expected result and band, on the record first

3Actyou make the change; what actually ran is logged, including no change

4Graderealized against predicted, versus the holdout slice

5Adjustthe grade recalibrates the next run; the loop repeats day after day

Some predictions miss. The loop is built for the miss: the grade lands within days, the correction feeds the next run, and the correction compounds. Being right every time is not the design goal; finding out fast is.

The loop runs at every altitude at once, and as its memory compounds, the same loop extends to decisions above and below the ones it started on.

The loop is in production on live campaign spend today; graded results are shared in diligence, not on websites.

06The level of detail is a declared choice.

A property of coalition attribution worth being straight about: the grand total is preserved at any granularity, but the per-player values at a coarse level are not the rollup of the values at a finer level. Partner-level, segment-level, and path-level runs are different games with different coalition structures. So we do not quietly pick a level. Every read states the level it was run at, and when a decision needs a finer level, we run that level rather than dividing a coarse answer.

07What this is, next to controlled experiments.

Holdout and lift experiments answer whether a thing works at all. They are slow by design and they cost you a dark cell. This system answers a different question: inside the operation you are already running, which parts are earning their price right now. The two compose. An experiment sets the ceiling and the weight; the decomposition allocates underneath that ceiling, and the built-in holdout slice keeps grading us while everything stays live.

What we do not claimThis is an observational decomposition of live operations, not a randomized experiment. Where causal identification is weak, the read says so, and where your experimental results disagree with ours, that disagreement is surfaced to you, argued in writing, and settled by the next measurable window.

08How it's delivered.

Everything above ships as something your team can run, not just read. It runs as a capability your agents call as a tool, as a standalone application your team logs into, or both at once. It runs in our cloud, in yours, or in your customer's, in any combination.

And it is open to being built further. Your team extends it, runs its own models on the measurement layer, and wires it into workflows we never see.

In plain termsThe method is not a service you mail data to. It is a capability that moves into however you work.

09Ask the read why.

Any number on a read can be questioned in plain language, right where you are looking at the data: why is this partner flagged, what happens if I move this, what should I do next. Answers cite the record behind the number, the runs, settings, and grades it came from, and refuse to go beyond what that record supports. A question the record cannot answer gets "the record doesn't show that yet," not a guess.

Today this is how the capability is used agentically: your agents and analysts put questions to it through the same tool surface the reads come from. Where this goes: a packaged assistant for customer teams, on top of the same record. That is a direction, not a shipped product.

10What it takes to start.

An NDA and DPA, log-level exports from the systems that produce them (programmatic platforms, CTV, ad servers), your outcome table keyed however you key it, and one trailing window. Walled-garden spend exports less; the first read covers what your systems hand over and states its coverage. It is checkable against what you already believe before you act on anything.

What the daily read looks like → The API and MCP surface →