Buying UK DOOH without a movement-data licence

Programmatic out-of-home is sold, almost universally, with audience segments: business professionals, affluent shoppers, IT decision makers. Underneath those labels sits a mobility dataset — location signals from mobile devices, licensed from a data company, used to build an index of which screens are passed disproportionately often by devices belonging to a given segment.

That is a real technique and it produces genuinely useful rankings. It also carries two costs that rarely appear in the pitch. It requires a commercial licence, which is expensive enough to be a real barrier. And it requires a lawful basis, because device-level location signals are personal data under UK rules and a business-to-business purpose does not exempt them: person-level targeting built on device identifiers is consent territory, not legitimate-interest territory.

So the honest question to ask of any out-of-home proposal is which of its claims survive without that dataset. The answer is: most of the useful ones.

Four inputs carry an out-of-home plan. Three of them touch no personal data at all; the fourth carries whatever basis its provider attested, and the manifest names that provider.

The claim "this screen reaches business professionals" is, in almost every case, a compressed version of "this screen is in a place business professionals pass through, at hours when they pass through it". Once you say it the long way, you can build it out of a schedule.

AdBuyMCP does exactly that, and the rule is visible in the compiler. Where the brief carries firmographics — a sector, a seniority, a business audience of any kind — the plan buys the two commute windows, roughly half past six to ten in the morning and half past four to eight in the evening. Where it does not, the plan buys the long daytime and evening window instead. Nothing about that requires a movement panel; it requires knowing what a commute is.

The claim you are left with is weaker and true: you have bought a rail station concourse at commuter hours because business professionals are known to be there in numbers, not bought business professionals. That distinction is the difference between a plan you can defend to a data protection officer in one sentence and one that needs a paragraph.

AdBuyMCP's out-of-home compiler returns a targeting specification with audience segment identifiers, venue types, geographic polygons, dayparts — and an empty screen-ranking list. That empty array is deliberate and it is documented as such on the channel page: the rationale describes screens ranked by persona over-index using movement data, and the product says plainly that this half of the rationale describes the intended design rather than shipped behaviour.

It would have been easy to fill. A seeded number between 105 and 168 next to each screen would look exactly like a real index, and nobody reviewing a plan would query it. That is precisely the argument against doing it: a fabricated index is indistinguishable from a measured one at the point of sale and only distinguishable afterwards, when it is too late to matter.

The compensating control is that manual selection is a first-class path rather than a fallback. Picking billboards, venues and screens by hand is fully supported in the product, and where a screen list matters more than an algorithmic ranking — which, without movement data, is most of the time — that is the honest route.

Three rails reach out-of-home in AdBuyMCP, and their states differ enough to matter.

The Perion (Hivestack) buyer-side API is the one with real published documentation, and the live client is written against it: campaign and line-item creation, availability checks against unit identifiers, pause, and a unit catalogue. Two details from that integration are instructive for anyone building against the same API. Line items target numeric unit identifiers, so a plan expressed in venue types and postcode polygons has to be translated into specific units before it can be activated. And dayparts are a bit field of 168 whole hours, so a daypart of half past six to ten in the morning covers three whole hours rather than three and a half — the adapter includes only fully covered hours rather than widening the range, because widening a daypart silently buys inventory the buyer did not ask for.

Vistar Media is a stub. Every one of its live methods — forecast, activate, pause, creative submission, reporting, inventory listing — throws before making any request, and the reasons are specific: no published demand-side campaign endpoint matching the shape this platform sends, a creative endpoint limited to approved third-party bidders needing an offline-issued key, and a reporting response contract that has to be observed against a real seat before it can be normalised. Our own README once described this connector as having a live client; the code is right and the README was stale.

The third is not a dedicated out-of-home integration at all. StackAdapt carries DOOH on the same GraphQL seat as its CTV and audio inventory, which makes it the broadest single rail in the product and the only one where an out-of-home line can sit in the same buy as the video and audio lines. Its grade is client-built, like the rest of that connector: the client is written and passes tests against mocked responses, and no vendor has accepted a call from it. One limit travels with it — the client reports that StackAdapt publishes no inventory-browse API, so any out-of-home catalogue it shows you is a sandbox catalogue rather than a screen list you could buy from.

The practical upshot is stated on the channel page and repeated here because it is the sort of thing a buyer should hear twice: no DOOH rail can be driven end to end from a compiled persona in live mode today. Activation needs hand-picked unit identifiers, because venue and postcode semantics have no verified translation into vendor identifiers.

Out-of-home creative fails in a way no other channel's does: the reader is moving. The constraint that follows is not aesthetic, it is arithmetic, and AdBuyMCP enforces it in code rather than advising it in a checklist — a headline is capped at seven words.

The formats are fixed by the screen rather than by the seller: portrait at 1080 by 1920, landscape at 1920 by 1080, banner at 1400 by 400. The studio renders to the exact screen resolution rather than scaling a stretched asset into it, which matters more on out-of-home than anywhere else because a rescaled asset on a high-resolution portrait screen is visibly soft at the distance people actually read it from.

The rule of thumb worth keeping whatever tool you use: one idea, one image, a brand that is legible at a glance, and no telephone number. A headline nobody can read at four miles an hour is not creative, it is spend.

Out-of-home has the weakest targeting claim of the digital channels and the strongest position on causal measurement, and those two facts are related. Because the buy is geographic, it can be held out geographically, and a matched-market test needs nothing from the medium except the ability to buy some places and not others.

Proof of play comes from the seller: a record that the creative played on a screen at a time. That is delivery evidence, not exposure evidence, and it should be labelled as delivery. The exposure ledger in AdBuyMCP writes out-of-home exposures at postcode-sector level, which in principle supports frequency deduplication against cinema and connected TV in the same area and a sequential journey view across them. Today that ledger is fed only by the deterministic sandbox: there is no inbound ingest route for viewshed panels, so the journey view is a working mechanism awaiting live input rather than evidence about a campaign.

If you want out-of-home to prove something, budget for the holdout at the same time as the media, and run the power calculation before the flight rather than after it.