Moving OOH - also called mobility OOH - is inventory that travels: truck-side and truck-back mobile billboards, wrapped vehicles, and screens mounted on buses, trams, and taxis.

It is the most general of the three media types, because it is the only one where position varies - and it may vary content as well.

A static unit holds both fixed, so its viewshed is computed once and time enters only as the flight dates. A digital unit holds position fixed and varies content, so the viewshed is fixed and the time windows come from ad play logs. A moving unit always varies position, and depending on the format may vary content too:

• Fixed content, moving. A vehicle wrap or a truck-side poster carries one creative for the whole flight. Every moment the asset was operating is a moment the campaign was on display, so the only question is where it was.
• Rotating content, moving. A digital screen on a bus or taxi cycles between advertisers while the vehicle travels. Position and content both vary independently, so a device is exposed only where the two line up - near the asset, while this creative was playing.

Measuring either requires knowing the asset's path through space and time, at fine enough resolution to reconstruct where it was at any given moment. For rotating content it additionally requires knowing which creative was showing across each stretch of that path.

🚧

We Need Waypoints, Not a Route Description

A route name, a list of streets, or a daily mileage total cannot be used. Exposure requires timestamped positions along the actual path travelled.

🚧

For Rotating Content, Play Times Are Required Too

A digital screen on a vehicle needs the same thing a roadside digital unit needs - the exact windows the creative played - in addition to the positions held during those windows. A waypoint log covering the vehicle's whole day, with no indication of what was on screen when, will overstate exposure by attributing the entire route to this campaign.

Waypoint Logs

The required file is a waypoint log: a series of records, each describing a segment of travel with a start and an end. Together they trace the asset's journey.

Each row is an interval rather than a single instant, which lets Mira determine the asset's position between reports and construct a moving viewshed along the segment.

The same interval structure carries content timing, which is what makes one format serve both fixed and rotating creative:

• Fixed content. Rows cover the asset's whole operating period. Every interval is a period the campaign was on display.
• Rotating content. Rows cover only the periods this campaign's creative was playing, tagged with creative_id. A stretch of travel during which a different advertiser was on screen is either absent from the file or attributable to that other creative.

In other words, a row means this asset was travelling from here to there during this window, showing this. For a wrapped vehicle the last clause is constant; for a digital screen it is the thing that varies.

Start Position and Time

Required for every row:

• start_time - well-formed timestamp with an unambiguous timezone
• start_latitude - latitude at the start of the segment
• start_longitude - longitude at the start of the segment

Optional, and used to refine the viewshed when present:

• start_speed - speed at the start of the segment
• start_bearing - direction of travel
• start_facing - direction the screen faces, which on a vehicle is usually relative to travel

End Position and Time

• end_time - required - timestamp at the end of the segment
• end_latitude - required
• end_longitude - required
• end_speed - optional
• end_bearing - optional
• end_facing - optional

Vehicle and Route Metadata

• vehicle_id - identifier for the specific vehicle carrying the media
• route_id - identifier for the route being run, where the asset follows fixed routes
• gtfs - a reference to a GTFS feed, for transit inventory running on published schedules

For transit media in particular, vehicle_id and route_id are worth supplying even when they aren't needed for the computation itself, because they make useful cuts - performance by route is a question that comes up almost every time.

Standard and Custom Metadata

Moving Sources accept the same metadata as any other Source type, and any field provided can be used as a cut:

• unit_id, geopath_id, venue_type, vendor_name, contract_id, campaign_id, creative_id
• custom fields, prefixed with custom_

See Standard Schemas for OOH Data Onboarding for the full specification.

Resolution Matters More Here

The gap between consecutive waypoints sets the precision of the whole measurement. Reports every few seconds trace a path closely. Reports every ten minutes leave a vehicle's position across most of a city essentially unknown, and the exposure that occurred in those gaps cannot be recovered.

Reports at long intervals are also actively misleading rather than merely incomplete: two positions fifteen minutes apart imply a straight line between them, and a vehicle that in fact drove a loop will have its exposure attributed to streets it never travelled.

📘

In Practice This Is Rarely a Problem

Moving OOH is a relatively new format and the vendors operating it are generally built on GPS telemetry from the outset, so high-resolution waypoints are usually available as a matter of course. The conversation to have early is about the export, not the collection.

Waypoint Checklist

Before onboarding a moving Source, check a sample:

• Timestamps are well-formed and the timezone is unambiguous. This is the single most common problem across all Source types.
• Both a start and an end are present for each row, in position and in time.
• Resolution is high enough - segments measured in seconds rather than minutes.
• The log covers the whole flight, not one vehicle out of a fleet or one day out of a month.
• There are no gaps during operating hours. A vehicle that reports for an hour and then goes quiet for two has either stopped or stopped reporting, and the two need distinguishing.
• Cut fields are present, including the vehicle and route identifiers you will want results broken out by.
• For rotating content, creative windows are present. Rows should identify which creative was showing, and cover only the periods it was. A file whose intervals span the vehicle's entire shift is a position log, not a play log.
• Positions are plausible. Sort by time and check for jumps that no vehicle could have made - a common symptom of interleaved fleets in one file.