Parking lot counts vs. foot traffic panels for retail earnings forecasts
Anyone modeling same-store sales ahead of a print has run into the same wall: foot traffic panels are built on a sample of phones, and that sample moves around under you.
What a foot traffic panel actually measures
A foot traffic panel (Placer.ai, Safegraph-style data, and similar products) starts from a pool of devices that opted into location sharing through some app on the phone. The vendor extrapolates from that panel to an estimate of total visits for a location, using census and demographic weighting to correct for panel bias. That extrapolation step is where things get shaky for single-tenant forecasting. The panel's device mix shifts quarter to quarter as apps gain and lose users, as iOS privacy settings change, and as the underlying population simply ages into or out of certain apps. None of that has anything to do with how many people actually walked into the store, but it shows up in the trend line anyway.
Panels are also built for category-level and portfolio-level reads. They work reasonably well when you're averaging across five hundred locations of a national chain, because sampling noise washes out. A single big-box store, a single power center anchor, or a single distribution facility is a much smaller sample, and the month-to-month swings can be sampling artifact as much as signal.
What a parking lot count measures instead
A parking lot count skips the device panel entirely. Each pass of a very-high-resolution satellite or aerial platform images the lot, and the vehicles in the frame get counted directly from the pixels, not inferred from a phone sample. At 0.5 m ground sample distance or better, individual cars resolve cleanly enough to count stall by stall. Run that daily at the same site and you get an occupancy series: how full the lot was today versus the same day two weeks ago, versus the same week a year ago.
That's a different kind of proxy than a foot traffic panel, not a better or worse one in the abstract. It has its own blind spots. It won't tell you how long a shopper dwelled, what they bought, or whether they walked in from the sidewalk instead of parking. Overflow lots, street parking, and employee parking in a back row all need to get handled in how you read the series, not assumed away. And a count of cars in a lot is a count of cars in a lot. It's a traffic proxy for the site, not a revenue number, and it should get triangulated against whatever else is in the model, not treated as a standalone forecast.
Where this fits next to the panel, not instead of it
For a REIT analyst building a read on an anchor tenant's quarterly comp, or an equity analyst trying to get ahead of a retail print, the honest framing is that parking lot occupancy and panel-based foot traffic are measuring overlapping but distinct things, from independent collection methods. A device panel has sampling bias tied to app adoption. A vehicle count has its own biases tied to parking supply, walk-ins, and transit-accessible locations. When both move together, that's a stronger signal than either alone. When they diverge, that divergence is worth digging into before the call, not after.
That's the specific niche a daily occupancy read like this is built for: a per-site series from repeat VHR passes, delivered so it sits next to a tenant's reported comps on the same chart rather than buried in a portfolio-level dashboard. The data comes from satellite imagery, not a device panel, counting cars rather than inferring visits from a sample. That's the lever for catching a trend before the company puts it in a press release.
If a parking lot is the chokepoint for a tenant's foot traffic, that's a lot worth counting daily. Get in touch to see what a site's occupancy series looks like before your next model update.