Programmatic for a Digital Out-of-Home Screen Network: Sell Through a DOOH SSP, Take a White-Label Stack, or Build Your Own

Programmatic selling means software sells your ad space. Each time a slot comes up, advertisers' buying systems bid on it in an automatic auction. A digital out-of-home (DOOH) network has screens in places like malls, stations, gyms and offices. It can sell them programmatically through a DOOH supply-side platform (SSP), which offers the screens of many networks to buyers. It can also run a vendor's software under its own brand (a white-label stack) or build its own platform. The choice depends on how much of the selling you want to control and who will run the technology every day.

What changes when a screen network sells programmatically?

Some buyers start bidding on single plays through software instead of booking campaigns with your sales team. In a direct sale, that team agrees on dates, screens and a price with an advertiser. Someone then loads the ads into your content management system (CMS), the software that decides what each screen plays and when.

Programmatic bids come from a demand-side platform (DSP), the system advertisers and agencies use to buy ads. Buyer and seller systems usually exchange those bids in OpenRTB, a common message format. IAB Tech Lab, which writes technical standards for digital advertising, maintains it and added support for screens to OpenRTB 2.6 in November 2022.

This article draws on that specification and IAB Tech Lab's implementation notes for it. It also uses the OpenOOH venue taxonomy, a shared list of venue types, and the Media Rating Council (MRC) standards for out-of-home measurement. All sources were opened on 4 November 2026.

Start with your CMS or player, the device or software that runs each screen. A loop is a sequence of content and ads of a set length that plays over and over. If your screens run one, some of its slots must stay open for programmatic. The player has to fetch ads for them and report what played. When no ad arrives, it needs something else to show.

The auction can happen well before the play. IAB Tech Lab's notes explain that most screens connect over mobile networks, which can drop out at busy times. So some screen networks fetch ads in advance. The notes say: “The current industry accepted lead time from ‘bid confirmation’ to ‘display’ can be up to 1 to 2 hours.”

How does one play on a screen become many impressions?

Each bid request, the message that asks DSPs to bid, says how many impressions the play is worth. On a website, an impression is one ad shown to one person. A play on a screen, IAB Tech Lab's notes say, is “viewable by everyone who is in the vicinity of the advert being displayed”.

That number is the impression multiplier, the audience counted for each play. OpenRTB 2.6 defines it as “The quantity of billable events which will be deemed to have occurred if this item is purchased.” In plain words, it is what the buyer pays for.

The multiplier can be below one, as it might be on a quiet screen at night. The notes say “fractional values (e.g. .32 impressions per ad display) are common”. They add that the number may change by the hour or come from “real-time sensor data”.

Prices stay in CPM, the price per thousand impressions. The notes give a worked example, not a market price: if a $2.50 CPM bid wins a play worth 30.3 impressions, the invoice comes to $0.07575. They also warn that multiplying by decimals “can lead to discrepancies when the ‘buy side’ and ‘sell side’ truncate decimal places.” Agree on rounding with each SSP and buyer before the first campaign.

Where does the audience number come from?

The bid request can also say who supplied the number. IAB Tech Lab's AdCOM specification names three sources: a measurement vendor, the publisher (you) or the exchange (the SSP).

Buyers will ask what the number measures. The MRC is a US industry body that audits and accredits media measurement. Its out-of-home standards, in a final version from December 2025, set out a ladder from the traffic at a location to the audience likely to have seen the ad. Each step adds conditions, and the standards note that “Gross Impressions reflect the highest potential audience estimate”.

How do we prove that an ad played?

Proof of play is a log from the screen's player that shows which ad played, on which screen and when. The MRC standards say: “There must be strong evidence of proof-of-play (PoP) to support the reporting of Gross Impressions or Audience estimates”.

For digital screens, the standards accept technology that logs player activity, if it is tested before launch and “periodically monitored”. They also cover the seller's proof that an ad ran, such as play logs. What goes into it, they say, “should be agreed to by the buyer and seller prior to initiation of the ad campaign”.

OpenRTB has a billing notice, the message that tells the buyer an impression can be billed. The win notice, a different message, only says that a bid won. IAB Tech Lab's notes strongly recommend keeping the two apart and sending the billing notice when “the creative has rendered on screen and impression[s] are billable”. The creative is the ad file itself.

What are the three ways to sell our screens programmatically?

• Sell through a DOOH SSP. You connect your CMS or players to the SSP and load your screens and audience numbers. The SSP offers them to the DSPs it works with, runs the auction and pays you what is left after its fee.
• Take a white-label stack. A vendor licenses you its ad server and the software that sells to DSPs. The ad server is the system that picks which ad plays and counts it. The platform carries your brand, and the vendor maintains the code.
• Build your own. Your team, or a firm you hire, builds the ad server, the link to DSPs and the reports. You own the code and every rule in it, and you run it.

You can combine the paths: for example, run your own ad server for direct campaigns and sell spare plays through SSPs.

When is selling through a DOOH SSP enough?

Use an SSP when most of these are true:

• You want to learn whether programmatic buyers will pay for your screens before you spend on technology
• Your CMS or players already work with the SSP, or the SSP will help connect them
• Programmatic will fill the slots your sales team does not sell
• You have no engineers to run an ad platform day and night

The catch is control. Buyers find your screens in the SSP's marketplace next to other networks, and prices and deals work the way its software allows.

When does a white-label stack make sense?

Take one when:

• Agencies should buy from your brand and your sales team, not from a marketplace
• You want your own rules for prices, deals and which ads may play in which venue
• You can staff a team to run campaigns, but not one that writes and runs ad software

The code is rented. New features arrive on the vendor's schedule, and licence fees can grow with your volume. If you leave, you may have to set up screens, deals and buyer accounts again elsewhere.

When is building our own platform worth it?

Building pays off in these cases:

• Programmatic is a large share of your revenue, and fees cost more than paying a team to run your own system
• Your screens need rules the vendors you spoke to cannot support, such as ads that change with train times in a station
• You sell other networks' screens too, so the platform is part of what you sell
• Audience data from your venues must stay in your own systems

On this path, each DSP usually has to agree to connect to your platform and test your bid requests before its buyers can see your screens. Someone has to watch the system and settle reports with buyers. OpenRTB keeps changing too: IAB Tech Lab has released seven updates to version 2.6 since it added screens. If nobody on your team will own this work, start with an SSP or a white-label stack.

What work stays with our team on every path?

Your team decides and maintains these:

• Screen and venue data: an ID, location, size, hours and venue type for each screen. A venue taxonomy is a shared list of venue types, so that a gym means the same to every buyer. OpenRTB 2.6 assumes the OpenOOH Venue Taxonomy unless the request names another. It sorts venues into levels, such as “Retail” and then “Retail / Malls”.
• Audience estimates and their source: which step of the MRC ladder your number measures, who measured it and how often it changes
• Creative approval and content rules: IAB Tech Lab's notes say ads on large commercial networks “need to be manually pre-approved”, in some cases by venue landlords too. They warn that one bad ad shown “to 1000’s of people in a public place” puts the network's “contract/permission to serve ads” at risk. Keep a written list of what each venue owner allows.
• Play logs and reconciliation: keep your own proof-of-play logs even when an SSP collects them. Screens go offline and decimals round differently, so someone has to compare your logs with each buyer's report every month.
• Floor prices and direct deals: a floor price is the lowest bid you accept, set as a CPM like the bids themselves. A private marketplace deal is an auction open only to buyers you invite. The bid request marks it with a code called a deal ID. Decide which wins when a direct campaign and a programmatic bid want the same slot.

What should we check before signing with an SSP or a white-label vendor?

• Who owns the screen list, venue data and audience numbers we load, and can we export them at any time?
• Whose audience number goes into each bid request, and how is its source marked?
• What share of each sale do you keep, and do our reports show both the gross and the net amount?
• Which DSPs are connected today, and which of them bought DOOH plays in the last three months?
• Can we keep selling direct campaigns and use other SSPs at the same time?
• Who approves each creative, and can we block an ad for one venue only?
• What happens when we leave: how long is the notice period, and which deals, accounts, logs and reports can we take with us?

Who owns the code, the data and the buyer relationships?

An SSP owns its platform and its contracts with DSPs. Your screen and audience data should stay yours, and the contract should say so. Deals set up inside an SSP may not move with you.

A white-label vendor owns the code, while the brand is yours. Check whether buyer accounts and DSP connections are in your company's name or the vendor's.

If you build your own, you can own the source code and hire any team to change it. Ask the builder to name in the contract any parts it keeps, and the licence that lets you use them.

Whatever you choose, put in writing that your data may be used only to sell your screens, and that logs and reports can be exported at any time.

What should we ask a firm that would build our screen platform?

• How will the platform connect to our CMS and players, and what plays when no ad arrives in time?
• How will each bid request carry the screen's location, venue type, audience per play and the source of that number?
• How will proof of play be recorded and matched against buyers' reports?
• Will buyers send creatives for approval through IAB Tech Lab's Ad Management API, a standard its notes call “strongly recommended” for DOOH?
• How will floor prices and private marketplace deals be set for each screen, venue and hour?
• Which DSPs will you connect first, and who runs the talks with them?
• Can you show this working in a system that runs today?

Where does amBrain fit?

amBrain publishes this blog. Three of its own statements describe systems a network builds on the third path. One reads: “amBrain builds supply-side platforms (SSP) for publishers.” Another: “amBrain builds ad servers: targeting, frequency capping and reporting.” A third: “amBrain builds event analytics pipelines for ad tech: collection, processing and reporting of impression and click events.” A fourth, on the buying side, reads: “RTBBidder, a demand-side platform we built for a client.”

amBrain has been building software since 2019. On how it works with clients, it says: “Three formats: full delivery, a dedicated team, or engineers embedded in your team.” Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.” Ask for the list of those components by name before you sign.

This article is not a case study. Apart from naming RTBBidder, it describes no client work. It does not say that amBrain has built a DOOH platform, connected a screen network to an SSP or measured audiences for any client. Nor does it give amBrain prices or timelines. Quotes from IAB Tech Lab, the OpenOOH taxonomy and the MRC come from their published documents, and the article claims no relationship between amBrain and any of them.

It is not legal advice either. Have a lawyer read SSP, vendor and venue contracts before you sign. If your audience counts come from cameras or other sensors, ask how privacy law applies to them. If amBrain is on your shortlist, ask it the same questions as any other firm.