Google Loves Apple (In a World of Beacons)

google-eddystone

 

The launch of Eddystone by Google has, at long last, addressed a challenge in creating proximity experiences with beacons. Namely, that the software tools for beacon detection and interaction were less robust for Android development than for Apple devices.

The media narrative, as always, paints the move by Google as a showdown between Eddystone and iBeacon.

Mashable calls Eddystone a rival, Ars Technica announces that iBeacon needs to move over because Eddystone is a fighter, and Tech Republic concludes that it has clear advantages in the showdown with Apple.

Now, you can’t blame the media. It makes good copy.

If Google launched some kind of self-driving toilet paper the media would call it a rival to the iPad, siphoning off valuable screen time from its arch enemy in Cupertino.

And while there’s a broader truth to the Apple v Google narrative (which I’ll get to in a minute), the truth is that the move by Google has made life easier for brands, retailers, developers and device manufacturing companies.

What Your Clients Need to Know

If you work in mobile development you’ll know that the last thing your clients need to hear is that there’s yet more fragmentation – between Android devices, between Apple and Android.

The good news is that, at the simplest level, Google’s announcement of the Eddystone beacon format (and the accompanying development tools) means that we can now create beacon experiences for both Android and Apple devices in a way that assures a higher level of confidences that the experiences will be on par.

Better yet, Eddystone has added a few tricks to how beacons work that will benefit both Apple and Android apps. These tricks include the ability to embed beacon management functions inside your app (instead of needing to rely on some type of admin app or cloud beacon), a promise of increased beacon security, and the ability to link beacons natively to web URLs.

By launching an open specification and leveraging the capacity of beacons to interleave multiple signals, brands, retailers and venues can get the best of both worlds:

  • Android apps that respond as fluidly to beacons as Apple apps
  • Access to new beacon features across both platforms
  • No need to buy new beacons – especially if your hardware provider is one of Google’s preferred manufacturers (and we note that almost all of them are our own!). Just update your firmware and you’re good to go.

There’s No App For That

The second part of the media narrative about Eddystone is its capacity to deliver a URL in place of a unique identifier. The promise is that on Android, you’ll be able to deliver messages without an app.

Part of this promise will be reliant on what Google releases with Android M so it’s too early to judge how deep this promise will go. We’ve long speculated that the secret war horse for Google will be Chrome – a trojan horse on Apple devices that could conceivably contain beacon detection and help Google bypass the gatekeepers in Cupertino.

Regardless, the capability of reaching consumers without an app isn’t confined to Google.

Apple has been using Passbook to trigger beacon interactions and will be extending this through Offers, a new iAd “wrapper” on Apple Wallet. We assume that this will allow brands to target iAds based on location and allow the delivery of Wallet Offers (similar to Apple passes) which embed beacon detection (as previously available).

So while it’s a compelling value proposition – the ability to bypass apps entirely, it’s not confined to Google.

Who Owns The Experience?

It’s when we look beyond the beacon that the Google v Apple narrative starts to make a bit more sense.

Both Apple and Google give you tools to register your “place”. Both want to help you map your indoor location. Both want to provide “contextual experiences” through Siri, Google Now, and search.

And both want to serve ads:

  • Google wants to use all the data it can get to serve better (and more) ads across more platforms (including iOS)
  • Apple wants to generally keep the data anonymous but still wants to make money through its iAd platform.

Apple’s main focus is the user experience, and we can expect to see more and more tools to integrate beacons into payments, Apple Wallet, in-home connectivity, and location-based context. Google’s main focus is giving users better and better free tools and applications but in the larger service of ad revenue.

Neither approach is bad for brands or venues. But each provides strategic pros and cons – from sharing your data about your customers with Google through the lack of access to individual user data on the Apple platform.

But these trade-offs and decisions have nothing to do with the beacon. The choice to integrate that beacon, to make Google aware of its presence, to integrate it with Google Now (with the benefit of “app-less” consumer interactions but with the cost of providing Google data about your customers) are strategic ones.

As a retailer, you’re faced with the same questions you’ve already struggled with: who owns the data about what happens in your store, and are the trade-offs worth it?

But, again, those questions have nothing to do with the base function of the beacon, and are supplemental decisions about how far you want to go with Eddystone.

For now, it’s enough to know that beacons just got better, and users of both Apple and Android devices will benefit from the innovation.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

What do you think? Google has clearly done Apple one better with Eddystone. But is it really a “threat”? How will you use Eddystone?

6 Responses to “Google Loves Apple (In a World of Beacons)”

  1. Good post Doug. I also think that it’s a nice addition to the technology stack we can already work with, it brings even more options to the table to tailor a solution for the clients.
    Up to us not to confuse the clients with too many options to choose from.

    Reply
  2. It will be interesting to see what Apple does to Ibeacon to compete with Eddystone. My CMS is setup for Ibeacon only so I am curious to know from a code standpoint can the two work together, or do we have to give up Ibeacon base code and adopt Google’s.

    The biggest challenge I see with Ibeacon is the requirement to have a mobile app to interact with beacons. By using the eddystone URL, this totally eliminates that friction and makes it a no brainer.

    Looking forward to see how this plays out before I consider transitioning over.

    Reply
  3. Andres Ursueguia

    I agree that Eddystone will add value to the beacon world. For us the beacon developers (we develop software and hardware) that menas the beacon world has been reinforced, due that the “two bigs” are spending efforts on them. Sounds good for the future of beacons and give us some tranquility that our work is not going to the trash in a short term.

    But I don´t see Edystone as the only move Google has made…remember they give us now the Proximity Beacon API, or as I have understood a “free” cloud storage system (ibeacon compatible)…..
    This can be a good point to discuss also…because I don´t know about anything similar on Apple.
    Many companies have seen business on this cloud services, and maybe this Google move will affect them seriously…

    Nice article, like always.

    Reply
  4. Hi Doug, we missed you!
    Yes, Google’s announcement of the Eddystone beacon format will help to push the awareness for location aware mobile services with beacon technology.

    But I have also some concerns about the user experience with the Eddystone URL capability:

    1. How can the user block some selected aggressive Eddystone URL campaigns?
    How can the user control and deactivate the call of specific Eddystone URL’s?
    Is there a kind of blacklist service to block crazy spamming campaigns?

    2. What if the Eddystone URL campaign calls the browser but the internet connection is very slow or not working? Do you only see a white empty page without a glue?

    3. How can the user control and limit the maximal number or frequency of Eddystone URL campaign calls to avoid excessive spamming campaigns or battery drains?

    I hope the marketers don’t use the cool Eddystone URL capability to implement a massive location aware spamming service within our cities and will harm and kill our beloved Beacon technology.

    What do you think about my concerns?

    Reply
  5. Awww thanks Florian! We’ve been so bloody busy – who said doing a start up was a good idea???

    I’m with you on Eddystone questions – but I think the way they’re handling it is via Chrome Today. So it will be one of those “evidence of absence isn’t absence of evidence” kind of things. HAHA

    In other words, I have a sense that the way it will work isn’t so much push as contextual. But I guess we’ll see now that we can get Chrome on iOS going! Will try to run some tests this weekend and see how it looks.

    Reply

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>