What is Eddystone and the Physical Web?

To their credit, when Google decided that they needed an equivalent to Apple’s iBeacon protocol, they could simply have matched it for functionality and stuck a generic name on it, like g-beacon or something. They did neither; they created a different way for people to interact with beacons, and the name is delightfully obscure.
The key difference that Eddystone brings over iBeacon is, as standard, it allows for three packet types compared to the single ID packet type supported by iBeacon. It’s the second of these packet types, the accurately named Eddystone-URL, that we’re going to focus on in this post.
The normal way we’re used to beacons operating is to broadcast their presence to any listening apps in the area. This requires that the user has a native app, and in a situation where multiple beacons from different providers share the same location, they will actually be competing against each other for attention. The average consumer will rapidly reach saturation point and stop installing new apps just to interact with a new beacon. Google’s proposal to ameliorate this problem is called the Physical Web, and Eddystone-URL packets are a key component. Basically, instead of sending an ID packet to be consumed by a specific application, Eddystone-URL configured beacons announce a specific URL over and over in a standard format. Google is encouraging browser developers (and their own dev teams) to include support for this beacon protocol in their products. The ultimate aim is that when people see a beacon, or a Physical Web logo or notification of some sort, they take out their phone and load up a Physical Web enabled browser. At this point they’ll see at a glance all the Eddystone-URL enabled beacons in the area, forming the Physical Web around them. They can then select the one that caught their eye and use the normal web browser on their phone to access whatever functionality is presented to them through the URL. It’s a really clever adaptation of beacons which neatly circumvents their main adoption issue: the requirement for that beacon’s specific app.
If Google can succeed in getting traction for their Physical Web project, it could ultimately prove to be more useful for day to day discovery and brand to customer engagement than the traditional iBeacon format. It isn’t suitable for other applications like way-finding or movement tracking, however, so it’s a good job we have both types.
If you’d like to know more about Physical Web you can check out Google’s page on the topic, which has some interesting usages of the technology as well as a good video.