Checking access…
Checking access…
Behavioural intelligence signals derived from 180B+ monthly CDR events — mobility scores, engagement indices, and churn propensity — delivered to quantitative hedge funds as structured BigQuery feeds and REST APIs for systematic trading strategies.
Omni Alpha delivers per-ticker consumer intelligence reports — tracking how Verizon subscribers engage with a public company's digital product across 10 behavioural funnel stages. Signals are correlated against reported financial KPIs to give quantitative hedge funds a real-time window into consumer activity before earnings.
Avg active subscribers / day by funnel stage · Q1 2026 · ★ = Alpha Point signal
Accuracy = signal-to-actual QoQ correlation · Relevance = strategic importance to hedge fund clients
| Financial KPI | Scope | Accuracy | Relevance |
|---|---|---|---|
| Europe Revenue | EU | 44 | 86 |
| US Revenue | US | 98 | 64 |
| International Revenue | INTL | 33 | 90 |
| Total Revenue | ALL | 74 | 71 |
| Funnel Stage | Signal URLs | Alpha Pts | Avg / Day |
|---|---|---|---|
| New User Acquisition | 7 | 1 | 1.1K |
| Login | 12 | 2 | 132.8K |
| Open App | 24 | 5 | 188.5K |
| Marketing | 26 | 0 | 218.2K |
| User Engagement | 44 | 7 | 400.2K |
| Commerce Intent | 21 | 2 | 177.8K |
| Transactional Activity | 22 | 4 | 49.0K |
| Churn Risk | 17 | 0 | 11.8K |
| Total | 260 | 21 | — |
Each report covers 8 analytical sections — from raw engagement trends through to AI-generated narrative insights — updated on a rolling 90-day window per ticker.
Reports are delivered as interactive HTML — self-contained, no login required per file, shareable with portfolio managers and analysts.
Four source dataset families delivered via encrypted GCS transfer. Two are generated daily at high velocity (web traffic sessions and location pings), two are refreshed monthly (subscriber demographics and reference master tables). Field widths and byte measurements are empirically validated from source file analysis.
Every subscriber HTTP/HTTPS session routed through the operator network. Each row is one TCP session: a unique pairing of a privacy-preserving subscriber token, a radio cell site, a destination hostname, and the data volumes transferred. The highest-volume source — approximately 1.25 billion raw session rows per day before any aggregation. Delivered as Parquet via encrypted GCS transfer; Pub/Sub triggers downstream Dataflow processing within 15 minutes of file landing.
event_date is extracted from this field. Buckets into 5-minute and 15-minute windows in the aggregated downstream tables.{site_code}-{year}. Foreign key to the cell site reference table. Derives network-level geographic location without storing raw lat/lon at this table level.VALID_FROM_CELL BETWEEN valid_from AND valid_to for point-in-time accuracy.visited_host in the output datasets after domain normalisation (sub-domains collapsed to root domain).visited_download_data in output datasets. Typical range: 0 to ~50 MB per session.visited_upload_data in output datasets.visited_duration_total in output datasets; divide by 15 to derive session count.visited_event_count in output datasets.session_count, distinct_hosts and drops individual HOST_NAME per session — a 31× row reduction.Geo-timestamped location pings generated as subscriber devices transition between radio cell coverage areas. Each row is one location event with start and end coordinates. Raw volume is extremely high due to stationary ping repetition (~60–70% of raw pings are identical consecutive coordinates for stationary devices) — deduplication at source reduces ~8 billion raw pings/day to ~2.5 billion unique location events before storage. Uses the same TOKEN_ID hash as Source 01, enabling direct join between browsing behaviour and physical movement without any PII exposure. Parquet with delta-encoded coordinates (consecutive nearby values compressed 4–6×).
end_time - start_time gives dwell duration. For instantaneous pings (same second), start_time equals end_time — these are network-forced location updates rather than movement events.CELL_ID — enabling cell-level join across both datasets. Provides network-topology-based geographic anchor when GPS precision is not required. NULL only for Wi-Fi calling or IP-only sessions with no assigned radio cell.One row per active subscriber per monthly snapshot. Contains stable identity and socioeconomic attributes derived from billing records, supplemented by third-party income banding. Slowly changing — most fields are constant month-to-month. A Type-2 SCD (Slowly Changing Dimension) approach is used: changed records generate a new row, enabling historical attribute join accuracy. The join key to Sources 01 and 02 passes through an internal linkage layer — the raw subscriber number is never present in the analytical tables.
1=18–24 · 2=25–34 · 3=35–44 · 4=45–54 · 5=55–64 · 6=65+. Updated annually on subscriber anniversary. This field is the source of the age_band dimension in Dataset 02 (output).M · F · N (non-binary / not specified) · U (unknown). Approximately 3% of records are U. Treated as sensitive — access controlled by role-based permissions. Source of the gender dimension in Dataset 03 (output).postcode_area dimension in Dataset 04 (output).1=under £20K · 2=£20–35K · 3=£35–50K · 4=£50–75K · 5=£75–100K · 6=over £100K. ~12% of records are NULL (pre-pay subscribers with insufficient signals for income assignment). Refreshed quarterly by data vendor. Source of the income_bucket dimension in Dataset 05 (output).TOKEN_ID → [linkage hub] → Hashed_MSISDN. The linkage hub is never exposed in the analytical layer — downstream joins use a pre-joined view. SCD Type-2 adds ~5% row growth per month as subscriber attributes change.Static lookup tables providing geographic, network topology, and classification context. Updated monthly when cell site commissioning records change or area demographic data is refreshed. Small in volume but critical — they are the geographic spine connecting all other datasets. Two tables: the cell site master (linking radio cell IDs to physical locations and postcode areas) and the postcode area demographics table (linking postcode prefixes to population, median income, and urban/rural classification).
CELL_ID in Source 01 and cell_site_id in Source 02. Format: {site_code}-{year_commissioned}.4G-LTE · 5G-NR · 5G-mmWave · 3G-UMTS.SW, M, LS). Primary key. Links to subscriber demographics Home_Postcode prefix and cell site postcode_area.North West, Yorkshire and The Humber, London).1=Major Urban · 2=Large Urban · 3=Other Urban · 4=Significant Rural · 5=Rural 50 · 6=Rural 80.Source 01 CELL_ID → cell site master cell_id → postcode_area → postcode area demographics. This chain derives area-level demographic context from network topology alone — no subscriber-level location data required. Combined with the subscriber-level join via Hashed_MSISDN, it enables the full demographic segmentation seen in Datasets 02–06.Feeds arrive via dedicated GCS buckets with transfer encryption. Pub/Sub triggers downstream Dataflow jobs within 15 minutes of file landing. Output datasets are available T+3.
Full operational cost for running the daily BigQuery Notebook ETL pipeline on 16 TB/day of raw telco input (4 TB web + 12 TB foot traffic), materialising all 11 output datasets, and delivering to clients. Raw landing storage excluded — three stages costed: processing, BQ output storage, and data distribution.
Stacked by cost component · includes 5 rerun days/month · S3 egress at current slider setting · 15%/yr growth
Daily ETL reads 16 TB of raw telco feeds and materialises all 11 output tables. Each web table (DS01–DS05) scans the full 4 TB web corpus; each foot-traffic table (DS06–DS10) scans the full 12 TB FT corpus. Total effective scan: 5 × 4 TB + 5 × 12 TB = 80 TB/day. Panel (DS11) is a negligible aggregation. On-demand billing is per TB scanned — reserved slots pay a flat hourly rate regardless of scan volume.
| Pricing Model | Rate | Baseline/mo | 2026 · 6 mo | 2027 | 2028 | 2029 | 2030 | 5-Yr Total |
|---|---|---|---|---|---|---|---|---|
| On-demand $6.25/TB · no commitment · ~80 TB/day · 5×4 TB web + 5×12 TB FT · incl. 5 rerun days/mo |
$500/day | $17,500 | $105,000 | $241,500 | $277,725 | $319,384 | $367,291 | $1,310,900 |
| Enterprise Slots ★ 700 slots · 5 hr/day · $0.044/slot-hr · incl. 5 rerun days/mo · scales 15%/yr |
$154.00/day | $5,390 | $32,340 | $74,382 | $85,539 | $98,370 | $113,126 | $403,757 |
| Slots saving vs. on-demand ↓ | $12,110 | $72,660 | $167,118 | $192,186 | $221,014 | $254,165 | $907,143 | |
★ BQ Enterprise Edition at $0.044/slot/hour. 700 slots × 5 hr = $154.00/day — reserved capacity handles all 11 output tables with predictable throughput. Slots cost ($154/day) is 69% less than on-demand ($500/day) — reserved slots pay per slot-hour, not per TB scanned, saving ~$907K over 5 years. 5 additional rerun days/month included (35 compute-days/month = $5,390/month). Slot count scales at 15%/yr. S3 egress costed separately in Stage 3.
Daily output across all 11 tables totals ~80 GB/day uncompressed — web tables contribute ~60 GB, foot traffic ~20 GB. BQ Capacitor auto-compresses at ~3× to 27 GB/day stored. Active storage (≤6 months / 180 days) $0.02/GB/month; long-term (6–12 months) $0.01/GB/month. 12-month partition expiry auto-enforced.
| Compression Variant | Ratio | Daily Stored | 12-mo Volume | Active /mo (180 d) | Long-Term /mo (180 d) | Steady-State Total/mo |
|---|---|---|---|---|---|---|
| BQ Capacitor (auto) ★ Native columnar · zero export overhead |
~3× | 27 GB | 9.9 TB | 4,860 GB × $0.020 = $97.20 | 4,860 GB × $0.010 = $48.60 | $145.80 |
| Parquet / Snappy GCS or S3 export — daily transfer overhead |
~5× | 16 GB | 5.8 TB | S3 Standard: 5,800 GB × $0.023/GB = $133/mo | $133 + $41 egress | |
| ZSTD-9 GCS or S3 export · best ratio · slower decode |
~8× | 10 GB | 3.7 TB | S3 Standard: 3,650 GB × $0.023/GB = $84/mo | $84 + $26 egress | |
| BQ Capacitor Storage | 2026 · 6 mo | 2027 | 2028 | 2029 | 2030 | 5-Yr Total |
|---|---|---|---|---|---|---|
| Active storage (<6 months / 180 days) | $340 | $940 | $1,540 | $1,770 | $2,040 | $6,630 |
| Long-term storage (6–12 months) | $0 | $760 | $700 | $810 | $930 | $3,200 |
| Total BQ Storage | $340 | $1,700 | $2,240 | $2,580 | $2,970 | $9,830 |
Storage grows at 15%/yr as subscriber panel and domain/POI coverage expand. Long-term pricing activates automatically after 180 days. Data beyond 12 months is purged via BQ partition expiry — no manual cleanup needed.
Output datasets are pushed daily to a client-owned S3 bucket via GCP Storage Transfer Service. Two cost components: GCP → internet egress at $0.085/GB and S3 storage for the 24-month rolling Parquet archive at $0.023/GB/month. Use the slider to model different daily output volumes — from a few GB of filtered signals up to half a TB of full-universe exports.
| Cost Component | 2026 · 6 mo | 2027 | 2028 | 2029 | 2030 | 5-Yr Total |
|---|---|---|---|---|---|---|
| Processing — On-demand | $105,000 | $241,500 | $277,725 | $319,384 | $367,291 | $1,310,900 |
| Processing — Enterprise Slots | $32,340 | $74,382 | $85,539 | $98,370 | $113,126 | $403,757 |
| BQ Output Storage (Capacitor) | $340 | $1,700 | $2,240 | $2,580 | $2,970 | $9,830 |
| Distribution — S3 Daily Push (slider-driven) | — | — | — | — | — | — |
| On-demand + S3 | — | — | — | — | — | — |
| Enterprise Slots + S3 Delivery ★ | — | — | — | — | — | — |
All costs grow at 15%/yr. Compute rows include 5 rerun days/month. S3 delivery row is driven by the slider in Stage 3 — adjust there to see 5-year impact. At 700 slots · 5 hr/day ($154/day), Enterprise Slots saves ~$907K vs on-demand ($500/day) over 5 years — paying per slot-hour is significantly more efficient than per-TB billing for this 80 TB/day workload.
On-demand vs Enterprise Slots · includes BQ output storage + S3 delivery at current slider setting
Five pre-computed BigQuery datasets covering domain-level engagement enriched with funnel signals, and three demographic cuts (age, gender, postcode) plus a panel coverage reference. All datasets are partitioned by date, available T+3, and delivered as read-only shared views — no ETL work required on the client side.
The primary output dataset. One row per domain per day — aggregated from raw URL-level telco records and enriched with funnel stage classification and Alpha Point flags. This is the table that drives the daily visitor trend chart, Signal Breakdown, and KPI Correlation sections of every Alpha Signal Report. It combines raw engagement metrics (visitors, hits, data volume, duration) with analytical overlays assigned by the signal classification engine.
visited_date in every query to avoid full-table scans.fanduel.com, betfair.com). Sub-domains are collapsed to their root domain during ETL. Primary join key to the ticker-to-domain mapping used in report generation.new_user_acquisition · login · open_app · marketing · user_engagement · commerce_intent · transactional_activity · loyalty_activity · churn_risk · unclassified. A single domain may appear under multiple stages on the same date when different URL paths within it are classified differently — aggregate to domain + date to get totals across all stages.SUM(visitor_total) across dates to derive total active users over a window, or SUM(visitor_total) / COUNT(DISTINCT visited_date) for daily averages.visited_event_count / visitor_total ratio indicates interactive, multi-step engagement rather than passive single-page visits. Used in: SUM(visited_event_count) for total hits; divided by visitor_total for hits-per-user.SUM(visited_download_data) / SUM(visitor_total) / 1024.visited_upload_data / visited_download_data ratio as a directional indicator of purchase intent.visitor_total for average minutes per user. Divide by 15 to derive estimated session count using the standard 15-minute inactivity threshold: SUM(visited_duration_total) / 15 = estimated sessions.visitor_total across all signal_stage values for a given visited_date + visited_host gives the all-stages domain total used in the daily trend chart. The Signal Breakdown table in the report is produced by grouping this dataset by signal_stage.The enriched domain engagement metrics from Dataset 01, further broken down by subscriber age band derived from billing records. Age cohort analysis reveals whether new user acquisition is skewing younger or older quarter-on-quarter, which demographic drives transactional volume, and whether churn risk is concentrated in a specific age group. For regulated sectors (sports betting, financial services), the 18–24 cohort split is also material for compliance monitoring.
18_24 · 25_34 · 35_44 · 45_54 · 55_64 · 65_plus · unknown. The 25–44 band consistently generates the highest upload volume on commerce-classified domains, correlating with peak transaction frequency. The 55–64 band shows the highest duration per visitor, suggesting habitual, unhurried engagement.age_band values for a given date, host, and stage reproduces the visitor_total from Dataset 01.visitor_total for avg mins per user; divide by 15 for estimated sessions. The 55+ cohort consistently shows the highest duration-per-visitor despite lower raw visitor counts.age_band values for a given visited_date + visited_host + signal_stage triple reproduces the corresponding row in Dataset 01.The enriched domain engagement dataset cut by subscriber gender, derived from billing records. Gender-split analysis is particularly material for consumer brands where the product audience composition is a leading indicator of revenue mix — for example, a sustained shift in the male-to-female ratio within the commerce intent stage often precedes changes in reported product revenue for sports betting operators. Also used to validate that product reach is broadening or narrowing across acquisition campaigns.
M (male), F (female), U (unknown / not provided). The U bucket is non-trivial — typically 10–15% of the subscriber base — and should be excluded from ratio calculations or treated as a separate cohort. For sports betting domains the M share of transactional_activity stage consistently exceeds its share of user_engagement, indicating proportionally higher conversion from engagement to transaction among male subscribers.visitor_total for avg minutes per user.M + F + U rows for a given date, host, and stage reproduces the Dataset 01 totals. Exclude gender = 'U' when computing M:F ratios to avoid skewing the proportion.The enriched domain engagement dataset cut by subscriber home postcode area, derived from billing address (not location at time of visit). Geographic segmentation enables spatial concentration analysis — identifying whether consumer activity is nationally distributed or concentrated in specific regions. Regional signals frequently lead national KPI movements: a sustained uplift in transactional upload volume from a specific postcode area often reflects a regional promotional campaign or localised competitor withdrawal before it is visible in aggregate national metrics.
SW, M, LS, B, G). Represents approximately 120 distinct postcode areas covering all of Great Britain and Northern Ireland. This is the subscriber's registered home area — it is static per subscriber and does not change with physical movement. London postcode areas (EC, WC, E, N, NW, SE, SW, W) are retained as separate codes and can be grouped for London-wide analysis. NW England (M, OL, SK) and Yorkshire (LS, BD, HX) consistently over-index for sports betting relative to subscriber base share.transactional_activity domains frequently pre-date regional promotional announcements by 5–10 days.visitor_total for avg minutes per user.The enriched domain engagement dataset cut by subscriber estimated household income bucket, derived from a propensity model that combines billing plan tier, billing postcode area median income, and device class. Income segmentation enables spend-capacity analysis without transactional data — identifying whether high-value engagement (commerce intent, transactional activity) is concentrated among higher-income cohorts, and how income-sensitive a product's audience acquisition is across quarters. For consumer financial services and premium subscription products, income bucket is the most commercially actionable demographic dimension in the dataset.
under_20k · 20k_35k · 35k_50k · 50k_75k · 75k_100k · over_100k · unknown. Buckets reflect gross annual household income in GBP. The unknown bucket covers subscribers where insufficient signals exist to assign a bucket with confidence — typically pre-pay subscribers with no device data. The 50k_75k and over_100k buckets consistently over-index for transactional activity on sports betting and financial services domains relative to their share of the total panel.income_bucket values for a given date, host, and stage reproduces the visitor_total from Dataset 01.over_100k bucket consistently shows the highest upload-per-visitor ratio on transactional_activity classified domains.visitor_total for avg minutes per user; divide by 15 for estimated sessions using the standard telco inactivity threshold.income_bucket values for a given visited_date + visited_host + signal_stage reproduces the corresponding row in Dataset 01. Income bucket assignment is a propensity model estimate — treat as directional rather than precise. Use alongside Dataset 11 panel coverage fields to compute income-cohort penetration rates.The primary foot traffic output — one row per Point of Interest per day. Aggregated from raw location ping data, this dataset measures how many distinct subscribers physically visited a given POI on a given day and for how long. Where fewer than 50 unique visitors are observed for a segment, the value is suppressed to −1 to protect individual privacy. This is the base table from which all demographic and geographic foot traffic views are derived. Delivered daily including weekends and public holidays.
YYYYMMDD (e.g. 20250901). Partition key for all foot traffic queries. Daily granularity — the time period covers midnight to midnight local time. Always filter on this field to avoid full-table scans.Y = confirmed winner POI (subscriber's primary dwell location that day); otherwise the field contains the POI's rank position among up to 5 candidate winners. Used to distinguish confirmed footfall from proximity signals in dense urban environments where a subscriber's device pings may be attributed to multiple adjacent POIs.Visitor_Total for average seconds-per-visitor (dwell time). Note: this field is in seconds — unlike the web traffic equivalent which is in minutes. Dwell time is the primary intensity signal for physical location engagement: high dwell with moderate visitor counts indicates a destination POI (e.g. restaurant, gym); low dwell with high visitor counts indicates a transactional or transit POI (e.g. convenience store, transport hub).−1 (N/A) to prevent individual identification. The primary volume signal — directly analogous to daily footfall count. Null-safe aggregations should treat −1 values as suppressed, not as negative counts.Visitor_Total across all POIs for a given brand (using the chain affiliation from the POI Reference table) produces brand-level daily footfall. Compare against Dataset 01 (Enriched Domain Engagement) on the same date to measure online-to-offline correlation — a rising digital engagement signal ahead of sustained footfall uplift is a leading indicator for physical sales performance.Daily POI footfall further broken down by visitor age band. Enables cohort-level analysis of which age groups are physically visiting specific locations — critical for retail formats targeting specific demographics, for validating the age composition of a brand's physical audience versus its digital audience (Dataset 02), and for identifying whether demographic mix shifts are occurring at the store or venue level before they aggregate into reported earnings.
YYYYMMDD.1 = 18–24 · 2 = 25–34 · 3 = 35–54 · 4 = 55–75+ · 5 = unknown. Note: the 35–54 band is wider than the equivalent web traffic age bands (35–44 and 45–54) — account for this difference when comparing physical vs. digital audience age composition across datasets.Visitor_Total for average dwell per visitor. The 25–34 and 35–54 cohorts typically show the longest dwell times for food-and-beverage and leisure POIs; the 18–24 cohort shows the highest visit frequency with shorter average dwell.−1 when fewer than 50 subscribers are in the segment for privacy protection. Summing across all age bands for a given POI and date reproduces the Visitor_Total in Dataset 06 (excluding unknowns).Daily POI footfall split by visitor gender. Physical gender composition at a store or venue often differs from the brand's digital audience mix — a brand may have a predominantly male online audience (as measured in Dataset 03) but a more balanced or female-leaning physical visitor base. Tracking gender composition of physical visits alongside digital engagement signals enables detection of audience mix shifts at individual POI level before they appear in aggregated trading metrics.
YYYYMMDD.1 = Male · 2 = Female · 3 = Unknown. The unknown bucket typically represents 10–15% of the subscriber panel and should be excluded from M:F ratio calculations. When comparing to Dataset 03 (web gender), the same encoding applies: align on codes 1 and 2 and exclude code 3 from ratio analysis.−1 when fewer than 50 in segment. Summing codes 1 + 2 + 3 reproduces Dataset 06's Visitor_Total for the same POI and date.Daily POI footfall broken down by visitor estimated household income range — a third-party appended attribute derived from billing postcode median income and subscriber plan tier. Income segmentation of physical visits is particularly valuable for premium retail, financial services branches, and hospitality venues where spend capacity directly predicts transaction value. Compare with Dataset 05 (web income) to identify income cohorts that engage digitally but do not convert to physical visits — an indicator of conversion friction or geographic accessibility barriers.
YYYYMMDD.1 = under £25K · 2 = £25K–£74,999 · 3 = £75K–£149,999 · 4 = £150K–£249,999 · 5 = £250K+ · 6 = unknown. Income is a third-party appended attribute — treat as directional rather than precise. The unknown bucket (code 6) covers subscribers without sufficient billing data for income assignment; typically higher among pre-pay subscribers.−1 when fewer than 50 in segment. Summing across all income codes reproduces Dataset 06's total.Daily POI footfall broken down by visitor home postcode area — where the subscriber lives, not where they are visiting from at the moment of the visit. This distinction matters: a retail store in Manchester will draw visitors from a wide range of home postcode areas; the catchment map produced by this dataset shows the geographic reach of that physical location. Cross-referencing home postcode area with the store's own postcode area quantifies the proportion of local versus out-of-area visitors — a valuable input to site selection, marketing geo-targeting, and competitor proximity analysis.
YYYYMMDD.M, LS, SW). Derived from billing address — static per subscriber, not the location at time of visit. Used to construct visitor catchment maps: which postcode areas contribute the most footfall to a given POI. Cross-reference with the Postcode Area Demographics reference table for population-normalised penetration rates.−1 when fewer than 50 in segment. Summing across all postcode areas for a given POI and date reproduces Dataset 06's total. To compute catchment share: Visitor_Total (postcode X) / Visitor_Total (all postcodes).M (Manchester) at a London POI is a Manchester resident who travelled to London — not someone whose device was in Manchester at the time. This enables genuine catchment area analysis rather than proximity analysis. For cross-brand comparisons, normalise by the panel count for each postcode area from Dataset 11 (Panel Coverage & Size).A daily reference dataset recording the size and demographic composition of the subscriber panel used to compute Datasets 01–05. Panel size is not constant — subscribers join and leave the network daily, and the active panel fluctuates with data collection windows. This dataset is essential for normalising visitor metrics across time: a raw visitor count increase from one month to the next is only meaningful when benchmarked against the panel size in each period. Coverage percentage (active panel ÷ total panel) is the primary data quality indicator for any given date.
visited_date to normalise engagement metrics against panel coverage for that specific day.panel_size_active / panel_size_total × 100. The primary data quality flag for a given date. Days where coverage_pct falls below a threshold (typically 55%) indicate incomplete data collection and the corresponding rows in engagement datasets should be treated as unreliable for absolute visitor comparisons. Trend analysis should apply a coverage filter before computing period-over-period changes.visitor_total (gender=M) / panel_male gives the share of male subscribers who visited a given domain on a given day.visitor_total (income_bucket='under_20k') / panel_income_under_20k.visitor_total (age_band=18_24) / panel_age_18_24 — which normalise for the fact that some age bands are larger than others in the subscriber base.coverage_pct >= 55 before running trend models. For income-cohort penetration rates, divide the income visitor total from Dataset 05 (web) or Dataset 09 (foot traffic) by the corresponding panel_income_* field for the same date.Plain-English guide to all cost models, assumptions, strategies, and caveats across every product page.