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.

The technique produces genuinely useful rankings, and it requires a commercial licence and a lawful basis, which pitches rarely mention. The licence is expensive enough to be a real barrier. The lawful basis is needed because the UK GDPR counts location data and online identifiers among the things that make data personal, and a business-to-business purpose does not exempt them. AdBuyMCP's policy engine treats person-level targeting on device identifiers as needing consent, and the ICO says that where PECR requires consent, legitimate interests cannot be the lawful basis.

So the question to ask of any out-of-home proposal is which of its claims survive without that dataset, and most of the useful ones do.

An out-of-home plan is built from the inputs below. 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. The rule uses commuting hours and needs no movement panel.

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 and dayparts. Its screen-ranking list comes back empty. That empty list is deliberate: 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.

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 why the list stays empty: 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. Where a screen list matters more than an algorithmic ranking, which without movement data is most of the time, pick the screens yourself.

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 live operation (forecast, activate, pause, creative submission, reporting, inventory listing) stops 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.

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 no vendor has accepted a call from it yet. 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: 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.