Designing an Effective Proximity Pilot
A proximity pilot exists to answer specific questions before committing to a wider rollout. The most common failure is treating a pilot as a small-scale deployment rather than a structured test. Without a clear hypothesis, the results will be anecdotal rather than actionable.
Start by stating what you need to learn. Typical pilot questions include: can beacons reliably trigger notifications at a specific entrance without excessive delay? Does the chosen placement hold up during peak footfall? Will visitors tolerate the notification frequency you have in mind? Each question should map to a measurable outcome, such as a trigger rate above a defined threshold or a notification-dismissal rate below a certain level.
Limit the number of variables. If you change beacon placement, transmit power, advertising interval and notification copy simultaneously, you will not be able to attribute any result to a single cause. Decide which variable matters most for this pilot and hold the others constant. For a first pilot, placement and signal reliability usually take priority over campaign creative.
Define what constitutes success before the pilot begins. This might be a consistent trigger rate across 90% of approach paths, or a mean time to notification under three seconds at a defined walking speed. Without a pre-agreed threshold, you risk interpreting ambiguous data to fit a preferred outcome.
How to Test a Proximity Pilot With Real Visitors
Internal testing with staff devices should precede any live visitor exposure. Walk every expected approach path at different speeds, hold devices at pocket and bag height, and note where triggers fail or duplicate. This stage catches obvious placement errors and interference hotspots before they affect the visitor experience.
When moving to real visitors, phase the exposure. Begin with a small group, perhaps during a quieter period, and observe behaviour directly. Watch whether visitors notice the notification, how they react, and whether they stop, read and engage or simply swipe it away. Direct observation reveals friction that analytics alone will not show, such as visitors struggling to locate Bluetooth in their phone settings.
Consent must be handled properly even during a pilot. Under current UK data-protection guidance, visitors should understand what data is collected, why, and how long it will be kept. A pilot is not an exemption from privacy obligations. If you are collecting device identifiers or location data, the same transparency and consent mechanisms that would apply to a full deployment are needed at pilot stage.
Capture qualitative feedback alongside quantitative data. A brief conversation with visitors who received a notification, or a simple feedback mechanism within the notification itself, often reveals why a technically successful trigger produced a poor engagement result. Common findings include irrelevant content, poor timing relative to the visitor's task, or notifications that arrive after the visitor has already passed the point of interest.
Pilot Scope and Duration
Scope and duration are directly linked. A pilot covering a single zone with one beacon type can produce useful data in a week or two, provided that period includes representative footfall patterns. A multi-zone pilot comparing different placement strategies or hardware models will need longer, both to gather sufficient data and to account for day-to-day variation.
Avoid the temptation to compress a pilot into a single busy weekend. Weekend traffic may not represent weekday patterns, and a two-day window leaves no room to adjust for unexpected issues such as a firmware problem or a venue layout change. Equally, running a pilot for months without a clear end point tends to drift into permanent operation without the rigour of a proper evaluation.
Consider external factors that could distort results. A special exhibition, a weather event that changes footfall, or a nearby competing attraction can all skew pilot data. Note these factors in your pilot log so that evaluation accounts for them rather than treating the period as a stable baseline.
As a practical starting point, plan for a minimum of five to ten operating days that include both quiet and busy periods. If your venue has strong weekly cycles, aim to cover at least one full cycle. Extend only if the data is inconclusive, not because the pilot has become comfortable to run.
Selecting Pilot Zones and Visitor Segments
Zone selection should balance representativeness with diagnostic value. A zone that is typical of the wider venue tells you whether the approach works in normal conditions. A zone that is known to be challenging, perhaps due to thick walls, metal fixtures or high crowd density, tells you where the limits lie. Most pilots benefit from including at least one of each.
When assessing a zone, check for sources of Bluetooth interference. Wi-Fi access points operating in the 2.4 GHz band, neighbouring venues with their own beacons, and large metal surfaces such as refrigeration units or lift shafts can all degrade signal consistency. Document what is present before installing hardware, so that unexpected results can be traced to a likely cause.
Visitor segments matter less for signal testing but become important when the pilot includes notification content or engagement measurement. If your eventual rollout targets different visitor types, such as first-time visitors versus members, the pilot should expose at least one segment to the full experience. However, do not attempt to segment so finely that each group contains too few interactions to evaluate meaningfully.
A common mistake is selecting zones based solely on convenience, such as areas where beacons are easy to mount. This produces optimistic results that do not transfer to the more difficult zones that will form part of the full deployment. Prioritise zones where the technology will be tested, not where it will be easiest to install.
Pilot Monitoring and Adjustment
Daily checks during the pilot prevent small problems from invalidating days of data. Verify that each beacon is still broadcasting by scanning with a known-good device, check that battery levels have not dropped unexpectedly, and review trigger logs for anomalies such as missed triggers or repeated firing at a single point.
Decide in advance which adjustments are permitted during the pilot and which would break the test. Moving a beacon by a few centimetres to correct an obvious mounting error is usually acceptable. Changing the advertising interval or transmit power mid-pilot means the data collected before and after the change cannot be directly compared. If a change of that magnitude is needed, note it clearly and consider whether the affected data should be excluded from evaluation.
Interference issues often emerge only under real-world conditions. A beacon that triggers reliably during an empty-venue test may behave differently when the space is full of people, whose bodies absorb Bluetooth signals, and devices, which add to the RF noise. If trigger rates drop during busy periods, document the time, footfall level and any patterns, as this is precisely the kind of finding a pilot is designed to surface.
Keep a pilot log that records every observation, change and external event. This log is the single most important output of the pilot phase. Without it, you will be left trying to reconstruct conditions from memory when evaluating results weeks later.
Evaluating Pilot Results
Evaluation should return to the original hypothesis and success criteria. If the question was whether beacons could trigger consistently at a specific entrance, the relevant metric is trigger rate, not visitor satisfaction or dwell time. Resist the urge to pivot to more favourable metrics if the primary one was not met.
Distinguish between technology performance and experience performance. A beacon may trigger 95% of the time, which is a strong technical result, but if 80% of visitors dismiss the notification without engaging, the experience design needs work before a rollout is justified. Conversely, high engagement with a low trigger rate suggests the content is right but the infrastructure needs attention.
Compare results across zones and time periods. If one zone consistently underperforms, the cause is likely environmental rather than random. If performance degrades over the course of the pilot, battery drain or interference from a new source may be responsible. These patterns are only visible if the data is segmented by zone and time rather than aggregated into a single average.
The go or no-go decision should be explicit and documented. State which criteria were met, which were not, and what the next step is. A no-go outcome is not a failure; it is the purpose of running a pilot. Common next steps include revising placement and running a second pilot, changing hardware specifications, adjusting the scope of the planned rollout, or deciding that proximity technology is not the right solution for the identified use case.
Finally, capture the lessons that will inform the full deployment or the next pilot. What would you do differently in terms of zone selection, monitoring frequency, or success criteria? These observations have operational value well beyond the current project.
