Start with relevance rather than reach
Quiet hours and frequency caps are the two main mechanisms a venue or operator uses to stop proximity notifications from becoming a nuisance. Quiet hours define time windows during which the system will not push alerts to a visitor's device, regardless of their location. Frequency caps set a maximum number of notifications a single device can receive within a defined period, such as per hour, per visit or per day.
Neither concept is optional if you are running a live deployment. Under UK data-protection guidance, sending excessive location-based messages undermines the user's expectation of control and can render consent meaningless. The Information Commissioner's Office expects organisations to demonstrate that processing is proportionate. A visitor who opted in to "occasional offers near relevant displays" and then receives six push notifications in twenty minutes has grounds to argue the scope of consent was exceeded.
Quiet hours and frequency caps operate at different levels. Quiet hours are typically a schedule applied globally or per zone: for example, no retail notifications between 21:00 and 08:00, or no museum alerts during scheduled quiet-tour slots. Frequency caps are usually device-specific counters managed by the backend platform. They track how many times a particular device identifier has triggered a notification within the rolling window and suppress further pushes once the limit is reached.
The two mechanisms interact. A frequency cap of three notifications per visit still applies during active hours. Quiet hours then add a blanket block on top. Together they form the minimum responsible configuration for any public-facing proximity deployment.
From physical event to useful content
Retail environments
In a shop, the most common mistake is capping by calendar day rather than by visit. A customer who visits twice in one day could receive the full cap on each visit if the counter resets at midnight. A per-visit cap, tied to a session timeout (for example, no further triggers for 90 minutes after the last notification), better matches the customer's actual experience.
Quiet hours in retail should reflect opening times plus a reasonable buffer. If the shop closes at 20:00, setting the quiet window from 20:30 avoids edge cases where a customer is still browsing at closing and receives an alert that feels intrusive because the environment has shifted to end-of-day procedures.
Museums and galleries
Museum visitors often linger near a single exhibit. Without a frequency cap, a beacon at that exhibit could trigger the same notification repeatedly if the visitor's phone briefly loses and regains the signal. A per-exhibit cap of one notification per visit, combined with a minimum dwell time before the first trigger, prevents this.
Quiet hours in museums serve a different purpose. Some institutions schedule sensory-friendly or silent-opening sessions. During those windows, all non-essential notifications should be suppressed, even if the visitor has consented. This is both an accessibility consideration and a practical one: visitors attending a quiet session have a specific expectation that the environment will remain calm.
Events and conferences
Event deployments are temporary, which makes it tempting to skip configuration rigour. That is a mistake. A multi-day conference with beacons at each session room can easily bombard attendees if caps are not set. A practical approach is a per-session-room cap of one notification per session block, plus a global cap of no more than four or five notifications per day across the entire venue.
Quiet hours at events should align with the published schedule. If the agenda shows no programming between 23:00 and 08:00, the quiet window should cover that period. Some event platforms also allow per-track quiet hours, useful when one track finishes earlier than others.
Defining the cap period
The choice of rolling window matters. A "per hour" cap sounds controlled, but if a visitor arrives at 10:55 and triggers a notification, then another at 11:05, the hourly counter has reset and both are allowed. A sliding window (for example, no more than two notifications in any 60-minute period) is more robust but requires the platform to store timestamps rather than simple counters. Check whether your platform supports sliding windows or only fixed intervals.
Operational ownership and content maintenance
Setting caps without testing dwell behaviour
Beacons do not detect presence with a clean on/off signal. RSSI fluctuates as people move, turn their bodies or obstruct the line of sight with bags and other people. A visitor standing at the edge of a zone may repeatedly cross the trigger threshold. If your frequency cap is set to three per hour and the signal bounces in and out, those three slots can be consumed in seconds. Always test with real devices and real people moving naturally through the space before going live.
Ignoring staff devices
Staff who work in the venue all day will hit frequency caps first, which is actually desirable. However, if staff are using the same app as visitors, their capped state can skew analytics, making it look as though visitors are receiving fewer notifications than the system is capable of sending. Some platforms allow staff device identifiers to be excluded from analytics. If yours does not, factor this into your interpretation of campaign metrics.
Not communicating the cap to visitors
Visitors cannot trust a system they do not understand. If someone consents to notifications and then hears nothing for the rest of their visit, they may assume the technology is broken. A brief line at the point of consent, such as "You will receive no more than three relevant alerts per visit and none outside opening hours," sets the right expectation and reduces support queries.
Platform limitations
Not all proximity platforms implement frequency caps at the same level. Some enforce caps at the campaign level, others at the zone level, and a few at the individual beacon level. The distinction matters. If caps are per campaign and you run two campaigns in the same zone, a visitor could receive double the intended volume. Ask your provider exactly where the cap is evaluated and whether it applies across all campaigns or per campaign.
Key checks before going live
- Confirm whether the platform uses fixed-interval or sliding-window caps and that the behaviour matches your intent.
- Verify that quiet hours are applied in the venue's local time, not UTC, and account for daylight saving changes.
- Test what happens when a visitor is inside the venue when a quiet-hour window begins: does an in-flight notification get suppressed, or does it still deliver?
- Check whether caps reset correctly for multi-day events and whether the definition of "day" aligns with the event schedule rather than midnight.
- Confirm that suppressed notifications are logged for analytics purposes, not silently discarded, so you can distinguish between "no one was in range" and "the cap blocked delivery."
- Ensure that emergency or safety notifications, if you plan to send them, bypass quiet hours and frequency caps through a separate channel or priority tier.
Quiet hours and frequency caps are not a secondary configuration to revisit later. They define the boundary between a useful proximity system and one that actively damages the visitor relationship. Set them early, test them with real movement patterns, and revisit the thresholds after the first week of live operation using actual delivery data rather than assumptions.
