Checking access…
Checking access…
Omni Insights is a closed-environment custom analytics platform — bringing Web Traffic, Foot Traffic, and Demographics together inside a secure GCP perimeter, then running inferencing and bespoke analytics entirely within that boundary. No data leaves the project; clients receive curated, controlled outputs via BigQuery dataset sharing.
Omni Insights is not a dashboard product — it is a controlled analytics environment. Three datasets (Web Traffic, Foot Traffic, Demographics) are brought together inside a VPC-SC GCP perimeter, fused at the subscriber level, and then subject to any combination of custom SQL analytics, ML inferencing, and audience modelling. Results are delivered as curated BigQuery datasets — no raw data ever leaves the project boundary.
All three source datasets — Web Traffic, Foot Traffic, and Demographics — are ingested into and remain within a single GCP project. Inferencing models run inside BigQuery ML or Vertex AI within the same perimeter. Client teams never access raw feeds; they receive only the controlled analytical outputs published to a shared BigQuery dataset. This architecture satisfies data residency requirements and eliminates third-party egress risk.
date_partition reduces effective scan by ~65%, making large cross-dataset joins cost-efficient. Full SQL flexibility — no schema lock-in.Two high-velocity daily datasets are joined to produce cross-channel insights. Web Traffic captures online intent; Footfall captures physical presence. Linked by subscriber identifier, together they reveal the consumer journey end-to-end.
date_partition is extracted from this field. Used for 5-minute and 15-minute time-window bucketing in downstream aggregations.news.bbc.co.uk → bbc.co.uk). High cardinality: 500K+ unique domains per day; dictionary-encoded in Parquet.ECOMMERCE, NEWS, SPORTS, FINANCE). Mapped from a 500K-domain lookup table refreshed monthly. NULL for uncategorised or newly registered domains (~4% of sessions).duration_total in downstream output tables.{site_code}-{year_commissioned}. Foreign key to the cell site master table, enabling network-topology geographic resolution (postcode area, lat/lon of antenna) without storing subscriber GPS directly.0 = background sync with no user interaction; 1 = single page load; 10+ = active browsing or app polling (social feeds, streaming buffers). NULL for sessions predating event-count instrumentation.mobile · tablet · fixed · iot. ~2% of sessions return unknown where UA is absent or obfuscated.session_ts. Used for BigQuery partition pruning and rolling-window expiry. Historical data beyond the configured retention window is automatically dropped as new partitions arrive.session_count and distinct_domains (drops individual domain rows — 30× row reduction) → 15-min rollup per cell_id only, enabling k≥5 anonymised BI reporting. Aggregated tables reside in Nearline and Standard tiers respectively.end_ts − ping_ts gives actual time-at-location in seconds. For instantaneous network-forced pings, end_ts equals ping_ts. NULL for the most recent open ping (device still present).cell_id — enabling direct cell-level join across both datasets. Provides a network-topology geographic anchor when GPS precision is unavailable. NULL only for Wi-Fi calling or IP-only sessions with no assigned radio cell.retail · transport · leisure · health · hospitality · office. Derived from the POI master table; NULL where poi_id is NULL. Used as the primary dimension for footfall segmentation and cross-channel attribution queries.FLOOR((end_ts − ping_ts) / 60). 0 = transit ping (device passed through without dwelling); NULL = no POI match. Winsorised at 480 minutes (8 hours) to suppress overnight device misclassification.ping_ts. Used for BigQuery partition pruning and rolling-window expiry. Historical data beyond the configured retention window is automatically dropped as new partitions arrive.Both datasets share subscriber_id as the linkage key. Each analysis scans a configurable rolling window (1–6 months) of Parquet-compressed data in BigQuery, applying partition pruning on date_partition. The join produces subscriber-level cross-channel profiles combining online category interest with physical POI visits.
Cost is purely BigQuery On-Demand compute — you are querying data that already lives in the ingestion pipeline. No separate storage is charged. Each analysis scans Web + Foot Traffic for the chosen data window; cost scales with how much data you look back over and how often you run.
For ad-hoc cross-channel analytics, BigQuery On-Demand (pay-per-TB-scanned) is the right choice. The raw data already exists in the ingestion pipeline — no duplicate storage cost. Zero idle slot cost between runs. BQ's columnar Parquet format with partition pruning on date_partition reduces effective scan by ~65%, keeping large cross-dataset joins cost-efficient.
BQ On-Demand query compute (teal) + output dataset storage (purple) · input data carries no storage cost
Cost is entirely query-driven — scales with data window size and analysis frequency. 2026 covers Jul–Dec only (6 months).
| Year | Months | Analyses | Query Compute | Output Storage | Total |
|---|---|---|---|---|---|
| Total (5yr) | 54 | — | — | — | — |
date_partition · 15% join shuffle overhead included · input data has no storage charge (already in ingestion pipeline) · output dataset: $0.02/GB/month active, $0.01/GB/month after 90 days. Costs exclude BQ result egress (typically <$50/year).Plain-English guide to all cost models, assumptions, strategies, and caveats across every product page.