One Impression, Two Ledgers: From Campaign Budget to Publisher Payment

Priya opens a weekend-trekking article on Wanderlust Weekly. A moment later, an Urban Hiker boot advertisement appears beside the story. Somewhere, a campaign dashboard adds an impression. Somewhere else, the publisher’s estimated earnings increase.

It is tempting to treat those updates as the end of the transaction. But Urban Hiker has not necessarily paid an invoice yet. Wanderlust Weekly has not necessarily received the money. Several companies may already have received information about the opportunity, including companies whose ads Priya never saw.

Our introduction to AdTech set up two ledgers: one for money and one for data. Here we follow both through a complete transaction. We will connect the advertiser’s instructions to the publisher’s payment, stopping at the places where an auction result becomes a delivery record, a delivery record becomes a charge, and a charge becomes cash.

The running example uses a web-display campaign and one simplified supply path. Later, we expand Priya’s impression into a small accounting batch so the rupee amounts are easier to follow. Every price, fee, count, and payment schedule in that example is hypothetical, not an industry benchmark.

---

1. The Campaign Exists Before the Bid

Urban Hiker wants to sell its new waterproof boots. Its marketing team allocates ₹1,00,000 over ten days and selects sales as the campaign objective. That objective guides optimization; it does not automatically mean the company pays only when someone buys boots. In our example, the underlying media is bought on an impression basis.

Inside the demand-side platform, the brief becomes a collection of operating rules:

Configuration	Our example	What it controls
Campaign	Waterproof boot launch	Business objective and reporting group
Insertion order	Ten-day buying allocation	Shared spending envelope and dates
Line item	Web display on relevant outdoor content	Inventory, targeting, and bidding settings
Creative	Approved 300 × 250 boot banner	What can actually be delivered
Pacing	Aim to distribute spend over the flight	How quickly the allocation is consumed
Frequency policy	Limit repeated exposure where supported	Whether another impression is eligible

The names and hierarchy vary by platform. The underlying idea is stable: an auction decision sits inside a campaign’s constraints. A model can estimate that an impression is valuable while the campaign remains ineligible because its creative is unapproved, its schedule has ended, or its spending allocation is exhausted.

Pacing controls spending rate. Dividing ₹1,00,000 by ten gives an initial ₹10,000 daily reference, not an instruction to spend exactly that amount regardless of opportunities. To give that reference a physical scale: at the all-in price our example settles on later (₹100 per thousand billable impressions, with the DSP and verification charges included), the allocation buys about one million impressions, so the daily reference is roughly 100,000 impressions, a little over one per second. Which number the pacer counts matters too. In our example it paces against the advertiser’s all-in spend; a pacer that counted media cost alone would let through about 15% more impressions on the same allocation, which is the “gross or net of fees?” question our introduction flagged. Traffic and prices vary, and distributed spending reports arrive with delay. Google’s DV360 pacing documentation describes both pacing choices and the possibility of overspending while accounting catches up.

Frequency capping needs a recognition mechanism with a defined scope. A browser, account, or modeled identity is not an infallible count of one human across every device. DV360, for example, documents the use of available identifiers and modeling in its frequency controls.

When Priya’s opportunity arrives, the DSP therefore has two jobs: determine whether the campaign may participate, then decide what to bid. Our campaign lifecycle article develops the setup and operating controls, while our ML article explains the prediction machinery. The point here is where that machinery belongs.

The money ledger begins with an authorization to spend. The data ledger begins earlier than ad delivery too: campaign definitions, creatives, targeting choices, and any permitted audience inputs already exist.

---

2. One Transaction Runs on Four Clocks

There is no single useful stopwatch for the complete journey. Campaign preparation might take days. Auction decisions operate within a short timeout. Creative delivery and measurement depend on subsequent browser and server activity. Reporting and settlement run on their own schedules.

At page load, Wanderlust Weekly creates an ad opportunity. Its selling systems collect the permitted context and seek demand. Urban Hiker’s DSP evaluates a request and returns a bid. The publisher’s decision process selects an ad, and Priya’s browser attempts to load it.

Those are functional roles, not a requirement for five independently owned companies. An SSP can operate an exchange. Header bidding can create competing paths before the publisher ad server makes its decision. Our ad-server article explains those arrangements; the example follows one representative path to keep the transaction readable.

For the financial example, assume a first-price auction with a winning ₹85 CPM media bid. First-price means the winner pays what it bid, so ₹85 is both the bid and the clearing price; in a second-price exchange it would be the bid, and the charge would be set by the runner-up (our ad-server article covers the auction formats). CPM is a quote per thousand impressions, so the corresponding media amount for one billable impression is ₹0.085. That is neither the campaign’s ₹1,00,000 budget nor necessarily its eventual total charge after fees.

No bank transfer needs to occur in the auction’s critical path. Systems can record provisional obligations and settle them later, often in aggregated invoices. Our example follows that arrangement; actual prepayment, credit, and settlement terms vary.

---

3. The Data Branches Before the Money Does

Priya is reading about trekking. A buying decision may need the slot dimensions, page context, device characteristics, and permitted location or identity signals. The publisher’s selling system packages information into a request and routes it to potential buyers.

The exact payload matters. A request might contain a domain and content category, or a more revealing page URL. An identifier might be present, pseudonymous, scoped to a particular partner, or absent. Priya’s IP address is a case worth being precise about. Recipients of a server-to-server request see the server’s network address, not hers; but the request format has a standard field for the device’s address (device.ip in OpenRTB), and sellers routinely populate it. Whether it is sent in full, truncated (dropping the last octet is a common compromise), or omitted is a policy choice on the selling side, not a protocol constraint, and a creative served from a buyer’s own servers can observe the address directly in a separate browser interaction. We should distinguish those paths rather than assuming every recipient sees everything.

Figure 1. One ad. Several data recipients. One eventual ad can involve several request recipients, and each receives its permitted fields before the auction outcome is known. A losing bid does not reverse the earlier disclosure.

In this example, three DSPs receive requests. One returns the winning Urban Hiker bid, one loses, and one declines to bid. All three have already received whatever information their individual requests contained. The amount shared need not be identical across partners.

This is a structural difference between the ledgers. Buying the impression selects a financial outcome; distributing the opportunity can already have created multiple data copies. Whether recipients retain those copies, for what purpose, and for how long requires separate controls.

Privacy and consent signals accompany some of these exchanges. The IAB Tech Lab’s Global Privacy Protocol provides a mechanism for transmitting supported privacy, consent, and consumer-choice signals. It does not make a request self-enforcing. As an engineering principle, receivers still need to interpret applicable signals and enforce the resulting restrictions on collection, use, and onward sharing. Nor should we assume every jurisdiction uses the same framework.

For our transaction, the practical design questions are concrete: does the buyer need the full page URL, could a content category suffice, does the IP address need all four octets, and can bidding proceed without a persistent identifier? If a required privacy signal is unavailable, the system needs a defined restricted mode or a decision not to participate. An absent signal should not silently become unrestricted permission.

---

4. A Win Is Only One Event

Urban Hiker wins the exchange auction. The browser still has work to do. The selected creative can fail to load, arrive after Priya leaves, or render below the visible area. An exchange win can also precede a further publisher-side selection.

These distinctions are explicit in the protocol. In OpenRTB 2.6, nurl carries a win notification, which does not establish that an ad was delivered, viewed, or billable. burl carries a billing notification when a winning bid becomes billable under the exchange’s policy. The implementation guidance further separates auction notifications from tracked and billable ad events.

Figure 2. Winning is a step, not proof of delivery. This example bills on an agreed render event. Viewability and downstream response remain separate measurements; other agreements can define a different billing trigger. A win notice (nurl) is not a billing notice (burl).

It helps to attach a question to each record:

Record	What it helps establish
Auction win (nurl)	Was this bid selected within this auction?
Auction loss (lurl)	Was this bid not selected? The loser learns the outcome; its copy of the request is untouched.
Delivery or render signal	Did the creative reach the specified delivery/counting point?
Viewability result	Did measurable exposure satisfy the chosen viewability standard?
Billing notification (burl)	Did the exchange report its agreed billable condition?
Conversion event	Was a later business outcome reported?

Missing viewability measurement is different from a measured failure to meet the threshold. Neither a billing record nor a viewability result proves that Priya paid attention. Likewise, a later purchase does not itself prove the ad caused it. Our attribution and incrementality article follows that last distinction.

For the remainder of this example, we stipulate an agreement that bills a valid, recorded render event. That choice makes the arithmetic precise without claiming it is universal. The delivery system records the event, and the financial system can accrue the corresponding obligation. A subsequent quality adjustment can still change the payable amount.

---

5. Following ₹1,000 of Advertiser Spend

Fractions of a rupee become easier to inspect in a batch. Expand our example to 10,000 provisionally billable impressions, each bought at the same ₹85 CPM media price. Priya’s impression is one of them. Real auction prices vary; holding the price constant lets us isolate the accounting.

The media amount is 10,000 ÷ 1,000 × ₹85 = ₹850. Assume the buyer’s statement also allocates ₹100 to the DSP and ₹50 to verification, giving ₹1,000 total advertiser spend before later adjustments. The ₹50 covers delivery/quality verification, not a purchased audience dataset.

On the selling side, assume the SSP/exchange keeps 20% of its ₹850 media receipts, or ₹170, leaving ₹680 provisionally payable to Wanderlust Weekly. We combine SSP and exchange functions in one recipient here.

Figure 3. Where the ₹1,000 goes. A hypothetical allocation of ₹1,000, excluding tax, agency charges, and later adjustments. The SSP fee is 20% of ₹850, not 20% of ₹1,000; the publisher’s 68% share is of the full ₹1,000.

Component	Batch amount	Basis in this example
Advertiser spend	₹1,000	Media plus the two buyer-side charges
DSP fee	₹100	Agreed batch charge, equivalent to ₹10 per thousand
Verification charge	₹50	Agreed batch charge, equivalent to ₹5 per thousand
Media receipts	₹850	10,000 impressions at ₹85 CPM
SSP/exchange fee	₹170	20% of media receipts
Publisher revenue	₹680	Media receipts less SSP/exchange fee

The ₹850 media line is an intermediate subtotal, not another fee. The recipients’ amounts add to the advertiser’s spend: ₹100 + ₹50 + ₹170 + ₹680 = ₹1,000.

On our common 10,000-impression denominator, the advertiser’s all-in effective CPM (total cost per thousand impressions, whatever the pricing model) is ₹100, while the publisher’s impression RPM (revenue per thousand impressions served) is ₹68. Our introduction’s metrics section defines both and, for RPM, distinguishes the per-impression, per-page, and per-session versions, which differ exactly because their denominators do. The ₹85 CPM auction price sits between them. Per billable impression, the advertiser allocates ₹0.10 and the publisher earns ₹0.068 before adjustments.

This is why a percentage needs its denominator. The SSP’s 20% fee removes ₹170 here. Applying 20% to advertiser gross spend would remove ₹200 and describe a different agreement. Actual fee schedules can use media cost, gross spend, impression volume, minimum charges, or other bases. Agency costs, taxes, currency conversion, and additional intermediaries would require additional lines; an actual Indian invoice, for instance, adds 18% GST to each service line, which is one reason the boundary around the ₹1,000 has to be drawn explicitly before any percentage is quoted.

The waterfall shows allocation, not a literal sequence of four bank transfers. Commercial parties can invoice separately, net amounts, or combine services. It is useful precisely because it forces us to name the boundary around the ₹1,000 and account for every rupee within it.

---

6. Event Logs Have to Become Agreed Accounts

The auction and delivery systems produce evidence. Reconciliation determines how that evidence maps to the payable amount.

Suppose a raw export contains 10,300 render-event rows. Investigation finds 200 retry copies and 100 events outside the agreed reporting interval. After removing those, we have the 10,000 provisionally billable impressions used above. Those 300 excluded rows were never additional purchased impressions in our waterfall.

Later, the quality process confirms 100 of the remaining impressions as invalid traffic. Under our stipulated agreement, those media charges are reversed. The final eligible count is 9,900, and the media credit is 100 ÷ 1,000 × ₹85 = ₹8.50.

Figure 4. Event rows become billable impressions. Two kinds of removal. Exclusion before billing changes the count; reversal after billing changes the payable amount.

Assume the DSP and verification charges remain payable, while the SSP and publisher reverse their respective shares of the invalid media amount. The logic of that split: the fees paid for work that was performed on the event whether or not the impression was later reclassified, whereas the media charge is the thing being un-bought. It is an example contract rule, not a default across the industry:

Recipient or balance	Before adjustment	Reversal	Final amount
DSP	₹100	₹0	₹100
Verification provider	₹50	₹0	₹50
SSP/exchange	₹170	₹1.70	₹168.30
Publisher	₹680	₹6.80	₹673.20
Advertiser total	₹1,000	₹8.50	₹991.50

The example separates fees, which pay for services, from adjustments, which correct the amount recognized under the agreement. A different refund rule would change the allocation, and one common alternative shows how much: many SSP agreements pass invalid-traffic credits through to the publisher in full, in which case the SSP keeps its ₹170 and the publisher’s line falls by the whole ₹8.50, to ₹671.50. Note also who decided the credit was owed. The verification provider, the party paid ₹50 in this batch, is often the source of the invalid-traffic determination that sets what the other parties refund; a quality process needs its own auditability for exactly that reason. The publisher’s bank receipt follows the final payable balance and payment terms; it should not be inferred from the initial dashboard estimate.

Real discrepancies also arise when systems count at different points, use different reporting cutoffs, or miss network events. Google’s Ad Manager troubleshooting guidance recommends aligning date ranges, time zones, and included inventory, and identifies latency, counting differences, and delivery failures among the causes. Disagreement alone does not establish fraud.

To investigate our batch, we would want a compact evidence trail:

auction_id / impression_id    identify the opportunity within its source
bid_id / creative_id          identify the selected response and asset
event_id                     distinguish a new event from a retry
event_type / counting_rule    state what the row actually counts
event_time / received_time   separate occurrence from ingestion
amount / currency / basis    label media cost, fee, or adjustment
quality_status / revision    preserve why the payable amount changed

This is a conceptual record, not an OpenRTB payload. IDs are scoped to systems; cross-party reconciliation needs agreed mappings or shared references. An auction can contain multiple impression opportunities (an OpenRTB bid request carries an array of impression objects, one per slot on the page), so an auction ID alone is not always a sufficient join key. A missing buyer log should prompt evidence gathering under the agreement, not an automatic deletion of a seller’s charge.

For our operators, the first debugging move is to align definitions and intervals, then deduplicate and join the evidence. Comparing two dashboard totals before doing that confuses accounting differences with delivery failures.

---

7. Payment Closes One Obligation, Not Every Data Copy

Wanderlust Weekly eventually receives the ₹673.20 attributable to our adjusted batch. The financial story has reached settlement under our assumptions. The data story has several possible continuations.

Figure 5. Money settles. Data needs its own lifecycle. Settlement does not automatically delete operational data. Each retained dataset needs a purpose, access boundary, and lifecycle of its own.

For the system we are designing, we should distinguish billing evidence from detailed browsing context. A dispute may require transaction references, amounts, timestamps, and adjustment reasons. That does not establish a need to retain a full page URL or a reusable user identifier alongside every financial record.

Dataset	Purpose to assess	Control to make explicit
Raw request and delivery logs	Diagnose a specific operational problem	Restricted access, short justified retention
Financial evidence	Reconcile charges and adjustments	Separate storage, only necessary fields
Aggregated campaign reports	Compare delivery and cost	Grouping rules and disclosure controls
Permitted modeling inputs	Improve an authorized prediction task	Purpose limits, feature minimization, expiry

These are design recommendations, not claims that every platform implements them. A retention period should follow the dataset’s purpose and applicable obligations; there is no universal number of days that makes all four rows appropriate. Aggregation also needs scrutiny: tiny groups or persistent join keys can preserve linkability.

The privacy and power questions now have specific owners. Publishers can constrain partners and exposed context. Buyers can minimize request logging and separate billing records from identity-bearing features. Verification services need bounded collection purposes. If a recipient keeps stale or inaccurate data, the consequences can extend beyond a disputed invoice into future targeting or classification.

Priya can influence some collection through available consent choices and browser controls. She cannot inspect every server-side copy from the page itself, or unilaterally enforce each recipient’s retention policy. Partner governance, auditable controls, and effective enforcement carry responsibilities that individual settings cannot fulfill. Our identity article explains why removing one identifier does not remove every route to recognition.

The two ledgers, written out

Our introduction wrote the two ledgers as tables for a ₹5,000 campaign. Here they are for Priya’s impression, one of the 9,900 that stayed valid, using the numbers this post has accumulated. First the money:

Entry	Amount	From, to	Status for Priya’s impression	Had it been one of the 100 invalid
Media clearing price	₹0.085	Advertiser to SSP/exchange	Accrued at the recorded render, paid on terms	Reversed in full
DSP fee	₹0.010	Advertiser to DSP	Payable, service performed	Still payable
Verification charge	₹0.005	Advertiser to verifier	Payable, service performed	Still payable
SSP/exchange fee	₹0.017	Retained from the media amount	Retained	Reversed (₹0.017 of the ₹0.085)
Publisher revenue	₹0.068	SSP/exchange to Wanderlust Weekly	Payable on the agreed schedule	Reversed (₹0.068 of the ₹0.085)
Advertiser total	₹0.100			₹0.015

Then the data, for the same impression:

Stage	What is created	Who holds a copy	Changed by losing the auction?	Changed by settlement?
Bid request	Slot, page context, device signals, privacy signals, identifiers where permitted	The SSP/exchange and all three DSPs	No; the loss notice reports an outcome, it does not recall the request	No, unless a retention policy expires it
Bid and notices	Bid price, creative ID, win or loss notice, clearing price where disclosed	The exchange and each bidding DSP	No	No
Render and billing evidence	Event IDs, timestamps, amounts, quality status	Publisher, SSP/exchange, DSP, verifier	Not created for a loser	Kept as financial evidence, ideally without page or identity fields
Viewability measurement	A pass, fail, or unmeasurable result	Verifier and buyer	Not created for a loser	Purpose-limited retention
Later conversion, if any	Order signal joined to the impression	Advertiser and its measurement partners	Not created	Governed by its own attribution and retention rules

Read side by side, the tables make the asymmetry plain. Every line of the money ledger has a counterparty, a status, and a rule that changes it. The data ledger’s rows persist regardless of the auction outcome, and most of them regardless of settlement, unless something other than the transaction itself acts on them.

An exercise brings the two ledgers together: suppose Priya’s creative fails to render after three DSPs receive the request. Under our example’s billing rule, that opportunity earns no media charge, and every entry in the money ledger reads zero. The first two rows of the data ledger are unchanged. We need separate answers for the financial outcome and the fate of those records.

We can now trace the campaign from an instruction to spend, through a distributed decision, into delivery evidence and an adjusted payment. This post treated the selling side as one box that “packages and routes the opportunity”. In the next article we open that box: how publisher and advertiser ad servers decide which ad is served, how direct deals sit alongside programmatic auctions, and where header bidding changes the route. Our later anatomy of OpenRTB inspects the messages themselves: a bid request, its response, and the notifications that connect an auction to the ledgers.

---

Resources

• Google, Set budgets and control your pacing, Display & Video 360 Help - pacing options and the overspend caveat behind section 1.
• Google, Manage frequency with frequency caps, Display & Video 360 Help - identifiers and modeling used to count exposures.
• IAB Tech Lab, OpenRTB 2.6 specification - the nurl, burl, lurl, and device.ip definitions used in sections 3 and 4.
• IAB Tech Lab, OpenRTB implementation guidance - auction notifications versus tracked and billable events.
• IAB Tech Lab, Global Privacy Protocol (GPP) - the consent-signal mechanism discussed in section 3.
• Google, Investigate report discrepancies, Ad Manager Help - the reconciliation checklist behind section 6.