Programmatic DOOH:
how the ad-serving stack actually works?

Programmatic DOOH buying is quickly becoming the main way digital screens are sold. According to a MAGNA forecast cited by the OAAA, programmatic accounted for 24% of US digital out-of-home spend in 2024 and is expected to reach about 65% by 2029. For screen network owners, that means most future ad revenue will arrive through a DSP bid, not an insertion order. Networks that cannot sell programmatically will watch that growth go to someone else.

The basic chain behind programmatic DOOH is well documented. An advertiser buys in a DSP, the network sells through an SSP, and the CMS and player put the ad on screen. We covered those roles in our guide to DOOH advertising. This article goes one level deeper, into the parts of the ad-serving stack that decide whether a campaign delivers what was sold. 

In programmatic DOOH, the auction is the easy part – the hard part is making a physical screen play, and prove, exactly what was sold. That is the part Fingoweb builds for screen networks, from SSP integrations to player logic, as a digital signage software development company working with integrators and operators.

In this article, you will find:

• why programmatic DOOH ad serving works differently from web programmatic,
• what a DOOH bid request contains, including the impression multiplier,
• how deal types and floor prices shape what a screen earns,
• how a screen decides what to play, and why ads must be cached ahead of time,
• how proof of play and reconciliation work,
• how to connect your network to an SSP, with or without replacing your CMS, and what Fingoweb can build for you.

Why programmatic DOOH ad serving works differently from web programmatic?

Most programmatic technology was designed for browsers and apps. Screens in public spaces break several of its assumptions, and those differences explain almost every design decision further down the stack.

Programmatic DOOH from the ad-serving side

Programmatic DOOH (pDOOH) is the automated buying and selling of ad plays on digital out-of-home screens through DSPs and SSPs, based on bids for specific screens and time slots. From the ad-serving side, it means a screen’s schedule contains slots that are filled by an auction instead of a fixed booking. The network’s software has to request, receive, store, play and report those ads without a human in the loop.

Programmatic digital out of home uses the same protocols as online advertising, including OpenRTB for bidding and VAST for delivering video ads. The logic behind them has to adapt to screens that many people watch at once, often with an unreliable internet connection.

Four differences that shape the stack

The table below shows where programmatic DOOH advertising departs from web programmatic.

	Web programmatic	Programmatic DOOH
Viewers per ad	One user per impression	Many viewers per play, expressed as an impression multiplier
When the ad runs	Milliseconds after the auction	Often minutes or hours after the bid, at a scheduled slot
Where the ad is rendered	In a browser or app the user controls	On a player the network controls, inside a content loop
How delivery is proven	Browser or SDK tracking pixels	Play logs from the player, reconciled with SSP and DSP data

Each row turns into a piece of software on the network side. The multiplier needs audience data, the time gap needs caching and scheduling, the loop needs priority rules, and proof of play needs reliable logs. The rest of this article follows that order.

Inside a programmatic DOOH bid request

When a DSP bids on a screen, it does not see a person. The DOOH DSP sees a description of the screen, the slot and the expected audience, and prices the bid from that. The quality of this description decides how much demand a network attracts.

Screen metadata and the OpenRTB DOOH object

OpenRTB 2.6, maintained by the IAB Tech Lab, added a dedicated DOOH object to the bid request. It describes the placement rather than a user, with fields such as the placement ID and name, the venue type, the venue taxonomy in use, the publisher and keywords (DOOH object reference). Venue types follow the OpenOOH taxonomy, so a DSP can target “train stations” or “gyms” across many networks without knowing each one.

On top of the protocol fields, the DOOH SSP stores what it knows about each screen, and a good CMS feeds it automatically:

• Location – coordinates, city and venue, used for geo-targeting.
• Screen specs – resolution, orientation and supported formats, so buyers only bid with creatives that fit.
• Slot length and loop length – for example a 10-second slot in a 60-second loop.
• Availability – opening hours and the time windows open to programmatic demand.
• Content rules – blocked categories, such as alcohol near schools or competitor brands in a mall.

Example – why metadata matters: A network lists 300 screens with the venue type “retail”. A DSP buyer targeting “grocery stores” never sees them, because “retail” is too broad for that filter. After the network maps each screen to the right OpenOOH venue type, the same inventory starts appearing in grocery campaigns without any change on the screens themselves.

The impression multiplier

Online, one impression means one person saw one ad. On a screen in a station, one play can reach dozens of people. The impression multiplier converts a single play into the number of impressions the buyer pays for. OpenRTB 2.6 carries it in the imp.qty object, with the multiplier value, the type of source and the measurement vendor that provided it.

Example – multiplier in practice: A 15-second play on a platform screen at a commuter station has a multiplier of 38 during the 7–9 am peak and 9 at midday, based on footfall data for that location. A buyer paying a $10 CPM pays $0.38 for one peak play and $0.09 for one midday play. The play is identical. The audience is not.

What data is used in programmatic DOOH? Multipliers usually come from a mix of sources:

• mobile location data showing how many devices pass a screen at a given time,
• traffic and footfall counts from venue operators or transport authorities,
• panel-based audience research,
• camera-based counting that detects people in front of a screen and, in some systems, whether they are looking at it.

We have integrated camera counting for a client network, and it changes the conversation with buyers. A modelled multiplier is an estimate, while a measured one is an observation. Buyers price the second higher.

Deal types – open auction, PMP and programmatic guaranteed

Not every programmatic DOOH sale is an open auction. Most networks sell through three deal types at once, and each one behaves differently in the schedule.

Deal type	Price	Guaranteed delivery	Who the buyer is	Typical use
Open auction	Set by bidding, above the floor	No	Any buyer on connected DSPs	Filling remaining inventory at scale
Private marketplace (PMP)	Negotiated floor, then bidding	No	Invited buyers only	Premium screens for selected agencies
Programmatic guaranteed (PG)	Fixed CPM	Yes, an agreed number of plays or impressions	One named buyer	Campaigns that used to be sold as direct deals

Programmatic guaranteed is the one that surprises network owners most. PG looks like a direct deal with a DSP interface on top, which means the schedule has to reserve space for it in advance, exactly like a booked campaign.

Floor prices and yield

A floor price is the minimum CPM a network accepts for a slot. Set it too low and premium screens sell cheaply. Set it too high and slots go unsold.

Most networks start with one floor per screen group and then split it by daypart once they see bid data. Unsold slots do not have to stay empty. They fall back to house content, direct campaigns or promotions for the venue owner, which is why the fallback logic in the player matters as much as the floor itself.

Example – daypart floors: A network of 50 screens in an airport sets a $14 floor from 6 to 9 am, when business travellers pass through, and a $6 floor in the afternoon. Morning slots still sell out, and afternoon fill rises because more buyers clear the lower floor.

How a screen decides what to play?

Most explanations of programmatic DOOH end at the auction. On the screen side, a second decision happens, which is what the player runs in the next slot. That choice is made by the DOOH ad server logic, whether it lives in the CMS, in the player or in both.

Loops, slots and share of voice

A DOOH screen plays content in a loop, for example six 10-second slots in a 60-second cycle. Share of voice describes how much of that loop one advertiser or one demand source gets. If two of six slots are open to programmatic demand, programmatic has a 33% share of voice on that screen.

The split is a business decision, and it changes over time. A new network may keep most slots for direct sales and house content, then open more of the loop to programmatic as demand grows. The CMS should make that a configuration change rather than a development project.

Priority rules for direct, guaranteed and programmatic demand

When several sources compete for the same slot, the player needs a clear order. A typical priority ladder looks like this:

1. Guaranteed direct campaigns – booked by the network’s own sales team, with a fixed number of plays.
2. Programmatic guaranteed – committed through a DSP, and just as binding as a direct booking.
3. Private marketplace deals – invited buyers bidding above a negotiated floor.
4. Open auction – any buyer above the floor price.
5. House content – the network’s own promotions, venue information or partner content when nothing else fills the slot.

Example – mixing demand on one screen: A network sells a shopping centre’s main LED screen with a guarantee of 12 plays per hour for a local car dealer. The player spreads those 12 plays evenly across the hour, reserves two slots per loop for programmatic demand, and fills any slot that receives no bid with information about the centre. At the end of the day, the dealer’s report shows exactly 12 plays in every hour, and the programmatic slots carry their own logs for the SSP.

Getting this logic wrong is expensive. If programmatic ads take slots reserved for guaranteed campaigns, the network under-delivers on contracts it signed directly.

Bidding ahead, pre-caching and creative approval

In programmatic DOOH, the bid often happens well before the play. The SSP needs time to run the auction, the network may need to approve the creative, and the player needs time to download a video file that can weigh tens of megabytes. If the player tries to fetch the creative at the moment of the slot, the screen shows a black frame or skips the ad.

Example – timeline for one morning ad: A coffee brand targets station screens on cold mornings. At 06:40, the player requests an ad for its 07:05 slot. The SSP returns a winning creative as a VAST response. The network’s approval rules check the category and format automatically. The player downloads the video, buffers it and waits. At 07:05:00, it plays, and at 07:05:15, the play log is written with the screen ID, creative ID and exact timestamps.

In the Broadsign integration we built for IMS Sensory Media, players query the SSP ahead of each programmatic block, parse the VAST response, download and buffer the creative, and play it in the scheduled slot. One detail from that project shows how physical this problem is. Players had inconsistent start-up latency between 0.5 and 2 seconds, so instead of adding a fixed delay, the team calculated the median delay per device to remove outliers and time ads precisely, without black frames between them.

Proof of play and reconciliation

“No play, no pay” is the basic rule of programmatic DOOH advertising. A buyer pays only for plays the network can prove, which makes the play log the most valuable piece of data the network produces.

What a play log contains, and why clocks matter?

A useful play log records one line per play, with the screen ID, creative ID, campaign or deal ID, the exact start and end time, the playback status and the multiplier applied. The player writes it locally and uploads it to the CMS, which passes the relevant entries to the SSP.

Time is the weak point. If a player’s clock drifts by a few minutes, its logs no longer match the slots the SSP sold, and plays can be rejected even though they happened. Players should synchronise their clocks regularly with a reliable time source and record the time zone explicitly, especially in networks that cross borders.

Why CMS, SSP and DSP counts don’t match?

Every network running programmatic campaigns sees discrepancies between its own numbers and the buyer’s report. The usual causes are:

• Offline players that played the ad but uploaded the log after the reporting window closed.
• Creatives rejected on the device, for example because of a format or codec the player could not decode.
• Clock and time-zone errors that place plays outside the sold slot.
• Duplicate or missing log entries after a player restart.
• Different counting rules, where one system counts a started play and another counts only completed ones.

There is no single setting that fixes this. What helps is reporting that shows where each failure happened. In the IMS project, the reporting system classifies each error as SSP-related, a CMS configuration mistake or a device-level failure, so the operations team knows who has to act. Players also cache their schedule and logs, so a lost connection delays reporting instead of losing plays.

Measurement standards buyers trust

Buyers are sceptical about programmatic DOOH measurement, and the discussion on forums such as Reddit’s r/programmatic shows it. The recurring question is whether modelled impressions reflect real audiences.

Standards help. The IAB published a DOOH measurement guide to align media owners, platforms and buyers on what counts as a play and an impression, and the MRC sets out how playout data and audience data should be combined in audited measurement. Networks that follow these definitions, work with recognised measurement vendors and expose clean play logs sell more easily to agencies with strict verification rules.

Connecting a screen network to programmatic demand

Knowing how the stack works is one thing. Connecting your own screens to it is another, and the right approach depends on how much control you want over the player and the schedule.

Three ways to integrate with an SSP

Integration pattern	How it works	Control over playback	Effort	Multiple SSPs
SSP’s own player	Screens run the SSP vendor’s player software	Low	Low	Usually tied to one vendor
SSP SDK in your player	Your player embeds the SSP’s library for ad requests and reporting	Medium	Medium	One SDK per SSP
CMS-to-SSP API integration	Your CMS and player request ads through the SSP’s API, often receiving VAST responses	High	Higher at the start	Possible through the same logic

The first option is the quickest way to start, but it means handing part of your screens to another company’s software. The third takes more work up front and gives you the most control, including over priority rules, caching and reporting. For networks that already run their own CMS, an API integration usually fits best.

Do you need to replace your CMS to sell programmatically?

Not always. The answer depends on what your current CMS lets you do.

• SaaS CMS with built-in SSP connectors – some platforms connect to one or two SSPs out of the box. That is enough to start, but you sell only through the partners your vendor chose, with the reporting your vendor provides.
• Your own CMS, or one with an open API – you can add an SSP integration on top, keep your scheduling rules and connect more SSPs later.
• A closed CMS with no API – programmatic usually means either running the SSP’s player next to your content or migrating to a platform you control.

Example – adding programmatic to an existing network: An operator runs 400 screens on its own CMS and sells them only through direct deals. Instead of replacing the system, it adds a programmatic module. The CMS opens two slots per loop to an SSP, the players get ad caching and play logging, and direct campaigns keep running exactly as before. Programmatic revenue starts filling slots that used to show house content.

Choosing a DOOH SSP

A DOOH SSP decides which buyers can reach your screens, so it is worth comparing a few before you commit. The questions we see networks ask most often:

1. Which markets and buyers does it reach? Some SSPs are strong in North America, others in Europe or Asia-Pacific.
2. Which DSPs are connected? Check that the DSPs your target agencies use can see the inventory.
3. Which deal types does it support? Open auction, PMP and programmatic guaranteed should all be available.
4. How does integration work? API with VAST responses, an SDK or only the SSP’s own player.
5. How are plays reported and reconciled? Ask how discrepancies are handled and how quickly logs must arrive.
6. What is the commercial model? Most SSPs take a share of media revenue, and the terms differ.

Many networks connect to more than one SSP to reach more demand. An API-based integration makes that much easier, because the same scheduling and logging logic serves every SSP.

Case study – Broadsign integration for IMS Sensory Media

IMS Sensory Media runs its network on a platform Fingoweb built and continues to develop. To monetise empty slots, IMS wanted programmatic demand without handing its screens to another vendor's player. We connected the IMS CMS to Broadsign's SSP through an API integration, with players that request, buffer and play VAST ads inside time blocks the CMS opens for programmatic campaigns. Scheduled content keeps running around those blocks, and the reporting system traces every step from ad request to play. The result is a network that sells through programmatic demand while keeping full control of its own screens and data.

Readiness checklist before you connect

Before you sign with a DOOH SSP, check that your network can support programmatic DOOH:

1. Accurate screen metadata – location, venue type, resolution and slot structure for every screen.
2. Audience data – a source for impression multipliers per screen and daypart.
3. A CMS with an API – able to open programmatic time blocks and pass data to the SSP.
4. Players that cache ahead – downloading creatives before the slot and playing offline if needed.
5. Per-play logs with synchronised clocks – the basis for billing.
6. Priority rules and fallback content – so guaranteed deals are protected and empty slots never stay black.
7. Content approval rules – automatic checks for format, category and local restrictions.

Few networks tick every box on the first pass. The missing pieces are usually software, and software can be built.

Fingoweb's role in your programmatic DOOH stack

Fingoweb builds the screen-side software that programmatic DOOH depends on. We work with integrators and screen network operators who want to sell programmatically without giving up control of their CMS, players or data, and the code we write belongs to the client. The table maps the challenges described in this article to what we build.

Challenge	What Fingoweb builds
Screens invisible to buyers because of poor metadata	CMS modules that keep screen data, venue types and slot structure in sync with the SSP
No reliable audience numbers	Integrations with footfall and mobile data providers, and camera-based audience counting
Black frames or skipped ads	Players that request ads ahead of the slot, pre-cache creatives and calibrate start-up latency per device
Programmatic ads colliding with direct deals	Scheduling logic with priority rules, share of voice per screen and even pacing of guaranteed plays
Play counts that don't match the buyer's report	Per-play logging with clock synchronisation, offline log storage and errors classified by SSP, CMS or device
Dependence on one SSP or one vendor's player	API integrations that let one CMS serve several SSPs
Mixed hardware across the network	Player apps for Samsung Tizen, LG webOS, Android, Windows and Linux
Reports buyers find hard to read	Branded campaign reports built from the same play and audience data

You can start with a single piece, for example an SSP integration for an existing CMS, or build a complete platform with programmatic sales designed in from day one.

Tell us how many screens you run, which CMS and players you use and which SSP you want to sell through, and we will come back with a plan and a free estimate for the software your network needs to sell programmatically.

FAQ

What is pDOOH?

pDOOH is short for programmatic digital out of home, the automated sale of ad plays on digital screens in public spaces through DSPs and SSPs, instead of manual bookings. For the screen network, it means part of each screen's schedule is filled by auctions or programmatic deals, with the CMS and player handling delivery and proof of play.

What is an impression multiplier in DOOH?

An impression multiplier is the number of impressions assigned to a single ad play, based on how many people are expected to see the screen at that moment. It lets buyers compare DOOH with other channels on a CPM basis. A play at a busy station at rush hour may count as dozens of impressions, and the same play at night as only a few.

What is the difference between PMP and programmatic guaranteed in DOOH?

Both are private deals between a network and selected buyers, but they differ in commitment:

• PMP – invited buyers bid above a negotiated floor, with no guaranteed volume on either side.
• Programmatic guaranteed – one buyer commits to a fixed number of plays or impressions at a fixed CPM, and the network reserves that inventory.

For the network's schedule, programmatic guaranteed behaves like a direct booking, while PMP behaves like an auction.

Which DSPs and SSPs support programmatic DOOH inventory?

On the buying side, DOOH DSP options include:

• The Trade Desk, Google Display & Video 360 and StackAdapt,
• Vistar Media and Hivestack, which also operate on the supply side.

On the selling side, networks commonly connect to SSPs such as Broadsign, Hivestack, Vistar Media, VIOOH and Place Exchange. Which SSP to choose depends on the markets you sell in and the buyers you want to reach.

Can I sell my screens programmatically with my existing CMS?

Often, yes. If your CMS has an API or is your own software, an SSP integration can be added on top of it without replacing the system or changing how direct campaigns run. If the CMS is closed, you can run the SSP's player alongside your content or move to a platform you control. The deciding factor is whether the players can cache ads ahead of time and produce reliable play logs.

How do you know a programmatic DOOH ad actually played?

Through proof-of-play logs. The player records every play with the screen, creative, deal and exact time, and those logs are reconciled with the SSP and DSP before billing. Plays without a valid log are not paid for, which is why reliable logging, clock synchronisation and offline caching on the player matter as much as the auction itself.