By Chris Gadek, AdQuick.Topic: building a media-planning tool with geospatial APIs.
I set out to build something that sounded simple on a Friday afternoon and was still humbling me the following Wednesday: a small media-planning tool that could take a location and a date range and return which physical ad placements were available and what they cost. Give it a neighborhood, get back a list of billboards with prices, the way you would query available server instances in a region. I assumed the hard part would be the planning logic. It was not. The hard part was that the physical world does not ship with an API, and building one is a real geospatial data problem.
Here is what I underestimated. A web ad slot arrives pre-structured. It has a URL, which is a globally unique identifier. It sits in a document with a known shape, and it reports back through a pixel. The environment was built to be read by machines because machines were already serving it. A billboard inherited none of that. Its location is a point on the earth with an orientation. Its audience is a function of the road it faces, the direction of travel, and the speed of the cars. Its availability is a schedule with holds and expirations. Its price is a function of date and demand dressed up as a laminated number. For most of the medium's history, all of that lived in a PDF and a salesperson's memory, not in anything you could hit with a GET request.
So the tool I actually needed to build, before any planning logic could exist, was a normalization and geospatial layer. Let me walk through the parts, because they will be familiar to anyone who has wrangled messy location data.
The first problem is entity resolution. The same physical billboard shows up in multiple vendor feeds under different names, different coordinate precisions, sometimes with the coordinates simply wrong. You cannot plan against inventory if one board is three records. So you cluster candidate records by proximity and attributes, resolve them to a single canonical entity, and keep a mapping back to each source. This is fuzzy matching with a geospatial distance metric instead of pure string similarity, and it is the foundation everything else sits on.
The second problem is representing exposure honestly. A billboard's value is not its coordinates. It is how many of the right people actually see it, which depends on the road geometry, the sightline, the direction the panel faces relative to traffic flow, and how fast people are moving past it. Modeling that means joining the panel's position and bearing against road network data and traffic patterns. A geospatial library and a decent road dataset get you most of the way, but the point is that the useful field, estimated exposure, is computed, not given.
The third problem is state. Availability and price are not static attributes. They are time series with holds, bookings, and expirations, and they change underneath you. A planning tool that reads stale availability is worse than useless, because it will confidently offer you inventory that is already gone. So you need live ingestion and a current-state store, the same discipline you would apply to any inventory system where the underlying resource is being consumed concurrently.
Only once those three layers exist does the thing I originally set out to build become almost boring, in the good way. A buy-side system for physical media, a DOOH DSP, is only possible on top of structured, real-time, geospatially modeled inventory. The bidding and pacing logic is well-trodden. It is the same category of problem the web side solved years ago. The reason it took so much longer to arrive in the physical world was not that the medium was harder to buy in some fundamental sense. It was that nobody had built the clean interface to it, and you cannot write a planner against inventory you cannot query.
That reframed the whole exercise for me, and it is the part worth passing on to other developers. I had assumed out-of-home lagged the web because it was somehow a lesser or older medium. It is not. People still move through physical space and still look up, and a message on a wall cannot be ad-blocked or skipped. The medium was never the bottleneck. The interface was. And an interface is a thing you can build.
If you want to try a version of this yourself, start small and honest. Take a single city. Get whatever inventory data you can, however messy. Do the entity resolution first, because everything downstream depends on it. Model exposure with a real road dataset rather than treating a coordinate as if it were an impression. Represent availability as state that expires. By the time you have done that, you will have rebuilt, in miniature, the actual hard problem of programmatic out-of-home, and you will understand why the interesting frontier here is not another web service layered on the dozen you already call. It is wiring a stubbornly physical medium into the same programmable surface as everything else, and it is a genuinely satisfying problem, the kind where the model is trivial and the data plumbing is the entire game.
Top comments (0)