How to normalize parking lot vehicle counts for weather and seasonality

A raw count of cars in a lot on a given day tells you almost nothing by itself. A grocery-anchored center with 40% fewer cars on a Tuesday than the prior Tuesday could be losing traffic to a new competitor, or it could just be raining. Before a parking count series is useful as a footfall proxy for a tenant's same-store comps, it has to be cleaned up. Here's the approach that actually holds up across a retail portfolio.

Separate weather noise from the signal

Weather is the biggest single source of day-to-day variance in a lot count, and it's also the easiest to correct for because it's measurable. Pull daily precipitation and temperature for each site's zip code and flag the outliers: heavy rain days, snow events, days over 95°F for open-air centers, days under 20°F for anything without covered parking. Those flagged days get either excluded from trend calculations or weighted down, not deleted from the series entirely. You still want them in the record, since a string of snow days across a whole region in February is itself informative about a quarter's traffic, just not informative about whether a specific tenant is underperforming.

A simple way to handle this without building a full regression model: compute a rolling 90-day median for each site and compare each day's count against that median rather than against the single prior week. Weather knocks individual days around; it rarely moves a 90-day median much. A rolling median that keeps sliding over several weeks is a tenant-level signal worth flagging to the asset management team.

Strip out the calendar, then compare year over year

Seasonality in parking counts isn't subtle. A strip center with a home-goods anchor runs hot in Q4 and dead in late January. A DC-adjacent industrial park shows a weekly saw-tooth from shift changes that has nothing to do with the tenant's revenue. Before you chart a site against a tenant's reported comps, you need three adjustments layered on top of the weather correction:

• Day-of-week indexing. Build a baseline index value for each day of the week per site (Saturday counts aren't comparable to Tuesday counts), then express daily counts as a ratio to that day's baseline rather than as an absolute number.
• Holiday-week flags. Thanksgiving week, the week of July 4th, and the last week of December behave nothing like the surrounding month. Treat them as their own category rather than letting them distort a monthly average.
• Year-over-year framing. Comparing this October's counts to this September's catches seasonal churn that has nothing to do with store performance. Comparing this October to last October, same day-of-week alignment, isolates the part of the move that's actually about the tenant.

Once those three are in place, what's left in the index is much closer to what a same-store sales print is measuring: traffic that moved because something changed at the property, not because the calendar or the sky did.

What the cleaned series is good for

A normalized index doesn't replace a tenant's reported numbers. What it does is give you a read on the trend weeks before the print lands, and a way to sanity-check the print once it does. If a tenant's reported comps come in flat but the lot's weather- and seasonally-adjusted index has been drifting down for two quarters, that's worth a question on the earnings call. If the index and the print move together, you've got confidence the proxy is tracking something real at that specific site, which matters when you're extending the same method to a dozen other locations for the same tenant where you don't have a print to check against yet.

In practice, the hard part is getting a daily count at each site consistent enough, image to image, that the adjustments above correct for weather and the calendar rather than for changes in capture quality. Parking Lot Counts builds that daily, per-site series from repeat high-resolution passes, so the input to this kind of normalization is already a clean count rather than something you have to clean twice.

If you're tracking a tenant across multiple sites and want the daily counts to build this index from, that's the whole point of the product.