Advertising money and measurement systems turn ad outcomes into charges, budget feedback, advertiser reports, attribution results, incrementality experiment results, and model-training labels. They start after serving has selected an ad, because the server-side winner still needs client and user events before the advertiser can be charged or credited with an outcome.
RunCo can win a sneaker-ad allocation and still spend nothing if the creative fails to load, the user scrolls away before impression measurement, the product bills on clicks and no valid click arrives, or the billing notice never reaches the buyer. A billing notice is the event or callback that tells the buyer-side system that the seller-side path considers the impression chargeable. The money loop maps those messy outcomes into one financial and reporting story.
Billing Events And Spend Mapping
These terms define the strength of evidence as an ad moves from server selection to a financial charge.
| Event | What it proves | Spend implication |
|---|---|---|
| Insertion / selection | Server chose an ad and returned render instructions. | Debugging and auction accounting; usually upstream of billing. |
| Render attempt | Client began loading the creative. | Client diagnostics and render reliability. |
| Impression | Product counted an exposure according to its rule. | Charge basis for impression-priced products when validity checks pass. |
| Viewable impression | Exposure met the contracted pixel/time threshold; viewability is the measurement rule for whether enough of the ad was on screen long enough. | Charge or reporting basis when the deal requires viewability. |
| Click or engagement | User interaction passed redirect, dedupe, and invalid-click filters. | Charge basis for click- or engagement-priced products. |
| Conversion | Advertiser observed a downstream action such as purchase or signup. | Optimization label, attributed outcome, or action-priced charge basis. |
One served ad turns into spend through this chain:
- Serving emits insertion, auction, winner, price-basis, and serving-time-version records.
- Client and server paths emit render, impression, viewability, click, engagement, and conversion records.
- Dedupe logic collapses retries and replays to one counted record per event key.
- The counted record joins to the campaign, ad group, creative, and pricing state used when the ad served.
- The ad product billing rule selects the chargeable event and computes the amount.
- A ledger transaction or spend aggregate records provisional spend.
- Pacing reads provisional spend to adjust throttling or bid multipliers.
- Reconciliation applies invalid-traffic filtering, credits, corrections, and invoice finality.
Earlier charge events give pacing fresher spend. Later charge events reduce false positives but make spend feedback lag the auction.
Programmatic Win And Billing Notices
OpenRTB is the common request/response format used across programmatic sell-side platforms, exchanges, and demand-side platforms. In that format, win and billing are separate records.
| Field | Meaning |
|---|---|
nurl | Win notice. The exchange tells the bidder that its bid won. |
burl | Billing notice. The exchange tells the bidder that the impression satisfied the billing rule. |
| Impression/click trackers | Integration-specific callbacks for render, impression, viewability, click, or conversion records. |
OpenRTB integrations keep win, render, impression, viewability, click, conversion, and billing notice as separate records because each one can fail independently.
Budgeting Spend And Pacing
Budgeting defines how much an advertiser is allowed or expected to spend. Pacing is the budget-control loop that decides how aggressively the campaign should enter future auctions so spend follows that budget over time. The pacing controller is the service or streaming job that reads spend state, compares it with the campaign’s target spend curve, and writes a compact serving signal: enter normally, stop, throttle, or apply a bid multiplier.
RunCo’s daily budget is 1,000 USD. At noon, the target spend from the pacing curve is 500 USD. The platform sees 420 USD of confirmed spend and estimates 60 USD of in-flight spend from recent chargeable events still waiting for processing. A pacing controller that reads only confirmed spend treats RunCo as 80 USD behind. A pacing controller that also estimates in-flight spend treats RunCo as 20 USD behind. That difference changes bid multipliers, throttling, and overspend risk.
The diagram follows one control cycle: serving reads a lightweight pacing output, events update spend, and the pacing controller writes the next serving control. The expensive spend computation stays outside the request path.
Spend has several clocks:
| Spend state | Meaning | Used for |
|---|---|---|
| Confirmed spend | Events accepted by the spend pipeline after validation and deduplication. | Reporting, ledger-adjacent aggregates, stable pacing input. |
| In-flight spend | Estimated charges from recent wins, impressions, clicks, or engagements still waiting for confirmation. | Overspend protection during bursts. |
| Reconciled spend | Corrected spend after fraud filtering, credits, exchange/vendor settlement, or billing adjustments. | Final reporting, invoices, backfills, model labels. |
Serving should read a small pacing output: eligible, stopped, throttled, or bid multiplier. Spend computation belongs in the event path, where raw events can be deduplicated, joined, corrected, and replayed.
Pacing can act through several controls:
| Control | Mechanism | Failure mode |
|---|---|---|
| Hard stop | Serving stops entering auctions once estimated spend reaches a cap. | RunCo can miss later high-value inventory after cheap early inventory consumed the cap. |
| Probabilistic throttling | Serving skips eligible opportunities with some probability. | Random dropping can remove valuable sparse opportunities. |
| Bid multiplier | Pacing controller raises or lowers bids based on pacing error. | Aggressive multipliers can chase noisy spend estimates. |
| Target-to-date curve | Pacing controller compares current spend with planned spend for the current time. | Delayed or duplicated events make the pacing controller chase the wrong spend number. |
Measurement, Attribution, And Incrementality
Measurement, attribution, and incrementality answer three different questions about outcomes after ads run. Attribution assigns reporting credit to prior ad touchpoints. Incrementality estimates the extra behavior caused by advertising by comparing an exposed group with a comparable control group that did not receive the ad. Ads Attribution and Incrementality owns the detailed distinction; this note focuses on how the resulting events feed spend, pacing, and reporting.
An advertising lift estimate is the measured difference between those two groups. If RunCo shows the sneaker campaign to one region and holds out a similar region, and the exposed region produces 1,200 purchases while the holdout-adjusted baseline predicts 1,000 purchases, the estimated conversion lift is 200 incremental purchases. Brand-lift studies use the same idea with survey outcomes such as ad recall or purchase intent instead of purchases.
| Layer | Question |
|---|---|
| Measurement | Did the platform observe the outcome and match it to the advertiser? |
| Attribution | Which earlier ad touchpoint receives reporting credit? |
| Incrementality | How much extra behavior did the campaign cause compared with a holdout or modeled baseline? |
RunCo’s sneaker ad is shown on Monday. The same user clicks on Tuesday. The user buys shoes on Friday.
| Step | Event | System question | Typical output |
|---|---|---|---|
| Monday | Ad impression | Did serving logs record that RunCo’s ad was shown? | Impression touchpoint. |
| Tuesday | Click | Did the click carry a key that can later match a purchase? | Click touchpoint, often with a click id. |
| Friday | Purchase | Did RunCo send the purchase through a tag, server-side endpoint, mobile partner, offline upload, or clean-room workflow? | Raw conversion event. |
| After Friday | Matching | Can the platform link the purchase to an allowed identifier or event key? | Matched conversion, modeled conversion, or unattributed conversion. A modeled conversion is statistically estimated when direct matching is incomplete. |
| Reporting | Attribution | Which touchpoint receives credit under the configured window and model? | Conversion credit assigned to the Tuesday click, Monday impression, both fractionally, or neither. |
| Experiment analysis | Incrementality | How many purchases disappear when comparable users do not receive the ad? | Incremental purchases, incremental revenue, brand-lift percentage, or another lift result. |
The platform might observe the Friday purchase and credit the Tuesday click in reporting. Causal lift can be lower than reported conversions when RunCo reaches users already near purchase: they had searched for the shoe, visited RunCo’s site, or received another campaign.
Measurement sources can include the ad platform, advertiser backend, browser tag, server-side conversion endpoint, mobile measurement partner (MMP, a third-party app attribution provider), offline upload, customer-list match, third-party verifier, or clean-room workflow (privacy-constrained matching between advertiser and platform data). Reports can combine several of those sources, so the first debugging question is which party produced the number.
Debugging Disputed Numbers
When RunCo disputes spend or conversions, the platform has to locate which step in the money loop produced the wrong number. The debugging path follows the boundary that changed the count: event creation, dedupe, serving-time join, spend estimate, matching, attribution, modeling, or reconciliation.
| Boundary that broke | Advertiser-visible result |
|---|---|
| Event creation loses an impression. | Spend undercounts; delivery can look cheaper than it was. |
| Dedupe misses a repeated click or conversion. | Spend, clicks, or conversions inflate; pacing may throttle too early. |
| A late click arrives after the provisional window closes. | Reporting changes later or misses valid spend. |
| A backfill joins yesterday’s event to today’s campaign config. | Spend appears under the wrong bid, targeting, or creative state. |
| Confirmed spend lags in-flight spend during a burst. | Pacing controller treats RunCo as behind and may overspend. |
| Browser tag and server-side endpoint send the same order without a shared dedupe key. | Conversion double-counts. |
| Attribution window changes from seven-day click to one-day click. | Reported conversions move even when delivery and purchases are unchanged. |
| Report mixes observed and modeled conversions without labeling. | Advertiser loses the split between direct matches and modeled estimates. |