Location Intelligence Retail Site Selection Automation

Mobility & Foot Traffic Data Integration

Census demographics say who lives in a catchment. Mobility data says who actually goes there — which visitors a store draws, how often they come, and where they came from. This section covers integrating aggregated visit panels into the same pipeline that produces drive-time catchments and demographic joins, with the corrections and privacy thresholds that make the result usable.

It is the most powerful and the most easily misused input in a retail location stack. Powerful because it measures behaviour rather than inferring it: a trade area drawn from observed visits is not a model of where customers might come from, it is a record of where they did. Easily misused because a mobility panel is a sample of devices with an opaque, uneven and shifting relationship to the population, and treating its counts as population counts produces confident answers that are wrong in ways no internal check will catch.

Concept: A Panel Is Not a Census

Every mobility dataset available to a retailer is a panel — a set of devices whose location signals a vendor has permission to process — expanded to represent a population. Three properties follow, and every methodological decision in this section descends from them.

Coverage varies geographically. Panel penetration differs by market, by urban density and by neighbourhood demographics, often by a factor of two or more. A raw visit count therefore compares markets on their panel coverage as much as on their footfall.

Coverage varies over time. Panels change as apps enter and leave the vendor’s arrangement, as operating systems change permission models, and as consent rates shift. A year-on-year comparison of raw counts is measuring the panel’s own history alongside the store’s.

The unit is a device, not a person. Households share devices, individuals carry several, and some devices are not people at all. Any conversion from device-visits to customer-visits is an assumption that belongs stated rather than buried.

None of this makes the data unusable — it makes ratios far more trustworthy than levels. The share of a store’s visitors coming from each origin zone is robust to panel size; the absolute number of visitors is not. Building the pipeline around relative quantities and calibrating levels against something you own, such as point-of-sale transaction counts, is the difference between a useful input and a confident illusion.

The same footfall, three panel coverages, three wrong answers Three stores with identical true footfall of 12,000 monthly visits sit in markets where the panel covers 4.1, 2.6 and 1.4 per cent of devices. Raw panel visits are 492, 312 and 168, so a ranking on raw counts places them in an order that reflects panel penetration rather than store performance. Rank on raw panel visits and you have ranked the panel store true visits panel coverage panel visits raw rank A · dense urban 12,000 4.1% 492 1 B · suburban 12,000 2.6% 312 2 C · small town 12,000 1.4% 168 3 Three identical stores, ranked one, two and three, entirely by how many panel devices happen to live nearby. No internal consistency check catches this, because the data is internally consistent. What survives the problem is the mix: the share of A's visits coming from each origin zone is close to correct even when the count is not, because the coverage factor divides out of a ratio. Coverage figures are illustrative of the spread commonly seen between market types.

Architecture: Where Mobility Data Joins the Pipeline

Mobility data arrives as aggregates — visits per place per period, and origin-destination matrices between home zones and places — rather than as individual traces, and it should stay that way inside your pipeline. The integration therefore has four stages.

Place matching links the vendor’s place identifiers to your store identifiers and to your competitor set. This is a deduplication and geocoding problem, and it inherits every difficulty from geocoding and address normalization: the vendor’s polygon for a store may be the whole shopping centre, two of your stores may map to one vendor place, and a renamed unit may appear as a new place with no history.

Weighting converts panel counts into population-scaled estimates by dividing by the panel’s coverage in each origin zone. This is where most of the accuracy is won or lost, and it is covered in correcting panel bias in mobility datasets.

Spatial join attaches origin zones to your catchment geometry, using the same apportionment discipline as any other demographic join — with the added subtlety that a home-zone attribution is itself an estimate rather than an address.

Calibration anchors the estimates to something measured: transaction counts, door counters, loyalty scans. Without it the pipeline produces a well-formed number in unknown units.

Configuration Parameters

Parameter Typical value Notes
origin_geography census block group Finer than this is usually suppressed anyway
min_visits_per_cell 5 Cells below the threshold are withheld, not zeroed
weighting_basis devices per adult population Per origin zone, per month
dwell_min_minutes 4 Separates a visit from a pass-by
dwell_max_minutes 240 Above this, likely an employee or a parked device
visit_dedup_window 30 min Re-entry inside the window is one visit
period calendar month Weekly is noisy at store level; quarterly hides seasonality
home_zone_confidence vendor-provided, kept Never treated as certain

The dwell thresholds do more work than their simplicity suggests. Set the minimum too low and a store on a busy pavement counts every passer-by; set the maximum too high and the staff carrying devices dominate a small store’s visit count. Both errors are systematic by store format and location, which means they distort comparisons between sites rather than adding noise.

Dwell time distribution at a high-street store Device dwell times at a high-street store cluster below two minutes — passers-by on the pavement — then form a broad shopping peak between six and twenty-five minutes, and a small group above four hours that is almost entirely staff. The thresholds are chosen at the troughs between these three populations. Three populations in one distribution < 4 min the shopping peak > 4 hours pavement traffic — excluded counted as visits staff — excluded A drive-through or a forecourt has a completely different shape, so the thresholds belong per format.
Four stages between a vendor extract and a usable trade area Vendor aggregates are matched to store places, weighted to population per origin zone, joined to catchment geometry, and finally calibrated against transaction counts. Each stage has its own failure mode, and only the last one gives the estimates units a business can act on. Match, weight, join, calibrate — in that order 1 · place match vendor place → store 2 · weight devices → population 3 · spatial join origin zones → catchment 4 · calibrate against sales Stage one is a deduplication problem, stage two is where the accuracy is won, stage three is an ordinary spatial join, and stage four is what turns an index into a number of shopping trips. Skipping stage four is common and produces a pipeline whose output is internally consistent, comparable across stores, and expressed in units nobody can interpret. The stages are independent enough to build in order, which is the recommended way to adopt the data: match and join first for the origin mix, then weight and calibrate when levels start to matter.

Privacy and Aggregation Thresholds

Mobility data describes people’s movements, and the responsibilities that come with it are not optional extras on top of the analysis — they shape the pipeline’s design.

Three rules carry most of the weight. Work from aggregates, not traces: a pipeline that never holds device-level paths cannot leak them, and every question in this section can be answered from origin-destination aggregates. Enforce a minimum cell count — commonly five, sometimes higher by contract — and treat suppressed cells as withheld rather than as zero, because a zero is a claim and it is the wrong one. Suppress the margins too: a table whose cells are suppressed but whose row and column totals are published invites reconstruction by subtraction, which is the same disclosure risk covered in handling privacy thresholds in visit aggregations and in the PII practices that govern the wider data lake.

The contractual layer matters as much as the technical one. Vendor agreements typically constrain retention, redistribution and the geographies at which results may be published, and those constraints belong encoded in the pipeline — as retention rules on the storage layer and as a suppression step in the export — rather than as a paragraph somebody read once.

What Mobility Data Answers That Nothing Else Can

It is worth being concrete about the questions this input unlocks, because the licence cost is real and the answer to “is it worth it?” depends entirely on which of these a business actually needs.

Where do a store’s customers really come from? Every other method infers this. A drive-time catchment assumes people shop at the nearest reachable store; a gravity model assumes they trade off size against distance; a loyalty file knows only about the customers who joined the scheme. An origin-mix from a panel measures it directly, including the customers who pass three competitors on the way and the ones who visit while commuting rather than from home.

How far does the trade area really extend? Modelled catchments are drawn at a chosen time band, which is a convention rather than a measurement. Observed origin shares show the actual tail — how much of a store’s business comes from beyond fifteen minutes, and whether that tail is a handful of stragglers or a quarter of the revenue. For destination formats the answer is routinely surprising, and it changes both the site score and the media plan.

Which competitors do our customers also visit? Cross-visitation is only visible in mobility data. Knowing that forty per cent of a store’s visitors also visit a specific rival, and eight per cent visit another, is a direct measurement of who you are actually competing with — which is frequently not the nearest store, and frequently not the one the format comparison suggests.

What happened after a competitor opened? A panel provides a before-and-after view of visit volumes and origin mix around a competitive event, at every affected store simultaneously. That is the closest thing to a controlled experiment available in retail location analysis, and it is the evidence that turns cannibalization and competitive-impact models from assumptions into fitted relationships.

How do visit patterns differ by daypart and day of week? Formats live or die on this — a store whose visits concentrate in commuter peaks needs a different assortment and a different site than one whose visits are weekend family trips. Transaction data shows it for your own stores; a panel shows it for candidate locations by observing whatever is there now, and for competitors you will never have transaction data on.

The common thread is that each of these questions is about behaviour rather than geography, and behaviour is exactly what the rest of the location stack has to assume. That is the argument for the input and also the reason for the care: an answer about behaviour, drawn from a biased sample and presented without its corrections, is more persuasive and more dangerous than an obviously modelled number.

Scaling and Performance

Mobility aggregates are large by row count and small by complexity. A national origin-destination matrix at block-group resolution over a year is hundreds of millions of rows, and every question asked of it is a filter and a group-by. That makes it a natural fit for the partitioned columnar storage already carrying the rest of the pipeline: partition by month and market, keep the origin and place identifiers as dictionary-encoded columns, and the queries that matter run in seconds over the partitions they need.

The expensive stage is the spatial join between origin zones and catchment geometry, and it is expensive in the ordinary way — many polygons against many polygons — so it benefits from exactly the treatment described in performing point-in-polygon joins: reproject once, index once, and join per market rather than nationally.

Validation and QA Gates

  • Place-match coverage — the share of your stores matched to a vendor place, tracked over time. A fall means the vendor re-identified places, not that stores closed.
  • Panel stability — devices observed per origin zone, month over month. A step change is a panel event and every level comparison across it is invalid.
  • Dwell distribution shape — per format. A store whose distribution suddenly loses its shopping peak has a place-boundary problem.
  • Suppression rate — the share of cells withheld. Rising suppression in rural markets is expected; rising suppression everywhere is a panel contraction.
  • Calibration residuals — modelled visits against transactions for the stores where both exist, which is the only check that speaks to accuracy rather than consistency.

Integration Notes

Downstream, mobility data enters the suitability score in two distinct ways, and keeping them separate matters. As a demand signal, visit estimates for comparable stores inform what a candidate site might achieve — an analogue-based forecast rather than a modelled one. As a catchment measurement, the observed origin mix replaces or corrects the modelled drive-time catchment, which is the most direct improvement mobility data offers: a trade area that came from where visitors actually live rather than from an isochrone.

The second use also feeds distance-decay calibration directly, since an observed origin mix by travel time is precisely the curve that calibration is trying to fit.

Frequently Asked Questions

Can mobility data replace drive-time catchments?

It complements them rather than replacing them, for a structural reason: a mobility panel can only describe stores that exist. For a candidate site with no store on it, there is nothing to observe, so the catchment has to be modelled — and the modelled catchment is calibrated by comparing modelled and observed catchments at stores you already operate. That is the right division of labour: observation where it is available, modelling where it is not, and observation used to correct the model.

How much history is needed before the data is useful?

Three months for a level, twelve for a trend. A single month at store level is noisy enough that a modest change in panel composition dominates it; three months smooths that adequately for comparing stores. Anything seasonal — and most retail is — needs a full year before a year-on-year comparison means anything, and even then it needs a panel-stability check across the period.

What resolution should origin zones be?

Census block group is the practical floor, and tract is often the honest one. Finer geographies produce more suppressed cells, and the cells that survive suppression are systematically the denser ones — which biases the origin mix toward urban zones in a way that is very hard to see. Aggregating deliberately to a coarser geography where suppression is high produces a less precise and considerably more accurate picture.

How should a store with an unusual layout be handled?

By checking its dwell distribution rather than trusting the defaults. A drive-through, a petrol forecourt, a store inside a transport hub and a destination retail park all produce distributions that differ from a high-street shop, and applying one set of thresholds to all of them mislabels visits in a format-specific direction. Setting thresholds per format, from the observed distributions, takes an afternoon and removes a bias that would otherwise be permanent.

Is it worth buying mobility data for a small estate?

Often not, and the reason is the calibration requirement rather than the licence cost. Getting value from a panel means matching places, correcting bias, and validating against transactions — an amount of engineering that pays back across hundreds of stores and rarely across ten. A small estate is usually better served by its own transaction and loyalty data, which is free, unbiased about its own customers and already in the building.

What does a sensible first project look like?

One market, one format, three months of data, and a single question: does the observed origin mix agree with the modelled catchment for the stores we already run? That project needs place matching, a basic weighting and one comparison, produces an answer that is immediately useful, and surfaces every integration problem — shared centre places, suppression rates, geography mismatches — at a scale where they can be worked through rather than absorbed. Teams that begin with a national pipeline discover the same problems at a point where they have to be solved under deadline.

How should the estate’s mobility data be governed internally?

With the same care as customer data, because that is what it describes even in aggregate. In practice that means a named owner for the vendor relationship and its contractual limits, a documented retention schedule enforced by the storage layer rather than by habit, a suppression step applied in the export path so no analysis can accidentally publish below the threshold, and a short internal note explaining to analysts what the data is and is not. None of that is onerous, and it is considerably easier to put in place before the first dashboard than after the first question about it.

Conclusion

Mobility data is the only input in a retail location stack that measures behaviour directly, and it comes with a sampling structure that punishes naive use. Work in ratios rather than levels, correct for panel coverage per origin zone, choose dwell thresholds per format from observed distributions, enforce suppression thresholds on cells and margins alike, and calibrate against transactions wherever both exist. Do that and the panel becomes what it should be: the evidence that turns a modelled trade area into a measured one.

← Back to Demographic Data Integration & Spatial Joins