Viewcast On Demand methodology delta

What Viewcast On Demand shares with Viewcast Profiles (viewshed geometry, OTS/LTS model, traffic source, classification) and what differs (self-service asset creation, identifier semantics, tile surface scope).

Viewcast On Demand uses the same underlying measurement methodology as Viewcast Profiles. The viewshed geometry, traffic source, and impression model are identical. What differs is the delivery model, the identifier lifecycle, and the scope of the tile surface. This page enumerates what is shared and what is different so you can reason about when On Demand results are directly comparable to Profiles data.

For the full geometric and traffic model, see Viewcast Methodology.

What is the same

The following dimensions are identical between On Demand and Profiles:

  • Viewshed geometry: the viewshed for a given face is constructed the same way. Display size, elevation, orientation, area type (urbanicity), directionality of traffic, and maximum noting distance are all computed by the same model. An On Demand asset at the same anchor with the same display attributes produces the same viewshed as the corresponding Profiles face.
  • OTS/LTS model: Opportunity to See and Likelihood to See impressions are computed by the same noting-probability and attention-likelihood models. Circulation is derived from traffic within the viewshed weighted by directionality, then OTS applies the noting model and LTS applies the attention factor. The formulas are shared.
  • Traffic source: both products draw on the same Pathcast traffic volumes (roadside and place-based feeds). The placebased_version and roadside_version that identify the source feeds are the same across the two products for a given release.
  • Roadside / Place-Based classification: the classification field (Roadside or Place-Based) is governed by the same rules in both products. In On Demand it is set at asset creation and is immutable; in Profiles it is a property of the published record. The classification semantics are identical.

Because these dimensions are shared, an On Demand asset that reaches final_measured produces OTS and LTS values that are directly comparable to the corresponding Profiles record for the same face and forecast window.

What differs

  • Self-service asset creation: in Profiles, the inventory is published by Motionworks on a monthly cadence; you subscribe to the feed. In On Demand, you create individual assets through the API and purchase measurements on demand. You control which faces get measured and when.
  • viewshed_id minted at final_measured: in Profiles, every record carries a viewshed_id because all records are published. In On Demand, viewshed_id is absent until the asset reaches final_measured. Before that, the asset is identified only by its asset_id. See Asset lifecycle for the identifier semantics.
  • String identifiers: On Demand uses String identifiers for both asset_id (Supabase-issued) and viewshed_id (Motionworks-issued). Profiles records carry viewshed_id as a String as well, but the On Demand asset_id is a new identifier type that does not exist in the Profiles schema.
  • Tile surface scope: the Viewcast tile surface shows only public, final_measured, non-archived inventory. On Demand assets in draft or draft_measured state do not appear in tiles. An On Demand asset that reaches final_measured and is public will appear in tiles, but there are no per-org tilesets: the tile surface is a single shared inventory view, not a per-customer tileset. See the Viewcast Maptiles pages for the tile grant and rendering model.
  • No per-org tilesets: Profiles customers may be accustomed to thinking of their inventory as a private tileset. On Demand does not mint per-org tilesets. The tile surface is shared and filtered by the public/final/non-archived criteria. Access to private inventory is through the REST API, not tiles.

When results are comparable

An On Demand asset at final_measured with the same anchor and display attributes as a Profiles face will produce the same viewshed, the same circulation, and the same OTS/LTS values for the same forecast window. The two products differ in how you get to the result (self-service API vs. subscription feed), not in the measurement itself.

The one caveat is the forecast window: Profiles records carry period_start and period_end identifying the forecast window used. On Demand measurements use the current traffic source at the time the measurement is queued. If the traffic feeds have been updated between a Profiles release and an On Demand measurement, the absolute numbers may differ slightly even for the same face, because the underlying traffic data is from a different point in time. The methodology is the same; the input data vintage may differ.

What to read next


Did this page help you?