The visitor decision and value exchange
Notification frequency and timing refers to the rules that govern how often a single visitor receives proximity-triggered messages and the conditions under which those messages are sent. In a retail beacon deployment, these rules sit between the physical signal layer and the campaign content itself, determining whether a shopper who walks past the same display three times in one visit receives one notification, three, or none at all.
Two distinct concepts are often conflated. Frequency capping limits the number of times a specific notification or campaign can fire for a given device within a defined period. Timing control governs when a notification becomes eligible to fire, based on factors such as dwell time in a zone, time of day, or the interval since the last message was delivered. Both need configuring separately, and both interact with how zones are drawn and how beacons are placed.
Frequency caps are typically expressed as a maximum count per window: for example, one notification per zone per visit, or two per campaign per day. The window matters. A per-session cap resets when the app detects the device has left the venue entirely, whereas a per-day cap persists across multiple visits within a calendar day. Some platforms also offer per-hour caps, which are useful in high-traffic environments where a shopper might linger near a single beacon for an extended period.
Timing controls introduce conditions that must be met before the cap is even tested. A common pattern is a dwell-time threshold: the device must remain within the zone for a set number of seconds before the notification is eligible. This prevents messages from firing when someone walks briskly past a shopfront on the street outside. Another pattern is a cooldown period: after a notification fires, no further notifications from that campaign can fire for a minimum interval, regardless of whether the device leaves and re-enters the zone.
Quiet hours add a further timing layer. Retailers often suppress non-essential notifications outside trading hours or during predictable low-engagement periods, such as early morning restocking. These are straightforward to configure but easy to overlook when a deployment spans multiple time zones or when staff access the venue outside public hours and trigger test notifications that skew logs.
Implementation choices in the real venue
Entrance and welcome notifications
A welcome message at the store entrance is the most common starting point. The practical question is what happens when the same customer returns later that day. A per-visit cap handles this cleanly: one welcome notification per session, resetting when the customer leaves and returns. Without this cap, a lunchtime shopper who steps out and comes back receives a second welcome, which feels robotic and wastes the impression. Some retailers extend this to a per-day cap to avoid any repeat welcome, even across separate visits, on the basis that the customer is already familiar with the store that day.
Aisle and category-zone notifications
Category zones, such as a wine aisle or a footwear department, require different frequency logic. A shopper may genuinely enter the same zone twice during one visit, perhaps to compare items or fetch something they forgot. A per-visit cap of one notification per zone is often too restrictive here, because the second entry might represent a renewed intent to buy. A practical compromise is a per-visit cap of one notification per zone, combined with a cooldown of several minutes. If the shopper returns to the zone after the cooldown has elapsed, a second notification can fire, but rapid back-and-forth movement is suppressed.
Till and exit-zone notifications
Notifications near the till or exit are typically time-sensitive offers designed to increase basket value at the point of payment. Frequency here is less about caps and more about precise timing. A dwell-time threshold of a few seconds is appropriate, because customers at the till are moving slowly and the window to influence the transaction is short. However, if the till zone overlaps with an entrance zone in a small shop, the frequency rules for both zones must be coordinated to prevent a customer who has just entered from immediately receiving an exit-zone prompt.
Overlapping zones and priority
In most retail environments, beacon zones overlap to some degree. A customer standing near a boundary may be detected by beacons in two adjacent zones simultaneously. If both zones have active campaigns with independent frequency caps, the customer could receive two notifications in quick succession. The practical solution is a platform-level priority rule: when multiple notifications are eligible at the same moment, only the highest-priority one fires, and the others are either suppressed or queued with a minimum interval. Checking whether your platform supports this, and how priority is assigned, is an essential step before going live.
Seasonal and event-driven adjustments
Frequency settings that work during a typical trading week may become problematic during a sale event or seasonal peak. Footfall increases, dwell patterns change, and customers may visit the same store multiple times in a short period. Rather than reconfiguring every cap manually, some platforms allow frequency rules to be tied to campaign schedules, so a sale campaign can carry its own caps that override the defaults for its duration. If your platform does not support this, the alternative is to plan a configuration window before each major event and document the changes clearly.
Operational ownership and content maintenance
Over-notification and opt-out risk
The single most damaging frequency error is sending too many messages. Once a customer disables notifications or uninstalls the app, every subsequent beacon in the deployment is wasted on that device. There is no universal safe number of notifications per visit, because tolerance depends on context, message relevance and the customer's existing relationship with the brand. As a practical starting point, many UK retail pilots cap total notifications at two or three per visit across all zones, then adjust based on observed opt-out rates rather than assumptions.
Ignoring dwell time
Triggering a notification the instant a device enters a zone is appropriate for some scenarios, such as a welcome message at a wide entrance where brief passes are unlikely. In narrower zones, such as a specific product display, instant triggering produces notifications for customers who are simply walking past on their way to something else. Adding a dwell-time threshold of three to five seconds filters out most pass-through traffic without introducing a noticeable delay for customers who are genuinely stopping. The correct threshold depends on the physical width of the zone and typical walking speed, both of which should be observed on site rather than estimated.
Failing to test across real traffic patterns
Frequency rules that appear correct in a quiet pre-launch test often behave differently under real footfall. A common issue is that staff testing during off-hours move through zones slowly and deliberately, receiving notifications as expected, whereas real customers move in unpredictable patterns that expose gaps in the logic. Testing during live trading hours, even with a small subset of devices, reveals whether caps and cooldowns behave as intended when zones are busy and devices are moving in multiple directions simultaneously.
Not accounting for signal variance
Bluetooth signal strength fluctuates due to interference, body absorption and device orientation. A device standing just inside a zone boundary may briefly drop out of the zone and re-enter, which some platforms interpret as a new entry event. If the frequency cap is per-entry rather than per-session, this can exhaust the cap or trigger repeated notifications. Checking how your platform defines an entry event, and whether it includes a hysteresis or debounce period to ignore brief dropouts, is a technical detail that has a direct impact on perceived frequency.
Key checks before going live
- Verify that frequency caps apply per device identifier, not per beacon, so moving between beacons within the same zone does not reset the count.
- Confirm that cooldown periods are enforced even when the device leaves and immediately re-enters the zone.
- Test what happens when a device is detected by beacons in two overlapping zones with active campaigns, and confirm that priority rules or minimum intervals prevent double-firing.
- Check whether quiet-hour settings suppress notifications entirely or simply defer them, and ensure the behaviour matches your intent.
- Review platform logs after the first few days of live operation to identify devices that are hitting caps frequently, which may indicate either over-exposure or poorly drawn zones.
- Document the frequency and timing configuration for each zone and campaign, so that changes can be reversed or replicated without relying on a single team member's memory.
Frequency and timing configuration is not a one-time task. As store layouts change, campaigns rotate and customer behaviour shifts through seasons, the rules need revisiting. Building a brief review of frequency settings into each campaign planning cycle, rather than treating them as set-and-forget infrastructure, prevents the gradual drift that leads to over-notification and customer disengagement.
