Distinguish technical faults from design faults
Proximity marketing projects fail in predictable ways. The hardware is rarely the problem. Most setbacks come from decisions made before a single beacon is mounted or a QR code is printed: skipping the site survey, treating consent as an afterthought, or assuming that placing a transmitter near a product automatically generates engagement.
The pattern tends to follow a familiar arc. A retailer, museum or event organiser sees a demonstration, orders a batch of beacons or tags, and expects the technology to deliver footfall data or trigger notifications straight out of the box. What arrives instead is a set of broadcasting devices that need placement logic, calibration, a receiving application, content management, privacy controls and an ongoing maintenance schedule. When those elements are missing or rushed, the project stalls after the pilot phase and the hardware ends up in a drawer.
Understanding where these projects typically break down helps you allocate time and budget to the stages that actually determine success. The mistakes cluster around five areas: technology selection, physical deployment, consent and privacy, campaign design, and operational maintenance. Each has practical warning signs you can check before committing spend.
Fixes, fallbacks and ownership
The right technology choice depends on what you need the visitor to do, what device they are carrying, and what physical constraints your venue imposes. Mistakes here usually stem from selecting a technology based on novelty rather than fit.
Retail environments
In a supermarket or high street shop, the goal is often a notification or offer triggered when a shopper enters a specific aisle or approaches a fixture. Beacons suit this when you already have a store app and can rely on Bluetooth being enabled. QR codes printed on shelf edges work when you cannot assume app adoption but can expect the shopper to point their camera. NFC tags embedded in displays suit premium or controlled environments where the visitor is encouraged to tap, but they fail if the tag surface is obstructed or the reader cannot get within a few centimetres.
A common retail mistake is deploying beacons at full transmit power in a densely shelved shop, then wondering why a device three aisles away still receives the signal. The physical environment dictates placement and power settings far more than the beacon's rated range.
Museums and galleries
Museums typically want exhibit-triggered content: audio, text or images that appear when a visitor stands near a specific object. The temptation is to place one beacon per exhibit and expect precise, one-to-one triggering. In practice, exhibits are often close together, walls and display cases attenuate signals unpredictably, and visitors cluster in ways that block Bluetooth propagation. Without careful zone definition and calibration, a visitor standing at one painting may consistently receive content for the next one.
QR codes on exhibit labels avoid the interference problem entirely, but they shift the burden to the visitor: they must notice the code, open their camera, and scan. NFC offers a middle ground but requires the visitor to physically tap a tag, which is impractical for fragile or elevated exhibits.
Events and temporary venues
At conferences and exhibitions, organisers often want to push session reminders, sponsor content or navigation prompts. The mistake here is deploying permanent-grade infrastructure for a three-day event without a removal and re-use plan. Temporary venues also introduce interference from other exhibitors' beacons, Wi-Fi access points and large crowds of bodies that absorb 2.4 GHz signals. A site walk-through with a Bluetooth scanner on the day before doors open frequently reveals conflicts that were invisible on a floor plan.
Document exceptions and remaining limits
Deploying without a radio-frequency survey
Mounting beacons based on a floor plan alone ignores what is actually broadcasting in your space. Existing Wi-Fi access points, other tenants' beacons, Bluetooth audio speakers and even microwave ovens share the 2.4 GHz band. A survey using a scanning app or a dedicated receiver reveals co-channel interference and helps you choose advertising channels and transmit power settings that will be distinguishable amid the noise. Skipping this step is the single most common cause of unreliable triggering.
Assuming accuracy without calibration
Beacon manufacturers quote ranges based on open-air line-of-sight conditions. A plasterboard partition, a glass display case or a metal-framed partition can reduce the effective range by half or more. RSSI values fluctuate with device orientation, antenna design and the number of people standing between transmitter and receiver. The only way to know what distance a given RSSI reading corresponds to in your specific room is to measure it with representative devices at multiple points and build a calibration table. Promising sub-metre accuracy without that measured data is misleading.
Treating consent as a tick-box exercise
Under UK data protection law and the UK GDPR, location data is personal data when it can be linked to an identifiable individual. Pushing notifications to a device based on its proximity to a beacon requires a lawful basis, and for marketing purposes that almost always means clear, specific, opt-in consent. Generic terms buried in a longer privacy notice, or consent bundled with app installation, do not meet the standard. You also need to explain what data you collect, how long you keep it and how the person can withdraw. Getting this wrong exposes the organisation to enforcement action and, more immediately, to visitor distrust that undermines the entire project.
Defining zones on paper instead of in situ
A zone boundary drawn on a CAD plan rarely matches the radio boundary on the floor. Walls, racking, ceiling height and furniture all distort the signal footprint. The practical approach is to define rough zones on the plan, install a subset of beacons, then walk the space with a test device and adjust placement, power or zone logic until the triggered content matches the physical location. Expecting the first configuration to be correct leads to complaints about wrong content appearing at the wrong place.
Choosing the wrong technology for the interaction model
Beacons are passive broadcasters; they cannot guarantee that a device receives a packet, and they cannot force a notification. If your use case requires a definite action at a specific point, such as verifying that a maintenance engineer reached a particular asset, NFC is more appropriate because the tap is a deliberate, confirmed act. If your use case requires reaching visitors who have not installed your app, beacons alone will not work. Matching the technology to the interaction model, rather than the other way around, avoids the most fundamental selection error.
Having no maintenance or inventory plan
Beacon batteries deplete. Tags get damaged or removed. Firmware needs updating. Without an asset register that records each device's identifier, location, install date, battery type and expected life, you will not know which unit has failed until a visitor reports missing content. A simple spreadsheet or asset-management system, combined with a scheduled replacement cycle, prevents the gradual decay that turns a working pilot into a broken live deployment.
Measuring nothing, or measuring the wrong things
Some deployments launch with no analytics at all, making it impossible to know whether the system is reaching anyone. Others fixate on raw impression counts without considering whether the notification led to a meaningful action. Useful metrics depend on the objective: for a retail offer, conversion or redemption rate matters more than reach; for a museum audio guide, completion rate and time spent per exhibit are more telling than trigger counts. Defining success metrics before the pilot, not after, ensures you collect the data that actually informs a rollout decision.
Skipping a real-visitor pilot
Testing with your own phone in an empty venue tells you whether the technology functions. It does not tell you whether visitors notice the QR code, whether they understand the permission prompt, or whether the notification timing feels natural when they are walking at their own pace rather than deliberately testing. A pilot with a representative group of real visitors, observed and surveyed, surfaces usability problems that no amount of bench testing will reveal.
Key checks before going live
- Has a radio-frequency survey been completed in the actual space during operating hours?
- Have zones been verified on foot with the devices your visitors will carry?
- Is consent collected separately from app installation, with a clear explanation of location use?
- Does each zone trigger content that is unambiguously relevant to that physical location?
- Is there an asset register with identifiers, locations and battery replacement dates?
- Have success metrics been defined and is the analytics pipeline capturing them?
- Has a pilot been run with real visitors, and have the findings been acted upon?
Proximity marketing is not a plug-and-play channel. It is a physical infrastructure project that happens to involve software and radio signals. Treating it as such from the outset, rather than discovering that fact mid-deployment, is the difference between a system that earns its place in daily operations and one that is quietly switched off after a few months.
Notification spam and privacy shortcuts
Two recurring failures are sending too many messages and treating a technical trigger as permission to market. Frequency should be governed across campaigns, not only inside one message flow. Privacy and PECR analysis should be completed before data is linked to a loyalty profile or used for direct marketing, with an easy objection or opt-out route.
