Skip to main content
wdm-agency-v1

This is the document every WilDi Maps agency report, invoice and CSV cites. It is published in full, unedited, so a claim in a report can always be checked against the rule that produced it.

← Back to the short version

WilDi Maps Measurement Methodology — wdm-agency-v1

This is the document every agency report, invoice and CSV cites as wdm-agency-v1. It says what we record, how each number is calculated, what each number proves, what it does not prove, and what we leave out on purpose. It is written for a media buyer who has to explain the report to a client, not for an engineer.

Last verified: 2026-08-22. Measurement rule versions in force: v2 for every event written on or after 2026-08-22; v1 for earlier rows (differences are listed in section 13).


1. What WilDi Maps is, in one sentence

WilDi Maps is a location-based advertising channel that reaches opted-in drivers based on their movement through a defined geography, validates each delivery at the event level, and can connect a delivery to a later visit under a separately defined rule. We do not describe ourselves as out-of-home and we do not translate deliveries into impressions.


2. Definitions

Every metric below is tagged with its class. Agencies should keep the classes separate in their own reporting.

TermDefinitionClass
Verified DeliveryOne campaign delivery event that passed every production eligibility, campaign-selection, validation, duplicate and invalid-event rule in section 4, and was claimed by the driver. It is deduplicated. It is not an impression and does not prove attention.Observed
Unique DriverA privacy-safe pseudonymous driver who received at least one Verified Delivery in the reporting window. Pseudonyms are per campaign; the same driver has a different key in another advertiser's report.Observed
Delivered FrequencyVerified Deliveries ÷ Unique Drivers for the window. Always reported with its distribution (median, p75, p90, p95, max and a 1 / 2 / 3 / 4–5 / 6–10 / 11+ table), because an average hides heavy delivery to a few drivers.Calculated
Verified VisitA driver who previously received a delivery later enters the advertiser's location hex and satisfies the dwell and validation rule in section 10, inside the 14-day attribution window.Attributed
Attributed OutcomeAn outcome (visit, redemption) associated with a prior delivery under the attribution rule. Association is not causation.Attributed
Incremental OutcomeAn outcome that would not have happened without the advertising. We do not claim this for any campaign unless a separately designed study supports it. No WilDi Maps report today makes an incrementality claim.Causal (not claimed)
NTE CeilingThe not-to-exceed amount the agency authorized. We bill only valid billable delivery actually fulfilled, never above the ceiling. Unused authorization expires and is never owed.Commercial

3. Who is eligible, and what the driver experiences

A driver is an adult who installed the WilDi Maps app, opted in to location sharing and to receiving advertising, and is moving through a targeted geography. Delivery is gated on motion evidence so that ads are not delivered to someone walking, cycling or stationary, and the app itself is designed to be heard, not read, while driving: the delivery arrives as a notification; the driver interacts with it later, when stopped, by claiming it. The claim is the billable moment precisely because it is the human action, not the push. See the driver-safety section of /for-agencies.


4. What qualifies a Verified Delivery

Each delivery is one row in an append-only event log. Rows are never edited or deleted; corrections are new rows. A delivery becomes billable only after the validator applies these rules, in this order, and each one is recorded on the row with the rule version:

  1. Test traffic — deliveries involving a WilDi Maps team device, founder account or staff account are marked invalid_test and never billed or reported to customers.
  2. Claimed — an unclaimed delivery is not_claimed; it is never billed. Claims made before the send, or more than 30 days after it, are invalid_stale.
  3. Mock location — the device reported a mock-location provider at the fix: invalid_spoofed.
  4. GPS accuracy — no accuracy reported, or accuracy worse than 150 m: invalid_geofence. Missing evidence fails closed.
  5. Geofence containment — the fix's H3 cell (resolution 12, roughly 9 m across) must fall inside the campaign's targeting snapshot — the exact cells the campaign targeted at the moment of delivery (zone hex plus its one-ring of neighbours; corridor polyline buffered by 0.15 mi; background target hex, or "everywhere"). Outside, or no cell recorded: invalid_geofence.
  6. Duplicates — one surface per message id; a second delivery of the same message to the same device is invalid_duplicate.
  7. Frequency cap / cooldown / budget / speed gate — suppressions happen before delivery and are logged as eligibility outcomes (section 5). A delivery that slipped through and is later found to violate one is marked invalid_frequency_cap, invalid_speed_gate or invalid_budget_exhausted.

Only billable rows count as Verified Deliveries. Every invalid reason is reported by count in the agency report's exclusions block.

Rendered is not seen. The event log keeps four timestamps: sent_at (handed to the push service), received_at (device acknowledged), rendered_at (device asserts it displayed the notification) and claimed_at (the driver acted). rendered_at is the device's assertion; it is not proof of attention, and no report treats it as one.


5. Evidence captured per event

For each delivery we store, at the time it happens: campaign and targeting-snapshot ids; pseudonymous driver key and hashed device id; the four timestamps; the device's own clock and timezone offset; position, GPS accuracy, location provider, speed, heading, altitude, activity type and confidence where the OS supplies them; the H3 cell; the targeted asset; inventory type; push message id; app version, platform, OS version, network type; whether the device says it showed its own notification; a snapshot of the device's recent fixes (up to 30, about 7.5 minutes); and the validation status, reason and rule version.

For each eligibility evaluation — delivered or not — we store the outcome and reason (frequency cap, cooldown, budget exhausted, speed gate, paused campaign, outside flight, consent missing, duplicate suppressed, no matching campaign), with the same telemetry. This is the reach denominator and it is the one table that cannot be reconstructed later.

For each distance claim from a device we store the anti-fraud verdict (client verified, capped, clamped, server computed, mocked, implausible speed, no data) together with the client miles, the server-recomputed miles and the motion-gate reason.

Fields that can only be captured at write time — position, accuracy, mock flag, speed, the targeting snapshot, device clock — are captured at write time. Nothing in a report is back-filled from memory.


6. Exclusions applied to every customer- or agency-facing report

  • Deliveries, visits, claims and wins involving WilDi Maps, Inc, WILDI ONE LLC, any @wildimaps.com account, staff test accounts, and founders' own driver accounts (maintained in one registry, applied at query time).
  • Team and test devices (is_test_traffic).
  • Pool-bounty payouts (a bounty is a driver reward, not a delivery).
  • Every invalid or pending delivery (section 4); they appear only as counts in the exclusions block.

Reports state "customer accounts only" in the footer when these apply. Internal dashboards may still show founder data.


7. Unique Drivers and privacy

The driver key in any agency artefact is an HMAC pseudonym salted per campaign. It cannot be reversed and cannot be joined across advertisers. Agency CSVs carry no name, email, raw device id, exact coordinate or exact timestamp; timestamps are truncated to the hour and locations are coarsened to H3 resolution 6 (about 36 km² cells). Any cut of the data with fewer than five distinct drivers is refused rather than released. Exact-grain data exists only in the internal variant, which is never sent outside WilDi Maps.


8. Geography and daypart

Geographic rollups count Verified Deliveries per resolution-6 cell and per targeted asset (zone or corridor name). Rows written before 2026-08-22 did not record an H3 cell; for those the cell is derived from the recorded position and labelled derived rather than recorded.

Dayparts are computed in the advertiser's reporting timezone from sent_at: early (00–06), morning (06–10), midday (10–14), afternoon (14–18), evening (18–22), late (22–24), split weekday / weekend.


9. Pacing and the NTE ceiling

The NTE is enforced at delivery time: for postpaid agency accounts every delivery reserves its rate against the ceiling before the message is created, and a delivery that would exceed the ceiling is refused. Billing therefore never exceeds the ceiling. Unused authorization expires and is never owed.

Pacing is snapshotted once a day per active campaign: deliveries sent that day, the spend those deliveries produced, and a forecast equal to the NTE (or campaign budget) spread evenly across the flight days (30 days assumed when the flight has no end date; the basis is recorded on the snapshot). A day under 50% of pace from the third flight day onward sets an underdelivery flag, which triggers a proactive notice to the agency contact — material underdelivery is communicated during the flight, not discovered in the final report. Pacing is a delivery-dated signal; the money it eventually produces lands on the claim date, so recent days under-report spend until claims arrive.


10. Verified Visits

A visit is recorded when a driver's device enters the advertiser location's hex (resolution 10, about 150 m across) and remains, with the dwell duration logged honestly — a stay that ends because tracking stopped is marked as a lower bound. A Verified Visit in a campaign report is such a visit by a driver who received a Verified Delivery for that campaign in the preceding 14 days. Unique visitors, visit rate (unique visitors ÷ unique drivers) and cost per Verified Visit are reported from that set. These are attributed outcomes: the visit followed the delivery inside the window. They are not evidence that the delivery caused the visit.

Redemptions and at-the-counter outcomes are reported only from staff-confirmed records and only when they exist; revenue and ROAS are not reported unless the advertiser supplies reliable transaction data.


11. Clocks

Different questions need different clocks, and every report prints the one it uses:

  • Delivery counts cut on sent_at (UTC) — when the ad was handed to the device.
  • Billable amounts cut on claimed_at — money moves when the driver claims, which can be days after delivery.
  • Agency billing periods cut on the reservation ledger's created_at — the moment the NTE was reserved for a delivery.
  • Visits cut on the hex entry time.

A delivery sent on the last day of a flight and claimed a week later appears in the flight's delivery count and in the following period's billing. Reconciliation (section 12) is where the two meet.


12. Reconciliation, reporting cadence and invoicing

Live figures are preliminary. Final reconciliation — claims landed, validation complete, exclusions applied, pacing closed — completes within 5 business days after the flight ends. The final report is issued from a frozen, immutable run, and the invoice is generated only from that run; the invoice number, rates and line items cannot change afterwards. Invoices itemize each inventory type separately (deliveries × locked rate). Invalid and duplicate deliveries are never billed. Disputes raised within the payment term are resolved against the event log.

During a flight the agency receives launch confirmation, a weekly pacing summary (NTE, billable to date, pace, unique drivers, verified deliveries, frequency, invalid counts), and any underdelivery notice as it occurs. Verified Visits are shown live but flagged preliminary until the attribution window closes.


13. Known limits and sampling (read before comparing periods)

  • Rows before 2026-08-22 (rule v1) were validated without the geofence containment test: the targeting snapshot and the event cell were not recorded, so containment could not run. Those rows are labelled geofence_tested = false in every export. Rows from 2026-08-22 (rule v2) are fully tested. Do not compare invalid-rate figures across the boundary.
  • Eligibility sampling. The one eligibility outcome that fires on almost every fix — "no matching campaign" — is stored at a 5% sample; the sample rate is stored on each row, so denominators are recoverable. All other outcomes are stored in full.
  • Device telemetry (app version, platform, OS, network, device clock, provider, altitude, activity) is present only for deliveries from app 1.1.3 and later; earlier builds did not send it.
  • Redemption outcomes and approach trails for location pools exist only for app 1.1.2 and later.
  • Per-fix history between deliveries is not stored beyond the 30-fix snapshot attached to each delivery (see section 14).
  • Reach sampling of drivers near zones and corridors was starved before 2026-08-22 by a client/server payload mismatch; reach denominators for those products start on that date.

14. Deliberate discards

Collected by the app or server and intentionally not stored, with the reason:

ItemReason
Every GPS fix between deliveriesVolume. The 30-fix snapshot on each delivery, the sampled eligibility log and the distance verdicts carry the evidence a methodology question needs.
Altitude as a validation inputStored when sent, never used in a rule — consumer GPS altitude is too noisy to gate on.
Speed accuracyNo consumer; not sent.
Full position list per pool heartbeatThe server keeps one fix per heartbeat (every 30 s); the approach trail already covers the drive in.
Real names and emails in any agency artefactNever — the pseudonym is the only driver identity outside WilDi Maps.

15. Claims we make, qualify, and never make

We make: Verified Deliveries are logged, deduplicated, validated, geofence-tested (rule v2) and individually auditable. Unique Drivers and frequency are observed platform metrics. Billing never exceeds the NTE. Invalid delivery is never billed.

We qualify: Verified Visits are attributed within a 14-day window and are not incremental. Pacing is delivery-dated; spend lands on claim. Rendered means displayed by the device, not seen.

We never make: impression or attention equivalence; incrementality from attribution; audience-size claims beyond the eligible-driver count we can show; benchmarks for ideal frequency, visit rate, cost per visit or ROAS from a single campaign; any delivery count that includes founder, staff or test traffic.


16. Change log

  • wdm-agency-v1 / rule v2 (2026-08-22) — targeting snapshots and event cells recorded on every event, so containment runs; mock-location flag threaded from the device; device telemetry, push id, eligibility link, test-traffic flag, distance verdicts, daily odometer, pool mock evidence stored; pacing snapshots fixed for open-ended flights; itemized agency CSV and restructured agency report; margin economics removed from every agency artefact.
  • rule v1 (2026-08-15) — event logging introduced; GPS accuracy and speed pass-through fixed 2026-08-21.