Define the decision and operating context
In proximity marketing, personalisation is frequently misunderstood. It does not mean greeting a visitor by name or referencing their purchase history the moment they walk past a beacon. In most real-world deployments, the practical distinction is between personalisation—tailoring a message to an individual based on stored data—and contextualisation—tailoring a message to the visitor's immediate physical situation. Both have value, but they rely on different data sources and carry different privacy obligations.
Contextual information comes directly from the proximity system: which zone the visitor has entered, the time of day, whether a particular exhibit or product fixture is nearby, and what the venue already knows about general footfall patterns at that spot. A museum can trigger audio about a specific painting when someone lingers near it. A retailer can highlight a promotion on the shelf the visitor is standing beside. Neither requires any personal data beyond the device's presence in the zone.
True personalisation adds a layer drawn from elsewhere: a loyalty tier, a saved language preference, a previous visit record, or an accessibility need. This demands integration between the proximity platform and another system—typically a CRM or app backend—and it requires the visitor's informed consent. Under UK GDPR and the Privacy and Electronic Communications Regulations (PECR), using location data to tailor messages to a identifiable individual is not the same as sending a generic zone-based alert. The legal and trust thresholds are higher, and the data-handling obligations are more demanding.
A common source of confusion is assuming that beacons themselves deliver personal data. They do not. A standard BLE beacon broadcasts an identifier; the receiving device or app does the rest. If the app has no profile data and no consent for personalised messaging, the system is limited to contextual content. That is not a shortcoming—it is a design constraint that should shape the messaging strategy from the outset.
Build and test the working approach
Retail environments
In a supermarket or department store, the most reliable form of personalisation is zone-level context combined with real-time stock or promotion data. If a visitor enters the wine aisle and the system knows that a particular label is in stock at that fixture, the notification can mention the product and price without any user profile. Where a loyalty app is in use and the visitor has consented, the message can additionally reference their tier—offering an exclusive discount, for instance. The practical question is whether the loyalty integration genuinely adds enough value to justify the extra data processing. In many cases, a well-written contextual prompt performs as well as a weakly personalised one.
Museums and galleries
Context is the primary tool here. A visitor near a specific exhibit can receive interpretive content keyed to that object. If the venue's app stores a language preference or an accessibility setting (such as large-text or audio-only mode), the same trigger can serve a localised or adapted version. The personalisation is narrow and functional: it removes friction rather than attempting to profile the visitor's interests. Attempting to recommend "similar exhibits you might like" based on dwell time is technically possible but often unreliable, because a long dwell may indicate interest, a queue, or simply that the visitor has stepped away to take a phone call.
Events and conferences
Event apps lend themselves to slightly deeper personalisation because attendees typically register with a schedule and session selections. A beacon near a seminar room can push a reminder that references the session title the attendee bookmarked. Context still does the heavy lifting—the room location, the start time, the fact that the attendee is approaching—but the personalisation makes the message specific enough to be useful rather than dismissible. The limitation is data freshness: if the attendee changed their schedule on the web portal but the app has not synced, the notification will reference the wrong session. Checking sync frequency is a practical necessity, not an edge case.
Layering context signals
The most robust deployments combine multiple low-risk context signals rather than relying on a single high-risk personal data point. Time of day, zone, dwell duration, and known venue conditions (a queue at the till, a sold-out session) can be layered into simple rules: If zone equals entrance hall, and time is after 14:00, and average dwell in this zone is under 30 seconds, show the "quick visit highlights" message. No personal data is involved, yet the message feels relevant because it matches the visitor's apparent situation.
Keep the service useful as conditions change
Assuming zone entry equals interest
People pass through zones for many reasons: a shortcut, a queue, a lost companion, a toilet sign. Triggering a product promotion every time someone enters a zone produces irrelevant noise and trains visitors to ignore notifications. The practical fix is to add a dwell threshold or a secondary signal—such as the visitor slowing down or approaching a specific fixture—before firing the message.
Using stale profile data
A loyalty tier that changed three months ago, a language preference set on a device the visitor no longer uses, or a dietary requirement that has since been updated can all produce messages that are not just irrelevant but actively off-putting. Check how often the proximity system refreshes profile data from the source, and set a maximum staleness window beyond which the system defaults to contextual-only content.
Over-personalising and crossing the comfort line
There is a point at which personalisation feels like surveillance. A message that says "Welcome back, you were here last Tuesday" may be acceptable in a small independent shop with a genuine relationship; in a large retail chain it is more likely to unsettle. The test is not whether the data is legally available but whether a reasonable visitor would find the message helpful or intrusive. If in doubt, default to context.
Relying on a single signal
Beacon RSSI values fluctuate. A single reading that places a visitor "in the shoe department" may be a momentary spike from an adjacent aisle. Personalisation that changes the entire message based on one unreliable signal will produce jarring errors. Use confirmation logic—consistent readings over a short window, or a combination of beacon and other inputs—before switching from generic to personalised content.
Key checks before going live
- Consent audit: Can you demonstrate which visitors have opted in to personalised messages, and what they were told at the point of consent?
- Data freshness: How often does the system pull updated profile data, and what happens if the source is unavailable?
- Fallback content: If personalisation data is missing or stale, does the system gracefully revert to a contextual message rather than showing an error or a blank?
- Relevance test: Would a reasonable visitor in that zone, at that time, find the message useful enough to act on?
- Frequency interaction: Does the personalisation logic conflict with frequency caps or quiet-hour rules configured elsewhere in the system?
- Sync verification: For event or loyalty integrations, have you tested what the visitor sees when the source data has just changed but the proximity platform has not yet caught up?
The most effective proximity messages are not the most personalised. They are the most relevant to the moment the visitor is in. Context provides most of that relevance at a fraction of the data-handling complexity. Personalisation should be added only where it demonstrably improves the visitor's experience and where the consent, data quality and integration work can be sustained over time.
