Geofencing: making a touchpoint work only in one place

What is actually being checked

This is the part that determines everything else, so it is worth being exact. Geofencing does not work out where somebody is. It asks the device, and the device answers only if the person has granted permission.

That single fact explains most of geofencing's behavior: why it needs permission, why it is more accurate outdoors, why it does not care about VPNs, and why it is a presence signal rather than a proof of location.

Zones and points

There are two ways to describe an area, and they exist because two quite different problems keep coming up.

An item can have several zones and several points attached at once. They are not combined into one big area — each is tested in turn, and the first one the visitor falls inside is the one that admits them. That means overlapping areas are harmless, and the practical way to cover a complicated site is several simple zones rather than one clever polygon.

The sequence a visitor goes through

Geofencing sits at a specific place in the chain of things that decide where a touchpoint sends someone. It is checked after protection and before your conditional routing rules. Knowing that saves a lot of confused debugging: a protected item will challenge for a password before it ever mentions location, and a location failure happens before any device or language rule gets a chance to run.

1. The visitor opens the touchpoint.
   Scan, tap, or click — it makes no difference here.
2. A location page appears instead of your content.
   This is the gate. It asks the browser or the Linxy App for permission.
3. Coordinates are tested against every active area on the item.
   Buffer or radius is applied first, then the point-in-area test.
4. If inside, a location session opens
   and your content is served. The session is what stops the visitor being asked again every few seconds.
5. If outside, or if no coordinate arrived,
   your deny message is shown, and if you set one, the visitor is offered a fallback destination.

Sessions, heartbeats and staying inside

Once someone is admitted, the platform keeps a lightweight session so they are not re-challenged constantly. Three numbers govern it, and they are fixed:

That last row is what powers the live presence view for an item, which shows who is currently inside a zone rather than who has ever been. It is genuinely useful at an event and slightly eerie the first time you watch it.

What happens outside the area

Two settings shape this, and both are worth filling in properly because this is the screen most of your unhappy visitors will see.

• Deny message. Write this for the confused, not the malicious. "You need to be inside the exhibition hall to open this" is useful. "Access denied" is not, and generates support contacts.
• Fallback destination. Optional, and the difference between a dead end and a graceful outcome. Point it at something a person outside the area can actually use — a public page, a schedule, a "find us" page.

Where several zones are attached to an item and none of them matched, the message and fallback come from the first zone that has them configured. In practice, if you attach multiple zones to one item, set the same message and fallback on all of them so the visitor's experience does not depend on the order they happen to sit in.

Accuracy, and what it means for your edges

Consumer devices are typically accurate to about 15 feet outdoors with a clear sky, and considerably worse indoors, in dense city streets, in basements, and in steel-framed buildings — exactly the places people run events. The device reports its own accuracy figure alongside the coordinates, so you can see how confident it was.

This is why the buffer exists. A zone drawn exactly to the walls of a hall will reject people standing just inside those walls, because their reported position wanders. The default buffer of about 80 feet is a sensible starting point for a building. Tighten it only when you have tested at the edges, and widen it when your zone is small relative to the accuracy you are getting.

Where geofencing is the wrong tool

Stated plainly, because getting this wrong is the expensive mistake:

• It does not prove location. The device supplies the coordinate, and a determined person can persuade a device to report a coordinate of their choosing. Treat geofencing as raising the effort required, not as evidence.
• It is not access control. If only certain people should see something, use protection — a password, or an invited-access Secure item — and add the geofence on top if the place matters too.
• It cannot work without permission. A meaningful share of visitors decline location prompts as a habit. Any design where a refusal means a lost sale needs a fallback path that does not depend on location.
• It is not a substitute for a ticket. Being in the building and being entitled to be in the building are different questions.

The right mental model: geofencing makes content feel anchored to a place and keeps casual off-site use out. Combine it with protection whenever the content would embarrass you if it leaked.

What it is genuinely good for

• On-site content. An exhibition label that only works in the gallery, a menu that only works in the restaurant.
• Event entitlements. Content, offers or networking that should belong to people actually attending.
• Regional integrity. Keeping an offer that is only valid in one territory from being used from anywhere else, in combination with location routing.
• Presence awareness. Seeing how many people are inside a zone right now, which is operationally useful in a way a scan total is not.
• Making a physical object matter. The most under-used case: a touchpoint that only works where the object is cannot be usefully photographed and shared.

Things people commonly get wrong

Related reading: Building and testing a zone, Why it says you are outside the area, Redirection controls, and Mark settings.