Run it yourself
Programmatic on your terms: only the demand partners you enable can buy, on the faces and at the floors your price list sets, sold by a platform that buys no advertising itself.
ExploreCS Context · Scenario
Prove every play
Your count and the buyer's, built from the same confirmed plays
The buyer is told what happened to every opportunity, so nobody compares two totals at month-end. Where your screens send photographs, the buyer can see its ad on the screen. And a month you closed still shows the plays and the money you billed.
The context
Your content management system logs what played, and the buyer’s platform logs what it bought. When each side keeps its own count, the totals differ, and month-end turns into a hunt for missing plays before anyone gets paid. A spreadsheet sent by email does not end the hunt, because the buyer cannot check it.
01/03The buyer counts the plays you count
“Our numbers and the partner's numbers never quite agree, and every mismatch costs us a little more trust.”
The buyer counts the same plays you do
The buyer is told what happened to every opportunity: played, or not shown. A play counts only once your content management system confirms it. So the buyer's figures are built from the same plays as yours.
How it works, from the documentation
A play becomes a countable fact in three steps.
- CityScreen Context answers an ad request from the content management system with a winning advertisement, and records that decision.
- The screen plays the advertisement.
- The content management system reports the playback back, and CityScreen Context matches that report to the ad request it answered earlier.
Only the third step turns a decision into a fact. Until the playback is confirmed, the decision is an intention — it appears nowhere in statistics, produces no financial transaction, and is not reported to the demand partner as delivered.
Ad-play counting model (one record per playback)This matters for reconciliation. The platform notifies the outcome of each opportunity to the demand partner, delivered or not shown, and retries the notice, up to a retry limit, until the partner acknowledges it. A written-off play is therefore reported to the buyer as not shown.
Confirmation-window write-off for late plays0203
02 “When an advertiser asks whether it really played, the answer is a photograph.” →A photograph when the buyer asks if it really played
“When an advertiser asks whether it really played, the answer is a photograph.”
Where the screen's CMS sends photographs with the plays it reports, the platform keeps a morning, a noon and an evening photograph of each ad on each face. The buyer can fetch the photographs of its own ad through its DSP, on the faces it ran on. A photograph the media owner's team supplied by hand is marked as such, so the buyer can tell it from one that arrived on its own.
How it works, from the documentation
A photo capture is a photograph of the physical screen, taken while a particular advertisement was on it. It is visual evidence that the advertisement appeared on a real installation, in addition to a player’s log of the playback.
A photo capture is the separate, photographic form of evidence. It exists only for the faces whose content management system supplies one, and it does not affect counting or pricing in any way. A campaign with no photo captures at all is counted, reported and billed exactly like one with a full set.
Who can view them:
Demand partners. Over the SSP protocol, a demand partner can fetch the three permanent captures for its own creative across the faces it ran on, the photograph attached to one specific delivered opportunity, and the most recent working copy for a given face. Each permanent capture is returned together with a marker saying whether it was collected automatically or supplied by a person.
Photo captures (proof-of-play photographs)03 “When a partner questions a month we closed long ago, the plays and the money records are still there as they were written.” →A closed month still shows what you billed
“When a partner questions a month we closed long ago, the plays and the money records are still there as they were written.”
In real-time bidding, money is recorded at the moment a play is confirmed. Neither the play nor its money record is edited or deleted afterwards: a correction is added as a new record. Both are kept without a time limit, so a question about an old month is answered from the records written at the time.
How it works, from the documentation
Nothing is recorded when a bid is won. The record is written when the content management system confirms that the advertisement actually played and the ad request is marked successful. An ad play that goes unconfirmed, or is confirmed too late to be matched, produces no financial transaction — see Late and lost plays for the window.
A financial transaction is one record of money arising from delivery.
It is written at the moment delivery is confirmed — for real-time bidding, when the ad play comes back from the content management system and the ad request is marked successful. Every record carries the account it belongs to, the amount, whether it is a credit or a debit, the time, and — where it arose from delivery — a reference back to the ad play that caused it. Records are written in pairs: the same event produces one credit and one matching debit, so both sides of the movement are visible.
The record is append-only. No part of the product edits a financial transaction after it is written, and no part of it deletes one. This matters for two reasons a reader will run into:
- A correction is a new record. Recording a payment adds a further pair of records with negative amounts, which is how a debt comes back down. The original charge stays where it is.
- Closing a billing period produces a document and leaves the records it was built from as they are.
Nothing in the platform drops an ad play on a schedule and nothing edits one after it is written.
Ad-play counting model (one record per playback)Delivery records, financial transactions and the audit log are kept indefinitely.
Append-only financial transactionsCS Context
Request a demo
CS Context documentation
Before you start
What the setup asks of you
What you doWhy, from the documentation
Have your content management system report each play back within the confirmation window, two hours by default, because a play confirmed later is written off
An ad request that is not confirmed within two hours of being answered is written off. After that, the platform accepts no confirmation for it from any source.
Confirmation-window write-off for late playsOn faces with cameras, have your content management system attach the photograph to each play it reports
CityScreen Context does not operate cameras and does not request photographs.
When a synchronization pass reads playback records from a content management system, some of those records carry the address of a photograph taken at that playback. The platform downloads that image and keeps it. Records with no photograph attached pass through untouched.
Whether a face has a camera at all is recorded on the face and advertised to demand partners; see What you can edit. Whether photographs actually arrive is a property of the content management system.
Photo captures (proof-of-play photographs)
CS Context · Features in this scenario4
Other scenarios
CS Context, tuned to your network.
Independent, and in the game
Agency money consolidates toward networks that are easy to buy. CS Context lets an independent network enable, with its own connection details, the demand partners already on the platform, and keeps the delivery evidence in the same system.
Explore
Your rules on your screens
A buyer's creatives reach the street after your own departments sign off, on the faces you choose; only the buyers on your automatic approval list and the partners you sell to through private deals skip the queue.
Explore
Compete for online budgets
The budget rival is the online channel that proves delivery event by event. CS Context gives out-of-home delivery evidence a media buyer can compare with it.
Explore