# Programmatic Out-of-Home Advertising and Impression Measurement: A Technical Architecture

1. From Selling Space to Selling Audiences: The Digital Reconstruction of OOH

Out-of-home advertising is one of the oldest ad formats. Its original business model tied advertising revenue to public infrastructure: operators funded the construction and upkeep of urban street furniture such as bus shelters, then recovered costs and earned a margin by selling advertising on those facilities. The model spread to other countries and cities, and expanded from shelters into light boxes, bus exterior media, metro and airport media, and standalone large-format billboards. After more than five decades of global expansion, the leading players are now large multinational OOH media groups:

• Broad network coverage: operations across more than 80 countries and regions, close to 4,000 cities, and over a million advertising placements.
• Large reach: the media networks reach hundreds of millions of people per day.
• Substantial scale: annual revenue in the billions of euros, with more than ten thousand employees worldwide.

Scale, however, is only the starting point. Once the inventory reaches a million placements across thousands of cities, the traditional operating model — manual negotiation, paper scheduling, offline reporting — can no longer support granular selling or effect verification. The industry is shifting from “selling space” to “selling audiences, selling time slots, and selling verifiable impressions.”

From an engineering perspective, OOH differs from online advertising in three fundamental ways:

1. Hard constraints on physical resources: a billboard can carry exactly one creative at any given moment; there is no notion of “concurrent requests” as in online ads.
2. Tight coupling of time and space: every impression is bound to a specific “placement × date × time slot,” giving it the dual nature of inventory and audience.
3. Impressions cannot be directly observed: online ads record every click and view; OOH impressions can only be estimated indirectly through footfall models.

This article uses the global operations of an international OOH media group as its reference point. The business is abstracted into five stages — resource, inventory, audience, delivery, and measurement — and a concrete, implementable technical design is given for each.

2. Overall Architecture: A Five-Layer Capability Model

A programmatic OOH system divides into five layers:

Layer	Core Responsibility	Key Capabilities
Resource layer	Manage placement assets	Asset catalog, geocoding, spec modeling, content review status
Inventory layer	Manage sellable capacity	Inventory model, capacity calendar, reservation and release, conflict validation
Data layer	Provide audience estimates	Footfall collection, de-duplication modeling, external data fusion, compliance governance
Delivery layer	Execute transaction decisions	Contextual bidding, targeting match, frequency capping, scheduling and rotation
Measurement layer	Quantify and verify results	Impression calculation, reach and frequency estimation, third-party audit

The dependencies between these layers are one-directional: lower layers supply facts and capabilities to the layers above, and upper layers must never mutate the base data of lower layers. Two cross-cutting concerns sit alongside them:

• Operations support: self-service ordering for advertisers and agencies, review workflows, billing and settlement.
• Technical support: unified authentication, logging and tracing, monitoring and alerting, canary releases.

The core value of this layering is separation of concerns. Whether a placement requires content review is a state attribute of the resource layer; whether a schedule can pass conflict validation is a capability of the inventory layer; how many passengers pass through a given metro line during the morning peak is a measure owned by the data layer. With clean boundaries, each layer can evolve independently, and can be configured differently per country and per business line.

3. Resource Layer: A Unified Asset Catalog

The resource layer turns placements scattered across cities and business lines into asset objects with a consistent structure that are searchable and computable. At minimum, the model should include the following fields:

{
  "asset_id": "OF-SH-0001",
  "asset_class": "street_furniture | billboard | transit",
  "geo": {
    "city": "Sample City",
    "lat": 31.2304,
    "lng": 121.4737,
    "geo_level": "city | district | grid"
  },
  "media_spec": {
    "width_mm": 1185,
    "height_mm": 1750,
    "aspect_ratio": "6:5",
    "type": "static | digital",
    "refresh_cycle_min": 30
  },
  "visibility": {
    "view_distance_m": 8,
    "max_view_angle_deg": 60,
    "lighting": "backlit | frontlit | none"
  },
  "inventory_binding": {
    "unit": "slot",
    "slots_per_day": 288
  },
  "compliance": {
    "content_review": "required | exempt",
    "local_permit": "valid | expired"
  }
}

Three design points matter:

• Dual-granularity geography: store full latitude and longitude internally for distance calculations and geofencing, but expose only coarse labels such as city or district externally, so that placement-level precision is not leaked.
• Parameterized visibility: viewing distance, visible angle, and lighting determine when and from where a creative can actually be seen, and are the basic inputs to impression estimation. If they are recorded only as free text, they cannot participate in computation.
• Separate handling for static and digital screens: for a static screen the inventory unit is a start/end date and swapping creative requires physical labor; a digital screen can be sold by time slot or even by loop. Inventory modeling must therefore distinguish the selling granularity of the two resource types explicitly.

Placement assets should also carry a complete state machine, for example: planned, pending approval, on sale, under maintenance, and delisted. Each state maps to sellable and non-sellable inventory ranges, which avoids problems such as a delisted placement still being matched by the bidder.

4. Inventory Layer: From Schedules to a Capacity Calendar

The essence of OOH inventory is two-dimensional capacity: time × space. A static placement can be treated as one sellable unit per day, while a digital screen can be split into several time-slot units. At its core, the inventory system maintains a capacity calendar supporting three operations: reservation (lock at order time), confirmation (converted to sold after payment or approval), and release (automatic rollback if not confirmed in time).

The reservation mechanism has to solve three problems:

1. Concurrent conflicts: two orders competing for the same slot at the same time require an atomic decrement capability.
2. Timeout recovery: a reservation must carry an expiry, and a scheduled job or delayed message must release it uniformly.
3. Explainable conflicts: a conflict should return the specific reason — “occupied by schedule A,” “the slot falls in a maintenance window” — rather than a generic “insufficient inventory.”

A simplified inventory deduction routine:

def reserve_inventory(order_id, asset_ids, start_date, end_date, ttl_seconds):
    keys = [build_key(a, start_date, end_date) for a in asset_ids]
    # Atomically write a "pending" state; if any key already exists, the
    # whole operation fails, keeping multiple assets consistent
    results = atomic_set_if_absent(keys, value=order_id, expire=ttl_seconds)
    if not all(results.values()):
        rollback(keys, value=order_id)
        return ReservationResult(ok=False, conflicts=find_conflicts(results))
    schedule_settlement_task(order_id, delay=ttl_seconds)  # delayed message handles timeout release
    return ReservationResult(ok=True, order_id=order_id)

For large-scale inventory queries, a tiered storage strategy is recommended: hot data (the next 7–14 days) in a cache or distributed store with high-concurrency read capability, warm data in a relational database, and historical data archived to object storage. This keeps scheduling page latency low while controlling storage cost.

5. Data Layer: Audience Estimation and De-duplication

Unlike online advertising, OOH has no individual identifiers to collect, so audience size can only be estimated. A common model looks like this:

impressions for a placement in a time slot
  ≈ people passing the placement in that slot × dwell probability
    × sightline hit probability × visibility factor

The passing count comes from manual footfall surveys, city transportation data, and aggregated location-service data. Dwell probability describes the average time pedestrians or vehicles spend in front of the placement. Sightline hit probability depends on viewing distance and visible angle. The visibility factor accounts for weather, day/night, and obstructions.

The harder problem is de-duplication. One person may pass several placements in the same commercial district during the morning peak; simply summing impressions per placement would substantially overstate the number of people actually reached. Engineering practice typically combines the following:

• Grid-level population baseline: divide the city into grids and estimate an active population base for each.
• Repeat-pass factor: from trip-chain data, estimate the probability that the same population passes multiple placements within the same period.
• Frequency distribution fitting: fit the per-capita impression count with models such as the negative binomial distribution, then derive reach and average frequency from total impressions.

An illustrative calculation:

def estimate_reach(impressions_by_asset, grid_population, repeat_factor):
    """
    impressions_by_asset: {asset_id: impressions in the time slot}
    grid_population:      {grid_id: active population base}
    repeat_factor:        probability that the same population passes
                          multiple placements in one time slot (0~1)
    """
    total = sum(impressions_by_asset.values())
    unique_pass = total * (1 - repeat_factor)          # remove repeat passes
    base_pop = sum(grid_population.values())
    reach = min(unique_pass, base_pop)                 # reach cannot exceed population base
    frequency = total / reach if reach else 0.0        # average frequency
    return {"reach": reach, "frequency": round(frequency, 2)}

The data layer also has to solve consistency in external data fusion. Different cities and data sources use different time granularities and refresh frequencies. A shared “metric definition dictionary” is recommended, stating for each metric its definition, source, refresh cycle, and confidence interval, so that numbers in different reports do not contradict each other.

6. Delivery Layer: Context-Driven Programmatic Trading

Online programmatic advertising targets with user-level identifiers. OOH should instead shift to contextual targeting, using environmental signals such as time, location, weather, footfall, and nearby business types as targeting dimensions. A typical delivery request context:

{
  "request_id": "req-8f2c",
  "timestamp": "2025-06-12T08:05:00+08:00",
  "asset": {"asset_id": "OF-SH-0001", "asset_class": "street_furniture"},
  "geo_context": {"city": "Sample City", "district": "Sample District", "geo_level": "district"},
  "env_context": {
    "weather": "sunny",
    "temperature": 27,
    "crowd_flow_level": "high"
  },
  "available_slots": 12
}

The bidding side needs the following capabilities:

• Targeting rule engine: composition of and priority between conditions such as time, geography, audience tags, weather, and frequency caps.
• Multi-candidate ranking: a ranking score combining bid, creative match, and historical performance, rather than sorting by price alone.
• Frequency capping and rotation: cap how often the same population is exposed within the same commercial district; for multi-creative rotation on digital screens, keep weight allocation and on-air duration fair.
• Idempotency and retries: delivery decisions may be retried, but inventory deduction must be idempotent to avoid duplicate holds.

7. Measurement Layer: Impressions, Reach, and Verifiability

The measurement layer is the “last mile” of OOH digitalization and the part advertisers care about most. Core metrics include:

• Impressions: the number of views a placement can generate within its time slot.
• Reach: the de-duplicated count of individuals actually reached.
• Average frequency: impressions divided by reach.
• Viewability: the share of time a creative stays within an effective visible range.

Technically, the measurement layer has to do three things:

1. Cross-validate multiple data sources: join footfall data, screen playback logs, and campaign delivery records on “placement × time slice” and output a deviation rate.
2. Auditable records: write all delivery and playback records to append-only log storage, preserving original timestamps and hashed device identifiers so events can be re-verified after the fact.
3. Industry standards and third-party verification: an association or standards body leading a unified impression measurement methodology is a key step toward credible OOH advertising. Technically, a standard-version identifier field should be reserved so historical data can be recomputed under the definition that applied at the time.

A simplified consistency check:

def reconcile(play_logs, traffic_stats, impression_records, tolerance=0.05):
    """
    Check consistency among "screen playback logs", "footfall stats" and "impression records"
    play_logs:          {(asset_id, time_slot): play count}
    traffic_stats:      {(asset_id, time_slot): footfall index}
    impression_records: {(asset_id, time_slot): reported impressions}
    """
    anomalies = []
    for key, plays in play_logs.items():
        expected = estimate_impressions(traffic_stats.get(key, 0))
        reported = impression_records.get(key, 0)
        if expected == 0:
            continue
        deviation = abs(reported - expected) / expected
        if deviation > tolerance:
            anomalies.append({
                "key": key,
                "plays": plays,
                "expected": expected,
                "reported": reported,
                "deviation": round(deviation, 4)
            })
    return anomalies

8. Data Platform and Technical Foundations

Supporting the five layers requires a set of general-purpose cloud capabilities working together:

• Object storage: creative files, raw log archives, and third-party data snapshots, with lifecycle policies to reduce long-term storage cost.
• Distributed message queue: carries the delivery event stream and inventory delayed messages, providing peak shaving and asynchronous decoupling.
• Real-time stream computing: windowed aggregation over playback logs and footfall events to produce minute-level and hour-level metrics.
• Data warehouse and columnar analytics engine: offline modeling, reporting, and feature engineering for model training.
• Container platform: hosts delivery services, rule engines, and gateways, with elastic scaling to absorb morning-peak traffic.
• Logging and monitoring/alerting: unified collection of traces and business metrics, with alerts on inventory anomalies, delivery failure rates, and data lag.

When implementing this architecture on Baidu AI Cloud, teams can compose it from general-purpose capabilities such as object storage, messaging services, the container engine, and logging and monitoring; the final selection should be driven by load-test results and a cost model.

9. Privacy Compliance and Security Governance

OOH audience data comes from many sources, and compliance risk should not be underestimated. Recommended principles:

• Data minimization: collect only the dimensions required for a delivery decision, reducing geographic precision as needed.
• Aggregation thresholds: do not output individual-level conclusions for small-sample areas; for example, exclude a grid whose active population falls below a threshold from the calculation.
• De-identification: hash or irreversibly transform any device-related identifier before it enters the data platform.
• Retention limits: define an explicit retention period for raw detail data, archiving or deleting it automatically once expired.
• Cross-border transfer: for multinational operations, localize data and assess transfers according to local regulations.

10. Performance, Reliability, and Cost Optimization

• Tiered caching: cache the asset catalog, hot inventory data, and targeting rules separately, keeping read hit rates high.
• Read/write splitting: scheduling queries go to read replicas, inventory deductions to the primary, avoiding long transactions that block writers.
• Degradation strategy: if the data service is unavailable, the delivery layer falls back to a footfall model based on historical averages so that delivery is not interrupted.
• Hot/cold tiered storage: keep recent data at high-concurrency read capability and push historical data down to low-cost storage.
• Cost observability: build per-business-line dashboards of resource usage and cost per impression, so that scaling decisions can be tied to measurable benefit.

11. Rollout Roadmap and Common Pitfalls

A three-phase rollout is recommended:

1. Phase 1 — asset digitalization: complete the asset catalog, geocoding, and spec and visibility modeling, and connect creative management with content review.
2. Phase 2 — online inventory and scheduling: build the capacity calendar and reservation/release mechanisms, replacing manual scheduling.
3. Phase 3 — programmatic trading and closed-loop measurement: integrate contextual bidding, frequency capping, impression measurement, and third-party verification to form a “delivery — playback — measurement — settlement” loop.

Common pitfalls include: treating placement count as the core KPI while ignoring sellable inventory quality; footfall models without confidence intervals, which makes report numbers untrustworthy; inventory deduction that is not idempotent, leading to overselling under high concurrency; and measurement definitions that change frequently, making historical data impossible to compare across periods. The way to avoid these problems is to treat “explainability” as equally important as “high performance.”

12. Conclusion

The essence of OOH digitalization is converting placements, time slots, and footfall in the physical world into computable, tradable, and verifiable data assets. The asset catalog, capacity calendar, audience model, contextual bidding, and impression measurement are tightly interdependent: a missing definition in any one of them undermines the effect commitments made above it. For engineers, the real challenge is not how many new technology components to adopt, but whether a measurement system can be built that is consistently defined, auditable, and evolvable — which is the prerequisite for OOH moving from a brand-exposure tool to a measurable medium.