Proof of Play: What Advertisers Expect in a DOOH Report

Imagine paying for 5,000 plays of your advert on screens you will never visit, in cities you may never enter. What you're really buying is a claim — "your ad ran" — and the entire DOOH advertising economy rests on whether that claim can be trusted. Proof of play is the industry's answer: a record, for every single playback, of what played, on which screen, at what time, for how long. It's the receipt of the screen business. And like receipts, the interesting question isn't whether one exists — it's whether it would survive an audit.

What a proof-of-play record contains

At minimum, one row per playback: the media item (which advert), the device (which screen, and therefore which location), a timestamp, and the duration played. Good systems add context — the campaign the play belonged to, whether the file played to completion, and the player version. Multiply by a real network and the scale gets serious fast: one screen looping a 10-slot reel for 12 hours generates thousands of rows a day. That's why proof of play is a data-engineering feature, not a checkbox — the platform has to collect, store, and aggregate these rows reliably from hundreds of devices on imperfect networks.

The fields agencies actually expect

"One row per play" is the principle; buyers work to a specification. The most concrete public one is the Outsmart Playout Reporting Standard v2.0, used by the UK out-of-home industry's shared Playout data warehouse. It is worth building to even if you never sell in the UK, because these are the fields agencies are already used to receiving. It requires reporting at what it calls the Spot Level of granularity — the individual play on the individual screen, never a monthly total — and makes the following mandatory for every playout event.

• ›StartTime and EndTime — the start and end of the spot playout event.
• ›FrameId — the media owner's own ID for the frame, or screen, that displayed it.
• ›CreativeId — the media owner's own ID for the creative that was shown.
• ›AccountId, OrderId and LineId — which buyer, which order, and which line of that order the plays belong to.
• ›CampaignId, CampaignName and PoNumber — optional, and the ones buyers quietly appreciate most, because they let an agency reconcile your report against their booking without phoning you.

Two details in that standard trip people up. Every time field must be ISO-8601 in Coordinated Universal Time, not local time — a report in IST that does not say so is a report an analyst cannot line up against anyone else's. And impressions are deliberately not on the mandatory list, because plays and impressions are different things that get reported separately. More on that below.

Beyond the minimum: what buyers ask for once they've been burned

The mandatory fields prove a spot started and ended. Buyers who have been short-changed before ask for four more things, and a report that anticipates them reads as competent rather than defensive.

• ›Completion status. A play that died at second 6 of a 10-second slot because the device rebooted is not a delivered play. Report the duration actually rendered, not the duration scheduled, and flag partials.
• ›Screen state at the time of play. The IAB's DOOH Measurement Guide defines a gross impression as exposure while the display is functional. A play logged by a player wired to a switched-off panel is worth nothing, so log display health alongside plays.
• ›Booked against delivered, by screen and by daypart. Agencies reconcile to the order. Give them the shortfall and where it happened before they calculate it themselves.
• ›Downtime and gaps, with reasons. If a screen was dark for four hours on a Tuesday, say so first. The UK Playout system separates processing errors, which are corrected and resubmitted within seven days, from operational errors such as inoperative screens, which stay a matter between buyer and seller — so your advertiser terms should already say how an operational gap is made good.

There is also a short list of things that will get a whole file distrusted, and they are exactly the validation checks the UK Playout warehouse runs on every record submitted to it: a playout must not be duplicated or overlapping, and it cannot carry a future date. If a buyer's analyst finds two plays on one screen with overlapping timestamps, nothing else in your report gets the benefit of the doubt.

Plays are not impressions — report both, separately

A play is one airing of one creative on one screen. An impression is one person's opportunity to see it. DOOH is a one-to-many medium, so a single play can deliver many impressions, and the bridge between the two numbers is the impression multiplier: the impressions delivered by a single ad play, appropriate to the hour of the day, the day of the week, and the specific screen. The IAB guide is clear that it should be derived from real-world audience data — foot traffic, dwell time, presence within the exposure zone — and not from optimism.

• ›The play count, straight from the log.
• ›The multiplier used, per screen and ideally per hour.
• ›How that multiplier was derived — footfall count, sensor, third-party research — and the date it was last updated.
• ›Impressions as plays multiplied by the multiplier, stating which definition you mean: gross impressions, Opportunity-to-See, Likelihood-to-See, and audience impressions are not interchangeable.

Multipliers are now audited, not assumed. In August 2025 Rapport, Vistar Media and UniLED rolled out independent verification across all US programmatic DOOH campaigns, including checking DSP impression multipliers against independent industry standards. If you cannot yet justify a multiplier per screen, report the plays and mark the impression estimate provisional. A buyer will accept a conservative number with a stated method. Nobody accepts a large number with no method.

Why unverified logs are worthless to a media buyer

Here's the uncomfortable part. A playback log is produced by the same party that gets paid for the plays. If the screen operator's server simply writes "played 5,000 times" into its own database, the advertiser is trusting the seller's spreadsheet — a number the seller could inflate with one UPDATE statement, with no way for anyone to tell. Media buyers know this, which is why unverifiable networks get paid less, audited harder, or skipped entirely. Agencies increasingly demand machine-readable proof-of-play exports as a condition of the buy, and disputes ("the screen was dark that week") turn entirely on whose records can be believed. A log that can't demonstrate its own integrity isn't evidence; it's a press release.

An unverifiable playback log isn't evidence — it's the seller marking their own homework.

Server-side logs vs device-signed logs

There are two fundamentally different places a play can be recorded. Server-side logging means the cloud platform writes a row when it believes the screen played something — based on what it scheduled, or on an unauthenticated ping. It's better than nothing, but it records intent, not fact: if the device was off, crashed, or showing an HDMI error, the schedule still "ran" on paper. Device-side logging means the player itself records each playback as it happens and reports it upstream — the record originates at the screen, where the truth is. The final step is device-signed logging: the device doesn't just report the play, it cryptographically signs the record, so that nobody — including the platform operator — can fabricate or alter rows afterwards without detection.

HMAC signing, explained without the maths

The standard tool is an HMAC — a keyed cryptographic stamp. Each device holds a secret key, known only to that device and the platform. For every playback row, the device feeds the row's contents (media, screen, timestamp, duration) plus its secret key through a one-way function — HMAC-SHA256 — producing a short signature that gets stored alongside the row. Two properties make this powerful. First, the signature is unforgeable: without the device's key, you cannot produce a valid signature for an invented row. Second, it's tamper-evident: change any field of a signed row — nudge a timestamp, swap an ad ID — and the signature no longer matches. An auditor can later recompute the signature for any row and instantly tell whether it's genuine and untouched. In effect, every play ships with a seal that only that screen, at that moment, could have applied.

Audits and CSV exports in practice

Proof of play is consumed in two ways. Operationally, dashboards aggregate it: plays per campaign per screen per day, completion rates, gaps that reveal a screen was down. Contractually, it's exported — almost always as CSV, because that's what agencies, billing teams, and auditors actually ingest. A typical month-end flow: the operator exports the campaign's playback rows, the buyer (or a third-party auditor) spot-checks them — totals against the contract, timestamps against the booked dayparts, and, on a signed system, signature verification on sampled rows. With signed logs the audit is arithmetic; with unsigned logs it's a negotiation. If you operate screens and ever intend to carry paid campaigns, exportable playback logs are the difference between invoicing with evidence and invoicing with vibes.

The delivery habits that get you renewed

The contents of the report are half of it. The other half is how and when it arrives, and this is the half that costs nothing to fix.

• ›Send it unasked, within one business day of the campaign ending. The advertiser should never have to chase you for the receipt.
• ›Send interim reports on long campaigns — weekly for anything over four weeks. A gap found in week one is a make-good; the same gap found in week eight is a refund conversation.
• ›Lead with a summary a non-technical buyer can read: plays booked, plays delivered, the percentage, estimated impressions, and any screen that had downtime. Put the spot-level data in an attached CSV or JSON behind it.
• ›Keep the raw logs for at least the campaign term plus your dispute window, and write that retention period into your advertiser terms.
• ›Print the buyer's own references on the report. It is the difference between an analyst ticking a box and an analyst emailing you.

The one-page checklist

Per play: screen ID, venue, creative ID, campaign and order and line ID, start time in UTC, end time, duration actually rendered, completion status, display state, signature. Per campaign: booked against delivered by screen and daypart, gaps with reasons, the impression multiplier per screen with its method and date, impressions with the definition stated, a readable summary, the raw data attached, the buyer's references printed, and the retention period spelled out.

Produced by the player, signed per record, append-only, no duplicates, no overlaps, no future timestamps, delivered before they ask.

How nextdooh does it

nextdooh implements the strict version of all this. Every playback row is recorded on the device, at the moment of playback, and signed there with HMAC-SHA256 using that device's own key — before it's ever reported to the server. The signed rows flow into per-screen, per-campaign reporting and export as CSV for billing and audits, and because the signature was applied on the device, a verifier can prove each play really happened on that physical screen at that time — the platform itself couldn't quietly invent or edit a row. Among signage platforms at SMB prices this is genuinely rare, and it matters most to exactly the people reading this far: operators who want to sell loop time to local advertisers, and resellers building screen networks where, sooner or later, somebody's media budget will demand receipts.

When you need none of this

A single screen in your own shop running your own promotions needs no proof of play at all. Two or three screens selling a slot to the business next door need a monthly one-page summary and nothing more. Everything above starts paying for itself the moment an agency, a brand, or an SSP is the buyer — because those three check, and the first time they check is not the moment to start building the report.

Common questions

Is proof of play legally required? It's contractually required, which in practice is stronger: most paid DOOH campaigns specify playback reporting as a billing condition, and many agency contracts require auditable logs explicitly.

Does proof of play mean someone watched the ad? No — it proves the ad played on a working screen at a time and place. Audience measurement (footfall, impressions) is a separate layer that's only meaningful on top of trustworthy playback data.

Do I need proof of play if I only show my own content? It's not contractual, but it's still how you verify your own promos ran as scheduled — and it keeps the door open: many operators start selling loop time to neighbouring businesses precisely because they can prove delivery.

What's the difference between proof of play and proof of display? Largely interchangeable terms; some vendors use "proof of display" for screenshot-based spot checks and "proof of play" for the full per-playback log. The per-playback log is what auditors want.

What fields are mandatory in a proof-of-play record? Working to the Outsmart standard: start time, end time, the screen ID, the creative ID, and the account, order and line IDs, with every timestamp in ISO-8601 UTC. Buyers commonly want duration rendered, completion status and screen health on top of that.

How do agencies actually check the report? They reconcile plays against the booking, hunt for duplicate or overlapping timestamps and future-dated rows, compare delivery by screen and by daypart, and increasingly hand the whole thing to a third-party verification service that also checks your impression multipliers against independent standards.

How soon should a proof-of-play report go out? Within one business day of the campaign ending, unprompted, with weekly interim reports on anything running longer than a month.

Can't a dishonest operator just fake the device too? Signing raises the cost of fraud from "edit a database" to "compromise physical devices and their keys" — a different class of attack entirely, and one that gap analysis catches: fabricated rows must also form plausible, gap-free timelines across months. No system makes fraud impossible; signed logs make it impractical and detectable, which is what audits actually require.

If verifiable delivery is on your roadmap — selling ad slots, running a reseller network, or just wanting receipts for your own campaigns — nextdooh records and HMAC-signs every play on the device from day one, on the same plans that run your menus and promos. Start the free trial, run a loop for a week, and export the CSV: the receipts are more convincing than any article about them.