How Programmatic Ads Run on Taxi Screens

Programmatic taxi ads move from buyer settings to screen playback - but winning a slot doesn’t prove the ad ran. I check three things separately: ad assignment, completed playback, and billable delivery. For example, an ad assigned inside a 2-mile target area may no longer qualify if the taxi leaves before playback.

Here’s how I follow the process:

• Set up: Register screens, then set budgets, locations, schedules, and ad-file requirements.
• Select: Buying and selling platforms match open slots with eligible ads.
• Play: The onboard player checks location, time, file compatibility, and permission - even when using cached files offline.
• Verify: Match playback logs to transactions, keep audience estimates separate, and resolve billing gaps.
• Test: Check screen connections, file playback, offline limits, fallback content, and restart behavior before launch.

My bottom line: <u>a playback log is not proof that someone watched</u>. Keep those measures separate when checking what your campaign delivered.

1. Set Up Screen Inventory and Buyer Campaigns

Once the campaign is loaded, the platform needs accurate inventory records to match each ad request to the right screen.

Register Screens and Set Ad Slots

• Create one inventory record per screen and link it to its vehicle or fleet. Include the screen ID, placement, pixel dimensions, physical screen size, orientation, accepted file formats, operating hours, connectivity, and device status. Keep rooftop LED screens separate from in-taxi touchscreens.
• Set the slot duration, loop length, slots per loop, and advertiser share-of-voice limits. Group screens by market, fleet, route, or format.
• State whether delivery is sold as plays, time slots, or impressions. Document how impressions are calculated before setting a floor price in U.S. dollars per thousand impressions (CPM).
• Confirm accepted file specifications, bid-request fields, and reporting fields.

Set Campaign Budgets, Locations, Schedules, and Assets

Set the buyer-side rules the system checks before serving an ad:

• Budget and targeting: Set total and daily budgets, a bid ceiling, pacing, target markets, and screen formats.
• Schedule and location: Set start and end dates and dayparts in the account’s local time zone. Define geographic boundaries using ZIP codes or a radius in miles. Confirm whether location refers to the current GPS position, last known position, or assigned operating area.
• Ad files: Supply approved files with dimensions, duration, file type, audio setting, language, campaign assignment, validity dates, and destination links where applicable. Provide separate versions for each format. Rooftop ads need text people can read from a distance. Tablet ads need the correct orientation and supported touch or landing-page behavior. Check file-size, frame-rate, safe-area, and audio requirements before uploading so files are ready for playback.
• Frequency controls: Set caps by screen, vehicle, campaign, or estimated person, and state the period each cap covers. Plays are not impressions, modeled reach is an estimate, and a per-screen play limit is not a passenger cap. Audience data and frequency controls vary by integration and do not necessarily identify individual passengers. Record data sources and modeling limits before promising audience-level targeting.

sbb-itb-6b5f97f

2. Trace the Ad Request and Selection

Once setup is complete, the supply side uses buyer rules to build a bid request when a screen slot opens.

Follow a Slot From Availability to Ad Assignment

• Mark availability and send the request: The player marks an open slot as available. The SSP or exchange packages that opportunity into a bid request and sends it to connected DSPs. The request typically includes the inventory ID, screen position and dimensions, creative format, slot duration, scheduled start time and time zone, location data, operating status, estimated impressions, deal or placement identifier, floor price in USD, and technical requirements. These requirements cover file type, resolution, frame rate, audio policy, and maximum file size.
• Check eligibility and choose the winner: Each DSP checks the request against campaign rules, available budget, deal terms, and creative compatibility. It returns a bid price and creative reference, or a no-bid response. Supply-side rules then select the winner. Guaranteed reservations or private deals may take priority, so the highest bid doesn’t always win.
• Schedule the ad: The ad server adds the approved creative to the player schedule. Record the transaction ID, campaign ID, creative ID and version, screen ID, and intended playback window. These records let you match the assignment to delivery later.

Requests may arrive seconds, minutes, or longer before display, allowing time for asset delivery and caching. When tracing delays, keep request, bid, assignment, download, scheduled time, and actual playback time separate.

Understand Each System’s Role

The table tracks handoffs from buyer settings through playback and reporting. One platform may handle several roles, and the order of checks varies by integration.

System component	Main function	Data received	Data returned
Advertiser or agency	Sets campaign goals, budget, targeting, and creative	Campaign brief, locations, dates, budget, assets, measurement requirements	Campaign settings, approved creatives, bid or deal instructions
DSP	Checks opportunities and submits bids	Bid request, targeting rules, budget, deal terms, creative eligibility	Bid or no-bid, bid price, campaign ID, creative reference
SSP or exchange	Packages inventory and applies supply-side transaction rules	Slot availability, floor price, screen metadata, timing, location, demand responses	Bid request, auction outcome, clearing data, transaction ID
Ad server	Schedules and assigns approved ads to slots	Campaign priority, selected bid, creative metadata, schedule, fallback rules	Playlist or assignment, delivery instructions, status events
Vehicle player	Downloads, validates, caches, and plays ads	Playlist, media files, timing, device commands	Playback event, timestamp, screen ID, creative ID, device status, error logs
Reporting layer	Matches transactions with delivery	Bid records, assignments, playback logs, telemetry, audience models	Proof-of-play, delivery totals, estimated impressions, spend, discrepancies

After assignment, the player retrieves and validates the file, plays eligible content, and records playback. Reporting then matches that event to the transaction. A player log proves playback, not audience attention. The next checks cover location, time, and budget before playback.

3. Apply Location and Time Rules Before Playback

Check Location, Time, Budget, and Priority

After assignment, the player checks the ad against stored geo-time, budget, priority, and expiration rules. Playlist inclusion alone doesn’t permit playback. Just before the ad runs, the player rechecks screen eligibility, current GPS position, campaign-local time, ad format, spot duration, and playback authorization.

If the taxi leaves the 2-mile geofence before playback, the ad becomes ineligible.

Reject GPS fixes older than the allowed age threshold, and log each fix’s time and accuracy. A wrong device clock can trigger an ad outside its campaign window. Synchronize the clock with NTP and check the window using the campaign’s configured time zone.

Validate and Cache Ad Files

Check the ad against the registered screen profile, including file type, codec, dimensions, orientation, duration, size, frame rate, audio policy, and content. Download the asset and schedule securely. Then verify the checksum and decode the file before placing it in the active cache.

Local caching lets ads play during connectivity outages, but only within the downloaded authorization. Screen type also determines which assets the player accepts and how it caches them.

Requirement	Rooftop LED screen	In-taxi tablet
Format	Images or motion files supported by the LED controller	Images, video, or HTML where supported
Orientation	Usually landscape or a custom layout; do not assume 16:9	Portrait or landscape, depending on installation
Playback limits	Controller resolution, frame rate, brightness, power, and audio policy	Codec, screen sleep, app state, thermal limits, and audio policy
Interaction	Generally non-interactive	Touch may be supported, subject to passenger-facing safety rules
Delivery	Controller-compatible local cache	Compatible assets with defined offline behavior

Run Eligible Ads or Approved Fallback Content

At each slot, reject ads that fail the current rules, then apply priority, pacing, and frequency caps. If no paid ad qualifies - or location, time, or authorization checks fail - use approved fallback content, such as a house ad, public-service message, or network slate. Otherwise, follow the network’s explicit no-play rule.

Cached assets remain authorized only until their stored permission expires. Offline players can enforce stored permissions, local counters, and expiration times. They can’t detect later budget exhaustion, pauses, or campaign edits until they reconnect.

Log play status, campaign/asset IDs, screen or vehicle ID, scheduled and actual times, GPS status, connectivity, and failure reasons. Upload queued events when service returns. These playback logs become the proof-of-play records used in the next step.

4. Verify Playback and Reconcile Reports

Match Proof of Play to Transactions and Billing

After playback, match device logs to the campaign records that created the slot. Proof of play is a device log, not a viewability measure. Track the screen or vehicle ID, campaign, creative, slot, start and end times, duration, status, and GPS or geofence data. Store logs locally while offline, then upload them securely when the device reconnects. Validate records and label late data as delayed.

Follow this sequence: play log → transaction match → billing reconciliation → exception review. Use one event key to match buyer transaction IDs with campaign, deal, creative, and device events. Reject exact duplicates, retain valid repeat plays, and flag possible duplicates caused by retries or clock drift for review. Keep partial plays and missing transactions flagged - not counted as completed delivery.

Keep playback counts, audience estimates, and billable delivery separate. Apply the contracted impression model and multiplier, along with the contract’s rules for completion, exclusions, billing units, and rounding. State the billing method clearly so readers don’t mistake device logs for audience counts.

Find Delivery Gaps and Reporting Delays

Compare auction wins, scheduled ads, completed plays, estimated impressions, and billable delivery by market, screen type, time window, fleet, and asset. Find the step where the counts diverge.

Treat mismatches as operational exceptions. Check for rejected files, missed plays, stale GPS data, duplicate events, clock errors, and device downtime. Review the last heartbeat, GPS fix, and asset version. Attach an exclusion reason to every rejected record.

Real-time analytics can still receive offline playback records later. Store playback time and ingestion time separately, and backfill accepted events into their original playback window. Label reports as pending validation or finalized, display the last successful synchronization, and agree on a reconciliation cutoff before invoicing. Use any remaining mismatches to guide the readiness checks in the next step.

5. Check Readiness From Buyer to Screen

Use this final checklist to confirm the buyer-to-screen chain works from end to end.

• Connected inventory: Check screen IDs, vehicle assignments, recent heartbeats, synced clocks, and SSP mappings.
• Campaign rules: Check that buyer rules match the approved launch settings.
• Approved file versions: Confirm the approved file version has downloaded and plays on the target screen hardware - not just in the upload portal.
• Offline and fallback tests: Test disconnects, cache expiry, decision-service failure, and power-cycle recovery. Confirm that expired authorization stops paid playback and approved fallback content takes over.
• Reporting match: Check that test playback appears in reports and matches transaction and billing records. Flag unresolved exceptions before sign-off.

For unattended vehicles, verify Auto Start and Kiosk Mode after a power cycle. The player should return to the ad app without driver intervention.

FAQs

How can I limit ad overspend during outages?

Use real-time platform monitoring to track device health and screen uptime. Enroute View Media’s automated alerts let you know when a device goes offline, so you can pause campaigns quickly and avoid spending money on screens that aren’t working.

Supported devices can continue playing stored content during temporary internet outages. Check device status in the dashboard to spot and disable underperforming inventory until the connection is fully restored.

How should I choose a taxi ad geofence?

Start with a geofence of about 980–1,640 feet (300–500 meters) to balance targeting precision with audience reach. Allow enough room for vehicles to stay inside the zone for at least 15 seconds so the ad can trigger and display correctly.

Use a cloud-based management platform, such as Enroute View Media’s, to set boundaries around high-traffic neighborhoods, stores, or competitor sites.

What should my contract require for billable plays?

Your contract should require verifiable proof-of-play for every ad: a precise timestamp, the vehicle’s exact GPS location, and the ad’s exposure duration. Sensor-based audience estimates don’t confirm playback. These logs do.

Cloud-based content management systems generate proof-of-play logs as the definitive record of ad delivery. Consistent formats, such as JSON, make those records transparent and simplify advertiser billing.

Related Blog Posts

• How Programmatic Ads Work in DOOH
• Programmatic Taxi Ads Solve 5 City Reach Gaps
• Vehicle Screen Sync: Ultimate Guide for DOOH
• SSP vs DSP in Vehicle DOOH Ad Delivery