What evidence confirms the issue
A measurement plan is the document or working note that specifies what a proximity deployment is supposed to achieve, which metrics will indicate progress, and how those metrics will be collected before any hardware is fixed to a wall. Deploying without one means installing beacons, NFC tags or QR codes, connecting them to a content management system, and only afterwards asking what the data means or whether the investment is justified.
In practice, this mistake tends to follow a predictable pattern. A retailer, museum or event organiser decides that proximity technology sounds useful. Hardware is procured, an integrator mounts the devices, and the system goes live. Within a few weeks, someone requests a report. At that point it becomes clear that nobody agreed on a baseline, that the analytics pipeline was never tested end to end, or that the metrics being collected do not actually answer the question the business needs answered.
The core problem is not a lack of data. Most beacon platforms, NFC management systems and dynamic QR services produce event logs: a tag was scanned, a beacon was detected, a notification was sent. The problem is that activity data is not the same as evidence of value. A high scan count on an NFC tag next to an exhibit might look positive, but without a measurement plan you cannot determine whether those scans represent deeper engagement, a one-tap mistake, or visitors simply testing what the tag does.
A measurement plan does not need to be a lengthy document. For a pilot, it can be a single page that records the objective, the primary metric, the secondary metrics, the baseline period, the review date and the decision rule. The decision rule is particularly important: it states in advance what the organisation will do if the metric meets, falls short of, or exceeds the target. Without that rule, pilot results tend to be debated rather than acted upon.
Prioritise causes by risk and evidence
Retail environments
In a retail setting, a common scenario involves deploying beacons near specific product zones to push offers to shoppers who have opted in. Without a measurement plan, the deployment might track notification delivery rates and open rates, but fail to connect those figures to till data or basket composition. The result is a system that generates engagement numbers but cannot demonstrate whether proximity-triggered offers influenced purchasing behaviour.
A practical measurement plan for this use case would start with a clearly defined objective, such as increasing sales of a promoted category by a specific percentage during the pilot period. It would then specify the primary metric, for example the conversion rate of shoppers who received a notification versus a comparable group who did not. Secondary metrics might include average transaction value, dwell time in the zone and notification opt-out rates. The baseline would be drawn from the same period in a previous year or from a control zone where no beacons are active.
Museums and galleries
Museums frequently deploy NFC tags or QR codes at exhibits to provide additional content. A deployment without a measurement plan might simply count scans per exhibit and present that as a success metric. However, scan count alone says nothing about content completion, visitor satisfaction or whether the technology changed how people moved through the space.
A more useful measurement plan would define the primary question, such as whether digital content increases median dwell time at tagged exhibits compared with untagged exhibits in the same gallery. It would specify how dwell time is measured, whether through Bluetooth detection, manual observation during the pilot or another method, and what threshold would justify a wider rollout. It would also define what happens if dwell time increases but visitor flow through the rest of the gallery slows, creating congestion.
Events and conferences
Event organisers sometimes deploy beacons at session rooms to automate attendance tracking or push session-related material. Without a measurement plan, the system may produce a list of detected devices per session but no clear basis for deciding whether the technology replaced a manual process effectively, reduced queue times or improved the attendee experience.
A measurement plan here would define the manual process that the deployment is intended to replace or improve, the time and error rates of that existing process, and the specific improvements the beacon system needs to demonstrate. It would also account for the fact that not all attendees carry Bluetooth-enabled devices or have location services enabled, establishing an expected detection rate based on the event's audience profile.
Document exceptions and remaining limits
Confusing activity with outcome
The most frequent mistake is treating activity metrics as outcome metrics. Notification sends, beacon detections and QR scans are activity data. They tell you the system is working technically. They do not tell you whether the deployment achieved its purpose. A measurement plan separates these layers: technical health metrics confirm the system is functioning, while outcome metrics assess whether the deployment is worth continuing.
Skipping the baseline
Without a baseline, you cannot attribute changes to the deployment. If a retailer installs beacons in April and sees a sales uplift in May, that uplift might be caused by seasonal demand, a parallel marketing campaign or a competitor closing nearby. A baseline period, ideally covering the same length of time immediately before deployment or during the same period in a previous year, provides the comparison needed to isolate the technology's contribution.
Not testing the analytics pipeline before going live
It is common to discover after launch that events are not reaching the analytics platform, that device identifiers are being hashed in a way that prevents correlation with other data sources, or that the reporting dashboard does not expose the metric the measurement plan specifies. The analytics pipeline should be tested with a small number of devices before the full installation, using the same hardware, firmware and platform configuration that will be used in production.
Measuring everything instead of what matters
Some deployments attempt to collect every available metric on the assumption that more data is better. This tends to produce noisy reports where no single figure is clearly actionable. A measurement plan should identify one primary metric that directly reflects the objective, supported by a small number of secondary metrics that provide context. If the primary metric moves in the desired direction, the secondary metrics help explain why. If it does not, they help diagnose the cause.
Key checks before deployment
- Objective stated in one sentence: Can you write down, in plain language, what this deployment is supposed to achieve? If the answer is vague, such as "improve the visitor experience," refine it until it is specific enough to measure.
- Primary metric identified: Is there a single metric that, if it moves in the right direction, would indicate the deployment is working?
- Baseline defined: Do you have a comparable period or control group to measure against?
- Decision rule recorded: Have you stated in advance what action follows from the results, including the option to remove the technology?
- Analytics pipeline verified: Has data flowed from the physical device through to the reporting layer using the production configuration?
- Review date set: Is there a specific date on which the results will be assessed against the plan?
- Responsibility assigned: Is it clear who will compile the data, who will interpret it and who has the authority to act on the findings?
Deploying proximity technology without a measurement plan does not necessarily mean the deployment will fail. It means you will not know whether it succeeded, and you will not have the evidence needed to justify scaling, modifying or discontinuing the investment. For pilots, which are explicitly designed to inform a decision, the absence of a measurement plan undermines the entire purpose of running the pilot in the first place.
