Location-Based Notifications: Best Practices
Location-based notifications are messages triggered when a device enters a defined physical area or comes within range of a beacon, NFC tag, or QR code. Unlike scheduled push notifications, they depend on where the visitor is at a specific moment, which makes placement, timing and relevance far more critical to get right.
The most reliable deployments share a handful of practical traits. The notification arrives within seconds of the trigger, not minutes later. The content relates directly to what the visitor can see, do or buy at that exact spot. And the visitor has already opted in through a clear consent step, rather than being surprised by an unexpected alert.
A common mistake is treating location-based notifications as a general broadcast channel. If the same message appears at three different zones, the system is not working as intended. Each zone should have a distinct purpose and a message that only makes sense in that context. A visitor near the entrance needs different information from someone standing in front of a specific exhibit or product display.
Before launching, check three things against your deployment plan. First, confirm that every notification maps to a single, named zone. Second, verify that the trigger logic has been tested with real devices on site, not only in a developer environment. Third, ensure there is a straightforward way to silence or disable notifications without the visitor having to hunt through app settings.
How to Prevent Notification Fatigue
Notification fatigue sets in when visitors receive too many alerts in a short period, causing them to disable permissions or ignore messages entirely. In a retail or museum environment, where a person might pass dozens of beacons in a single visit, the risk is considerable.
The most effective countermeasure is a frequency cap: a hard limit on how many notifications a single device can receive within a rolling time window. The exact number depends on the venue and visit duration, but the principle is straightforward. If a visitor receives an alert at zone A, the system should suppress further alerts for a defined cooldown period, even if they walk straight into zone B.
Cooldown logic needs to account for the visitor's journey, not just time. A short cooldown of a few minutes may be appropriate in a large museum where zones are far apart. In a compact retail unit where zones are within a few metres of each other, a longer cooldown or a per-session limit is usually necessary.
Another useful approach is a daily or per-visit ceiling. Once a visitor has received a set number of notifications in a single session, the system stops sending until the next visit. This protects the experience even if the zone definitions overlap or the visitor walks back and forth through the same area.
Watch for these warning signs that fatigue is already a problem: a rising rate of permission revocation, declining tap-through rates over the course of a visit, or direct feedback from visitors about excessive alerts. If any of these appear, reduce the frequency cap before adjusting content.
How to Define Location Zones for Notifications
A location zone is the physical area where a trigger condition is met and a notification becomes eligible to fire. Defining zones well is the mechanical foundation of the entire system. Poorly drawn zones cause either missed triggers or duplicate alerts, both of which erode trust.
Start with the floor plan and mark the physical feature that gives the zone its purpose: a product display, an exhibit, a queue area, an entrance. The zone should cover the area where a visitor would reasonably stop or slow down, not the entire surrounding space. In practice, this usually means a radius of one to three metres around the point of interest for beacon-triggered notifications.
For NFC and QR, the zone is effectively the tag itself. There is no radius to tune, but placement still matters. A tag that requires an awkward reach or is hidden behind a surface will not be scanned, regardless of how well the notification is written.
When using beacons, the zone boundary is not a clean circle. RSSI values fluctuate because of signal reflection, human bodies absorbing the signal, and nearby metal or glass. The practical approach is to define a primary trigger radius and a suppression radius around neighbouring zones. If zones A and B are close together, the suppression radius around A prevents a beacon in zone B from firing while the visitor is still standing in zone A.
Document each zone with four pieces of information: the physical location on the floor plan, the beacon identifier or tag ID, the intended trigger radius, and the notification content assigned to that zone. Without this record, later adjustments become guesswork.
Message Personalisation and Context
Personalisation in location-based notifications does not require complex profiling. The most useful context signals are often the simplest: the zone the visitor is in, the time of day, and whether they have visited before. A first-time visitor at the entrance needs orientation. A returning visitor near a new exhibit needs an update, not a welcome message.
Loyalty status or membership tier can be used where the venue already holds that data through a separate system, but keep the integration practical. If the membership check adds noticeable latency to the notification, the visitor will have walked past the zone before the message arrives. The trigger-to-display time should remain under two seconds in most indoor environments.
Language is another straightforward personalisation axis. In venues with international visitors, detecting the device locale and serving the notification in the appropriate language improves relevance without requiring any additional data from the visitor. Check that your content management workflow can maintain parallel language versions for each zone, because inconsistent localisation looks worse than a single-language approach.
Avoid personalisation that relies on sensitive categories such as health, disability or inferred demographics unless the visitor has explicitly provided that information and consented to its use. Under UK data protection guidance, inferring characteristics from location behaviour and using them to tailor messages raises compliance risks that are rarely justified by the marginal improvement in click-through rates.
Quiet Hours and Frequency Caps
Quiet hours are scheduled periods during which the system does not send location-based notifications, regardless of zone triggers. In a retail setting, this might apply outside trading hours to prevent alerts from firing for staff or security patrols. In a museum or gallery, quiet hours can suppress non-essential notifications during scheduled events, talks or private viewings.
Implementing quiet hours requires coordination between the notification engine and the venue's operating schedule. If the schedule changes frequently, as it does in event spaces, the quiet-hour rules need to be updateable without a software release. A simple calendar or time-block interface in the management layer handles this.
Frequency caps, as discussed earlier, limit the number of notifications per device within a rolling window. The two mechanisms work together. Quiet hours handle predictable, venue-wide silences. Frequency caps handle unpredictable, visitor-level volume control. Relying on only one of the two leaves gaps.
When configuring frequency caps, test with the shortest plausible visit duration. A visitor who enters, collects an item and leaves may only be on site for a few minutes. If the cooldown period is longer than the average visit, some visitors will never receive a notification. Set the initial cap based on observed dwell times from your pilot data, then adjust.
Notification Content Design for Proximity
A proximity notification has limited space and a narrow window of attention. The visitor is physically in the venue, possibly moving, possibly with companions. The message needs to communicate its purpose within a second or two of appearing on the lock screen or notification shade.
The title should name the location or the immediate opportunity. "Near the Sculpture Hall" or "20% off in Aisle 4" tells the visitor why the notification appeared. Generic titles such as "New offer" or "Update" provide no context and are routinely dismissed.
The body text should contain a single clear action or piece of information, not a list. If the notification points to a web page, the deep link should go directly to the relevant content, not to a homepage that requires further navigation. Every extra tap between the notification and the useful content reduces the chance the visitor will follow through.
Keep the total character count manageable. On most devices, the visible portion of a notification before expansion is around 100 to 140 characters. If the core message does not fit in that space, rewrite it rather than relying on the visitor to expand the notification.
Include a clear end state for the interaction. If tapping the notification opens a page, that page should have an obvious next step: a button to add to basket, a play button for audio, a map showing the route to the next zone. A notification that opens a page with no clear action wastes the trigger opportunity and trains the visitor to ignore future alerts.
A/B Testing Proximity Notifications
A/B testing in a proximity context differs from web or email testing because the trigger event is transient. A visitor walks through a zone once, and the system has one chance to deliver a notification. There is no option to show a different variant on the next page load. This makes test design more constrained.
The practical approach is to assign variants at the device or session level. When a device enters a zone for the first time in a given period, the system randomly assigns it to variant A or B and serves that variant consistently for the duration of the test. This prevents the same visitor from seeing both versions, which would contaminate the results.
Test one variable at a time. Changing the title, the body copy, the deep-link destination and the trigger radius simultaneously makes it impossible to attribute any difference in performance to a specific cause. Start with the element most likely to influence behaviour, which in most proximity deployments is the title or the offer itself.
Sample size is a genuine constraint in physical venues. A zone might see a few hundred unique devices per day, and not all of those will have notifications enabled. A test that requires thousands of impressions to reach statistical significance could take weeks. Accept smaller confidence intervals for operational decisions, and document the limitations of the test rather than presenting inconclusive results as definitive.
Measure the outcome that matters for that specific zone. For a promotional notification near a product display, the relevant metric is whether the visitor proceeded to a purchase or interaction, not just whether they tapped the notification. For a wayfinding notification, the relevant metric is whether the visitor arrived at the destination zone within a reasonable time. Link the test metric to the zone's purpose, not to a generic engagement figure.
Operating rules for a useful notification service
Use explicit eligibility rules, frequency caps, quiet periods, deduplication and a simple preference control. A trigger should reflect a meaningful zone and a current purpose, not every moment a device crosses an unstable RSSI threshold. Measure dismissals, opt-outs and complaints alongside clicks and redemptions, and suspend a campaign when the evidence shows that it is not useful.
