Welcome to Part 1 of the DDP Day session on mobile location data for transport. Over the next 45 minutes we cover what these data are, what they can and cannot tell us about how people move, who the two main DDP-listed vendors are, and the privacy rules anyone touching the data needs from day one. If you leave after this hour, you should be able to read a colleague’s mobility brief without being misled by it, scope a credible internal proposal, and recognise the red lines that turn a useful analysis into a reputational problem. No code, no terminal. Part 2 is the hands-on; staying is optional and nothing in Part 2 is a prerequisite for what you learn here.
| # | Section | Time | Key takeaway |
|---|---|---|---|
| 1 | Mobile location data 101 | ~10 min | A “ping” is one row in a giant spreadsheet — a device, a place, a moment. The data come from tracking code inside free apps, not from telecom operators. |
| 2 | Use cases for transport | ~8 min | Best for relative changes, OD flows, and shocks. Indicative, not a replacement for surveys or counts. |
| 3 | Data providers | ~12 min | Irys and Quadrant are both on the DDP partner list and both accessed through the Partnership Portal. They differ in geography, scale, and schema, not in the basic shape of the data. |
| 4 | Privacy, ethics, responsible use | ~10 min | Four points re-identify 95% of people. Removing the device ID is not anonymisation. Aggregate (k ≥ 15), strip sensitive places, document what you did. |
| — | Q&A | ~5 min | Seed questions are at the end if the room is quiet. |
Before we zoom in on app-based GPS pings — the data this workshop uses — it helps to see the wider family of location datasets and where ours sits. They differ mostly along two axes: how precise each position is, and how much of the population it captures. Almost nothing is both very precise and very complete; each source trades one for the other, which is exactly why they are complements, not rivals.
| Data type | Where it comes from | Spatial precision | Who / how much it covers | Best transport use | Main limitation |
|---|---|---|---|---|---|
| App GPS pings (mobile location data — our focus) | Tracking SDKs inside smartphone apps, resold by data brokers (Irys, Quadrant) | High — GPS-level, ~10–30 m | A few % of people; a biased, self-selected panel | OD matrices, visits to places, anywhere people go (all modes) | Biased sample; sparse, event-triggered; privacy-sensitive |
| Mobile network (telecom) data — CDR / signalling | Mobile operators’ own network records (CDR = call-detail records; signalling = network events) | Coarse — nearest cell tower, ~250 m to several km | Very high — most subscribers on that network (roughly a quarter to a third of people per operator) | Big population flows, disaster / displacement, where coverage beats precision | Low spatial precision; one operator only; held by the operator |
| Vehicle / probe GPS | Connected cars, fleet telematics (trucks, taxis, ride-hail), navigation apps (Waze, TomTom, HERE) | Very high — continuous, snapped to roads | Vehicles only, and only those enrolled in the programme | Road speeds, congestion, travel times, routing | Sees vehicles / drivers, not people or non-car modes |
| Transit smart-card (AFC) data | Automated fare collection — tap-in / tap-out on buses and metro | Exact at stations / stops (not continuous) | Public-transport riders who use the card | Transit OD and ridership; validating ping-derived flows | Transit trips only; tap-in-only systems miss the destination |
| Surveys & census (the baseline) | Household travel surveys, census journey-to-work | Reported at zone level — but with trip purpose and demographics | Small but representative probability sample; infrequent | Ground truth, trip purpose, and weighting / validating the big-data sources | Small, costly, quickly out of date; not real-time |
The pattern to take away: the “big data” sources (app pings, telecom, vehicle GPS) are large and timely but partial and biased, while the traditional survey is small but representative. Serious work pairs them — the big source for granularity, the survey to weight and check it. This workshop is about the first row, app-based GPS pings, but you will meet the others whenever you scope a real project.
Visual: A 2×2 positioning chart — x-axis “population coverage” (low → high), y-axis “spatial precision” (low → high). Plot app pings (high precision, low–medium coverage), telecom (low precision, high coverage), vehicle GPS (high precision, low coverage — vehicles only), and survey (representative but small). Caption: “Precision vs. coverage — pick your trade-off.”
Speaker notes — Keep this to ~2 minutes; it is orientation, not the lesson. The single idea to plant: “no source is both precise and complete — you trade precision for coverage.” Point at the app-pings row and say “this is us for the next 90 minutes.” For a non-technical room, just read the first and last columns. Quick definitions if asked: CDR = the records your operator keeps when your phone uses the network; AFC = the tap when you board a bus.
What is a “ping”? One timestamped location reading from one mobile device. Think of it as a single row in a very large spreadsheet, with at minimum:
That is it. One row, one device, one place, one moment. A device crossing a city in a day might leave a handful to a few hundred rows behind it. Multiply by hundreds of millions of devices and you get the multi-billion-rows-per-day datasets vendors describe.
Visual: A single-row schema diagram next to a synthetic example record. Below it, a stylised map with five coloured dots labelled
t=08:01,t=08:14,t=08:33,t=09:02,t=17:45showing a morning commute and an evening return. No real device.
Where do pings come from? From SDKs (software development kits — tracking code embedded inside apps) that ship with thousands of free or ad-supported apps. When you grant a weather app, a coupon app, or a game access to your location, the SDK sends periodic readings to a data broker, which aggregates and resells them.
Three consequences:
The panel. Treat the devices you receive as a self-selected survey: respondents installed certain apps and tapped “Allow”. The panel skews younger, more Android, more urban, more digitally engaged. Useful and large, but not a census.
Before any privacy concern, ping data has quirks that will quietly mislead you. The most important:
The first task in any analysis is to measure these and clean them — minimum-activity thresholds, accuracy filters, de-duplication — before trusting a single number.
Visual: A Lorenz curve of pings-per-device bowing well below the 45-degree line, captioned “a few devices, most of the pings.”
Speaker notes — Open by holding up your own phone. Say: “Right now, depending on what you’ve installed and which permissions you tapped ‘Allow’ on, you might be in one of these datasets. Maybe a dozen pings since you walked in.” Then walk through the spreadsheet analogy slowly — one row, one device, one place, one moment — and emphasise that this is the entire data model. The rest of the workshop is what you do with billions of those rows. Flag the SDK origin clearly: this is not telecom data, you are not asking AT&T for it. Aim to land this section by minute 10.
What ping data are genuinely good for in transport:
What ping data are not good for:
The honest framing: ping data are indicative and directional — a useful complement to census journey-to-work tables, household travel surveys, and ticketing data, not a replacement.
This is not a fringe technique — it has a substantial, peer-reviewed and applied track record:
Speaker notes — Use this list only if the room wants reassurance that the method is credible; name two or three and move on. The Chennai and Lima examples land best with a policy audience because they end in an investment decision, not a journal. Compressible to 60 seconds if you are behind.
Because the panel is only a few percent of the population, raw counts must be expanded to represent everyone. A tempting shortcut: take an external estimate of a city’s total trips — from a household travel survey, the World Bank, or the Asian Transport Outlook (whose data platform is now branded the Asian Transport Observatory) — and multiply every observed flow by one factor so the totals match.
The instinct is right; the single factor is the flaw. Anchoring to a known control total is exactly what best practice does — it stops the absolute level from floating free. But one global scalar fixes the city-wide level while leaving the panel’s bias intact in the shape: it over-counts trips from well-covered central, affluent, younger areas and under-counts under-served rural, lower-income, and elderly origins — precisely the people a development institution most wants to see. A single factor is fine as a clearly-labelled back-of-envelope city total; it is not defensible as the basis for an OD matrix, a mode split, or any sub-city number.
What the guidance actually does (ITF/OECD, 2021; UK DfT, 2018) is expand per home zone, not globally:
Rule of thumb. Don’t scale to one number. Use one expansion factor per home zone (≈ 1 ÷ that zone’s penetration), add demographics if you can, convert device-trips to person-trips with a survey trip rate, and validate against an independent count. Where penetration drops below ~2–3%, the factor becomes large and unstable — suppress those zones or fall back to telecom data. And on control totals: the Asian Transport Outlook does publish a city total-trips figure, but only for a handful of cities and usually lifted from a local survey of varying (sometimes decade-old) vintage — check the source and year before anchoring to it.
Speaker notes — Aimed at the economists, several of whom will have done exactly the single-scalar scaling. Validate the instinct first (“anchoring is correct”), then deliver the fix: one factor per home zone, not one for the city. The keeper line: “a global factor fixes the level but not the shape — it rescales your bias, it doesn’t remove it.” ~3 minutes.
A second way to anchor a ping-derived OD matrix — complementary to scaling it to a trip total — is to calibrate it against real traffic counts. You take the ping OD as a starting seed (prior) matrix, assign it to a road network (let a model route each origin–destination flow and predict the vehicles on every road), compare those modelled link volumes to observed counts (loop detectors, tubes, video), and adjust the matrix until the modelled flows match the counts. The technique is OD matrix estimation from traffic counts (ODME), standard in transport-planning software. The landmark mobile-data demonstration built an OD from phone data for Dhaka and scaled it in a traffic simulation to match counts at selected locations (Iqbal et al., 2014, Transp. Res. Part C 40:63–74).
Why pings make an unusually good seed: ODME is underdetermined — there are far more unknown OD cells than counted roads, so many matrices reproduce the same counts and the answer is dominated by the prior (Bera & Rao, 2011). A ping OD carries real observed structure, a far better prior than a synthetic gravity guess. Prefer this full adjustment over multiplying by a single global factor, which fixes the level but not the spatial shape. Two honest caveats: counts are vehicles, so you must assign a car OD — which re-opens the hard mode-inference problem — and you cannot validate on the counts you calibrated to; hold out independent counts or a screenline (a cordon line whose crossing flows must balance).
Speaker notes — Frame it as the inverse of assignment: assignment predicts traffic from a trip table; ODME works back to the trip table from the traffic you actually counted. The sentence to land: “because you only count a few roads, many trip tables fit equally well, so the answer is whatever you started from — which is why a real, observed ping seed beats a synthetic gravity guess.” Then the two warnings: counts are vehicles not people (feed in all-mode person-trips and the calibration hides your car-vs-bus error in a matrix that now looks validated); and tuning to counts is training, not validation — hold some out. Optional drop if Part 1 is running long.
A natural next question is how people travelled: car, bus, rail, bike, walk. With ping data this is genuinely hard, and it’s worth knowing why.
Telling modes apart relies on fine-grained movement — the pattern of speeds, accelerations, and stops — and recovering that needs the device to ping every few seconds. Research-grade GPS (consented apps, 1–5 s sampling) supports mode classification at 85–95% (Dabiri & Heaslip, 2018). But ad-tech pings arrive minutes to hours apart, in bursts, with gaps — two points eight minutes apart can hide an entire stop — so the very signal mode inference depends on is mostly gone. The often-cited “~93% mode accuracy from commercial location data” result (Yang et al., 2022) was run on data filtered to sub-15-second intervals — near-dense, not a raw feed; it doesn’t transfer.
And car vs. bus is the hardest split even with perfect data: they share the same roads at almost the same speed (~4.8 vs. 5.0 m/s). The only reliable tell is dwelling at bus stops — which sparse pings miss.
What you can still do: separate motorized from non-motorized (the speed gap is too big to miss), and flag rail/metro corridors by snapping to transit lines and stations (GTFS, the open transit-schedule standard). Anything finer — a car-vs-transit mode share — is a hypothesis to validate against a survey or farecard counts, not a result. It’s also why count calibration (above) is delicate: traffic counts are vehicles, so you need the car trips — and isolating those is exactly the problem that’s hard.
Speaker notes — The one line: “the sampling rate decides what question you’re allowed to ask.” Dense GPS → mode is solved; sparse pings → motorized/non-motorized at best. If a data scientist cites the 93% paper, that’s your cue — it quietly filtered to sub-15-second data. Tie back to the previous subsection: counts are vehicles, so the mode problem and the calibration problem are the same problem. ~2 min.
Visual: Two side-by-side maps of the same city: left, a sparse traditional OD matrix from a 10-year-old household travel survey; right, a denser modern OD matrix from pings. Underneath, a single line: “Different signals. Use both.”
Speaker notes — This is where the policy audience usually leans in, because they recognise the use cases from their own work. Keep the list short and concrete. Then deliberately slow down for the “what these data are not good for” half — that is the part that protects everyone in the room from overpromising in a project document. Land the “indicative, directional, complement not replacement” phrasing twice. The three deeper-dive subsections above (scaling to totals, calibrating against counts, mode inference) are advanced and compressible — lean into them for a technical room, skim or skip them for a non-technical one. Aim to land the core use-cases by ~18 minutes.
So how do you actually turn a pile of raw pings into an OD matrix? There are two routes. The commute-only shortcut pins each device to a home and a work location and counts the single flow between them — simple, but it sees only commutes. The more general route infers trips directly and aggregates them, giving an all-purpose, time-of-day OD. The steps:
The pay-off over the home/work shortcut is a richer picture — midday and evening trips, non-commute travel, how flows shift by hour. The price is sensitivity to the data: a missed stop merges two trips into one, a spurious stop splits one in two, and sparse, bursty pings make short trips and quick stops easy to lose. So step 1, and a sensible stop radius and dwell time, matter a lot.
Name the claim honestly. What this produces is the observed OD of the panel — the trips these devices actually made, by time of day — not population trip counts. The panel is a biased few percent, so weight it up to population (the scaling and calibration subsections above) and, above all, validate the structure against an independent OD: TomTom probe data, the census LEHD LODES journey-to-work, or a household travel survey. Compare shares and structure — the correlation of each zone’s productions (trips out) and attractions (trips in), and the OD-share distribution — not absolute counts, and mind any difference in time period between the two sources. And because “observed” still rests on the stop thresholds, state them and check the answer doesn’t swing with them. A matrix framed as “observed panel flows by time of day,” validated this way, is far harder to attack than one that quietly claims to be the population.
Part 2 builds an OD matrix from the sample data hands-on — load and clean (including the sensitive-POI strip), detect each device’s activity stops, turn consecutive stops into trips, aggregate into day-part bands, apply k-anonymity, and validate the structure, step by step. It is exactly the trip-based pipeline described here; the home/work shortcut appears only as the two-stop contrast. Because every trip carries a departure time, you also watch the busiest flows reverse between the morning and evening peaks.
Visual: One device’s week as a timeline — coloured “stop” blobs (home, work, a shop) joined by “move” arrows; beneath it, the same arrows collapsed into an origin→destination table. Caption: “Stops become trips; trips become an OD matrix.”
Speaker notes — A light, visual preview of the hands-on, not a lecture on the algorithm. The one idea to leave them with: “an OD matrix is just trips counted between zones, and a trip is just the gap between two stops.” The home/work method is worth a sentence as the two-stop special case, but Part 2 does the full trip-based version. ~2 minutes — and remember providers and privacy still come before the break.
Two vendors on the DDP partner list dominate IFI projects: Irys and Quadrant. Both are accessed through the same DDP workflow, both deliver event-level location data, and the basic data model is the same. The differences are in scale, geography, schema depth, and corporate history.
Irys (irys.us). Founded 2019, New York City. Acquired by LocationMind (a University of Tokyo spin-off) in May 2025; the Irys brand continues. Worth saying out loud: Irys is not Veraset — separate companies (Veraset is a SafeGraph spin-off), both on the DDP partner list as distinct entries. See the Irys DDP partner page and the Datarade product listing.
Quadrant (quadrant.io). Founded 2014, Singapore. Acquired by ASX-listed Appen Ltd in September 2021; brand unchanged. See the Quadrant DDP partner page and the public Quadrant Data Dictionary.
The headline comparison:
| Dimension | Irys | Quadrant |
|---|---|---|
| HQ / parent | NYC; acquired by LocationMind (Tokyo) May 2025 | Singapore; subsidiary of Appen Ltd since Sept 2021 |
| Countries | ~150 | 200+ |
| Devices | ~200M unique MAIDs | ~650M MAU (Hydra feed) |
| Daily events | ~6B | ~50B (Hydra) |
| Geographic strengths | North America, Europe | MENA, APAC, also large US feed |
| Latency | ~3 days for 95% coverage | 5-min delivery; up to 7-day max latency |
| Sampling cadence | Event-triggered (varies by app) | Event-triggered; Orion sub-sampled to ~150 events/device/day |
| Historical depth | Since Sept 2022 | Since 2019 |
| Access model (IFI) | DDP Partnership Portal proposal | DDP Partnership Portal proposal |
| Pricing tier (commercial) | Custom; quoted via Datarade | Custom; one-off / monthly / annual |
| Schema columns (core) | device_id, lat, lon, ts, h_acc, country, optional IP/carrier/model | device_id, id_type, lat, lon, h_acc, ts, ip, os, ua, country, source/pub/app_id, geohash, consent, quad_id |
| Formats | Parquet / CSV / JSON | Parquet / CSV / JSON |
| Compliance posture | GDPR / CCPA | GDPR / CCPA / PDPA; ISO 27001; SOC 2 |
How to read this table for a project. MENA or APAC project? Quadrant’s footprint usually gives you more devices. North America or Europe with a preference for a compact, analytics-focused schema? Irys is a reasonable default. Need history before September 2022? Quadrant is the only choice on this list. The Quadrant 17-attribute schema (with consent and provenance fields like app_id, source_id) is also helpful when you need to defend exactly which rows entered your analysis.
Access for IFI staff — both vendors, same workflow. You (or a colleague) must be staff at a Development Partner — the ~25 organisations including the World Bank, IMF, IDB, ADB, AfDB, and several UN agencies. Log into the Partnership Portal and submit a project proposal (use case, geography, time window, intended outputs). The vendor approves under the existing master licence. Approved data are ingested into the DDP-managed secure environment; they are not emailed to you. Expect weeks to months. If you are not affiliated with a Development Partner, this pathway is not available — you engage the vendor commercially, and full-coverage feeds routinely run into six figures per country per year.
Limitations that apply to both vendors. SDK panels over-represent free-/ad-supported-app users — typically younger, lower-income, more Android. iOS volume is materially smaller post-ATT (2021). Rural areas and low-ad-tech countries are sparsely covered. The most recent 24–48 hours are incomplete. Events are not evenly time-spaced. None of this disqualifies the data; all of it belongs in the methods note of any deliverable.
Vendors advertise enormous device counts, but those are marketing figures — regional numbers often overlap and add up to more than the global total. What matters is effective penetration: the share of an area’s actual population you can see. Independent studies put that far below the headline counts.
Rule of thumb. Aim for ~2–3% effective penetration of your study population; require ≥10 pings and ≥5 active days before assigning a home or workplace; require ≥15–20 devices per origin-destination cell before you trust — or publish — a flow. Always expand or weight raw counts to population, and validate against a benchmark (in the US, the census LEHD LODES home-to-work tables). Raw device flows are never trips.
Speaker notes — This is the slide that stops a project going wrong in month one. The single sentence to land: “the vendor’s device count is not your sample size — your sample size is a few percent of the population, on a good day.” Read the rule-of-thumb box out loud; people photograph it.
Visual: The comparison table above, rendered as a clean two-column slide. Beside it, a small caption: “Same plumbing, different fill.”
Speaker notes — This is the densest section by design, because it answers the practical question: “if I go back to my office on Monday and want to scope a project, which vendor do I write into the proposal?” Walk the table dimension by dimension. Linger on three lines: geographic strengths, historical depth, and access model. Make the not-Veraset point explicitly — people do confuse them. Close by repeating the access path: Partnership Portal, project proposal, vendor approval, secure environment. Aim to land at minute 30.
If you only remember one number from this workshop: four spatio-temporal points uniquely identify 95% of people in a mobile-location dataset. That is the headline finding of de Montjoye et al., who studied 15 months of hourly antenna-level traces for 1.5 million people and showed that “unicity” — the share of trajectories that are unique given a few observations — barely decays as you coarsen the data (de Montjoye et al., 2013). The load-bearing implication: removing the device ID is not anonymisation. A trajectory is, by itself, an identifier.
It gets worse before it gets better. A 2021 follow-up on a country-scale telecom dataset showed that re-identification risk decays so slowly with sample size that even hundreds of millions of users do not bring it to a safe level (Farzanehfar, Houssiau & de Montjoye, 2021). The intuition that “the dataset is huge, so individuals disappear in the crowd” is wrong. Privacy must be engineered in, through aggregation, not assumed from scale.
A concrete enforcement anchor for what this looks like when it goes wrong: on 4 May 2026 the US Federal Trade Commission entered a stipulated order banning Kochava and its subsidiary Collective Data Solutions from selling precise location data tied to sensitive places — medical facilities, places of worship, shelters, schools, military bases — without affirmative express consent, closing a case opened in August 2022 (FTC press release, 4 May 2026). The take-home: “we just bought the data from a broker” is no longer a defence, even in the United States. Sensitive-POI exclusion is table stakes, not a nice-to-have. For background, the 2019 New York Times investigation One Nation, Tracked used a leaked 50-billion-ping dataset to re-identify named individuals — including military officers and a Secret Service agent — by overlaying home and work addresses (Thompson & Warzel, NYT, 19 Dec 2019).
For a written standard to point IT or legal at, the current US reference is NIST SP 800-188 (final, Sept 2023), covering de-identification techniques, governance (Disclosure Review Boards), and formal privacy methods (k-anonymity, l-diversity, differential privacy) for high-risk data (NIST SP 800-188). Under NIST, hashing the MAID is not de-identification.
Visual: A re-identification illustration — the de Montjoye “4 points = 95%” finding rendered as a simple staircase chart, with a caption beneath: “Anonymity is engineered, not assumed.”
Rules of thumb you can write into a project document tomorrow. Industry-common, defensible defaults — not legal requirements; verify against your institution’s policy.
Speaker notes — This is the section that the policy audience came for. Start with the de Montjoye number and let it sit. Then the FTC Kochava order — make it concrete: a real regulator, a real company, a real ban, May of last year. Then walk through the rules of thumb slowly. Two sentences I land verbatim: “Anonymity in mobile location data is engineered, not assumed” and “The hole in the table is the privacy guarantee.” Aim to be at minute 40 by the end of this section, leaving five minutes for Q&A.
If the room is quiet, prime the pump with these.
Q1. If the data are “anonymous”, why worry about privacy at all? Because mobility traces are extraordinarily distinctive — four points uniquely identify ~95% of people (de Montjoye et al., 2013), and country-scale datasets do not dilute that risk (Farzanehfar et al., 2021). Anonymity here is a property of what you publish, not of the source file. Engineered, never assumed.
Q2. Are pings a representative sample? No. The panel is whoever installed an SDK-carrying app and tapped “Allow”. It over-represents Android, younger, lower-income, urban users; it under-represents iOS (post-ATT 2021), rural, and elderly users. Treat pings as a biased convenience sample and validate against an external benchmark — census journey-to-work, household travel surveys, or LEHD LODES in the US.
Q3. Can we use pings to measure economic activity — retail footfall, commuting, shock recovery? Yes for relative trends and shocks (the canonical COVID-19 case), with caution on absolute levels. Strongest signal: changes over time within a small area. Weakest: cross-country level comparisons.
Q4. What does it actually cost? For DDP-eligible institutions, no licence cost under the existing master agreements with Irys and Quadrant. The real cost is staff time — proposal, secure storage, processing (often terabytes per month). Commercial pricing outside DDP routinely runs into six figures per country per year.
Q5. Where are the legal and reputational red lines? Three: sensitive-location inference (FTC v. Kochava, May 2026); precise-location sale in jurisdictions with newer laws — Maryland MODPA (Oct 2025), Oregon (Jan 2026), EU/UK; any publication that allows re-identification of individuals or small groups. When in doubt, aggregate harder.
All accessed 25 May 2026.
consent, quad_id).Transport applications and methods:
Expansion, calibration, and mode inference: