Most of the simple site selection methods pioneered several decades ago are still widely used despite their known shortcomings. We all know fully well that the probability that a resident will be a customer is much higher if that customer lives one mile away than if they live five miles away. Despite this general awareness, trade area reporting systems persist in counting each household, regardless of how distant, as equal.
Analysts can become rigid applying filtering criteria for potential locations, requiring threshold levels of households and income, measured over a standardized trade area defined in either miles or drive time minutes. Summary demographics are presented, as if all households in the area are of equal importance.
For example, we have two nearby alternative restaurant sites, and for simplicity, we consider only households and median income for a five-mile radius. The first site has a higher count of households by some margin. But this masks the fact that its households are located further away in the trade area than are the households in the second site. When accounting for distance, the picture changes dramatically, as shown by the table below:
The weighted household count is derived by applying a distance decay factor using the Snapshot DECAY() function, which applies a simple distance weighting function that generates a weighted value (y) from the variable x:
The user specifies, β, which is our distance decay factor and is applied to the distance between each observation point and the site location. A value of 1.0 results in a linear decay, and a value of 2.0 results in a sharp decay. A second factor is used to specify a starting distance at which the decay is applied. Further, we can specify how we would like the output – either as the raw weighted count (as above), as a percentage of the unweighted value, and as a coefficient. In the above example we specified DECAY(RAW,HHDCY,1.0,1.5), which computed weighted households (HHDCY) with a decay coefficient of 1.5 which is applied at distances starting at one mile.
The interpretation of the weighted household count is obviously somewhat more difficult than the unweighted count, and may be an over complication if we are looking at individual sites in detail – a quick look at the population density surrounding a site can point an experienced analyst away from sites where most of the trade area households are at the edge of the trade area.
However, users are now accustomed to seeing maps which show “hot spots” so that rather than looking at the demographics for any particular location, they can scan large areas looking for areas where they are most likely to succeed. A typical hot spot map is based on the calculation of the same size trade area over a regular point grid from which a surface can be rendered. The results are certainly impressive, cost effective, and of considerable utility in selecting broad areas for further consideration. However, in the process of running hundreds of locations in a metropolitan area, we have now enabled the user to gloss over the details of the distribution of households within each of the trade areas that together comprise the map.
We run the substantial risk of two types of errors. We may highlight as good candidates some areas which have adequate summary variables (e.g. meets the threshold criteria) but in which the density of those variables tends to increase as we move away from the site. In such cases, our demand estimate is likely on the high side, which is sometimes a fatal location error. Conversely, we may rule out areas where the summary variables fail to meet the threshold level but in fact have concentrated demand near the site. Using the DECAY() function can help to overcome these deficiencies, albeit at the expense of some clarity in the results.
Recent Comments