Then they proximity-fence these pairing requests so it only activates when they tap a device on a "pairing beacon."
Then they proximity-fence these pairing requests so it only activates when they tap a device on a "pairing beacon."
Here's how the system works:
1) User walks into the store and receives the first ping from a beacon (or other location-based trigger)
2) The platform/UA shows a bit of UI asking the user if they would like to receive LBT content from the entity - for example, Target.com.
3) There are 3 options: disallow, allow for this location (aka: "Just this Target store location"), or allow for all locations (as in: "Allow notifications from all Target store locations"
4) After selecting to see notifications for the location, or all the entity's locations, the user no longer needs to do anything, they just receive content directly from beacons within the location.
This eliminates the need for every app to listen for beacons, and beacons can now pass content URLs, which the platform/UA can open directly. This way, there is no vendor or walled garden dependencies. The system grows organically, and scales without micromanagement.
Do you understand how that works? I can try to answer any other questions you may have.
And in a more likely scenario, walking down a crowded street would trigger endless pairing requests.