Proof of Play: How Advertisers Know Their Ad Actually Ran

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.

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.

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.

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.

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.