The Physical Web is a Google initiative making possible the linking of places, things and people with web content. It involves two pieces of hardware, a small device called a beacon and a variety of smart devices able to receive Bluetooth Low Energy (BLE) radio emissions. Set a beacon to broadcast a URL (a web address) and enable the smart device to receive and understand the message being broadcast. My personal collection of Eddystone BLE beacons has reached around two dozen units from four manufacturers. I have set each to broadcast a unique URL and some I change occasionally with a specific demo prospect in mind. I have lately been thinking about BIAs as prospects for several reasons, including: • a membership heavy on sidewalk merchants and service providers, and • the potential to “rent” a beacon network to brands, events and retailers, to name a few likely advertisers. I thought to link a prospect BIA’s website to a beacon and include it in the demo. It displayed properly on my smartphone but something about that created an itch that needed scratching. As often happens to me, the answer presented itself in the middle of the night. In some number of cases the content developed to appear in a successful search is quite different from the content an owner would want to present through a discovery on the Physical Web. Proximity and Context Take the BIA for example. A web search in Google or otherwise would likely come from a member, a prospective member or a local resident. The content presented would be useful to each, whether a membership directory, information on fees and services or upcoming events within the boundaries of the Improvement Area. But if I’m standing on the sidewalk, pull down my notification shade and see a link to the BIA site, what do I hope to see? Probably a menu that presents categories like “Food and Drink”, “Groceries”, “Shopping”, “Special Events”, “Theatres” and so on. I’d want to be able to select one and drill down to select Italian or Pub or Thai and I’d want a map or directions to each. I might want the link to open with a “You Are Here” spot, easy to do when the beacon I’ve discovered is in a fixed location. BIA management would, or should, see an opportunity here to sell membership based on inclusion in the discovery, and perhaps even banner ads or feature coverage, whether sold or offered on some rotation to interested members. I have used the word “discovery” more than once and perhaps an explanation is called for. Google’s approach to revealing Physical Web content intends it to be a passive experience, one the device user requests as opposed to having a phone vibrate or emit a tone. So you discover Physical Web content by swiping a screen to look for it. It is obvious in the image above that links discovered on the Physical Web appear very much like those in a search results page. When we use existing content the discovery includes the same text (metadata) a search presents. It’s not helpful to someone standing on the sidewalk. A further advantage to custom content for the Physical Web is the ability to write the metadata you would want the visitor to see. I know of a couple of third parties whose online dashboards provide a canvas for creating “cards” where words and increasingly images may be married to a link. This solution provides the opportunity to increase the likelihood of a visitor engaging with your content over some other beacon’s message. The “Now” Factor The only people who will see content on the Physical Web are those close enough to a beacon to receive its broadcast. So, by definition, most of the content presented should be relevant to here and now. That is of course why so much early content came in the form of a coupon or other offer to be used or taken up now. A useful feature of the Bluetooth beacon is the ability to set “working hours”. If a beacon is advertising a free cookie with a large coffee it shouldn’t be doing so when the coffee shop is closed. If an offer is good until four pm it should disappear at 4:01. The Physical Web has a unique advantage over every other form of marketing messaging I can think of in that the content available from any given beacon may be changed in seconds without touching the device. And with the right supplier, you don’t need a developer in the loop. Conclusion There is nothing inherently wrong with starting a beacon campaign with existing web content. Any positive message discoverable by nearby prospects beats silence. But the most effective messaging will result from giving thought to delivering the best possible experience. That isn’t always a deal. A new beacon user could do worse than to consider extending the reach of popular social media content to the beacon platform. Once a candidate for beacon messaging understands the opportunity, appropriate messages suggest themselves and the more time you spend in the space the more you see and can evaluate the merit of other user’s choices. For more coverage of Inbound and Social Media Marketing visit our Twitter and Facebook sites and sign up for the Friday Digest of breaking news on all things social, mobile and video. For a sample Digest, click here.
July 21, 2016 by · Leave a Comment
Follow @NetVideoMaker The initial exciting promise of Google's Eddystone-URL was that a beacon could broadcast a website address. Until that day about one year ago beacon broadcasts were directed to native apps. This was and remains a great capability for those who can afford to build and maintain an app that users value enough to return to often. But there are so many other situations in which useful or otherwise engaging content would be valued even if discovered just once. That Eddystone-URL does this so well has engendered some number of commercial efforts to improve upon the engagement and utility of delivering a web experience via beacon broadcast. My first encounter with a content creation platform specifically designed for the Physical Web came from an invitation to join a beta from Beeemapp. Using their cloud dashboard I could create cards or landing pages (the language varies) offering coupon, information and voting options which I could brand visually, include bar codes, images and text and then copy an assigned URL to direct a beacon to link to the content I made. At the same time as I was feeling my way around Beemapp I was much impressed with a cloud platform from Phy.Net, whose approach allowed for attaching a URL to any beacon registered to my account, and changing it on the dashboard in seconds - never any need to physically handle the beacon in order to check and change its settings. I have written about my experience with both cloud platforms here. This post is about a new feature just released by Phy.Net and it's a beauty. Behold the "Cover Card". a creation within Phy.Net's cloud platform that "covers" whatever URL you provide in the creation process. At time of writing only a logo will appear when discovered in an Android mobile device. iOS devices will see a larger image assuming one was used. Clearly one was in the image above, from Phy.Net's site. So I created a cover card today. The image above is a crop of what my Android phone displays when I swipe down the notification screen. (The red bars are my addition). If you compare the image to the one provided by Phy.Net you will note the similarity - a logo, and custom meta data below, but no larger image because they are available only to iOS devices for a few more weeks. Were I to click on the link I'd be taken to the retailer's specials page, which changes frequently. In this example, setting the cover card URL to a beacon means being able to change the meta data at will, and the image, without changing the destination month after month. Here's how the card looks in the dashboard's preview: It's probably worth mention that while the URL phy.net provides is secure, the URL I've provided "under" the cover is not. So, the Chrome browser will not display the retailer's specials page. The "Physical Web" app will. This is likely going to be the best thing that ever happened to https. Use it, migrate to it, or forget discovery from Google. Cover Cards offer a way to pop out from any screen filled with beacon discoveries and when they can display a large image in Android I predict they're going to get very hot very fast. Well done, Phy.Net. For more coverage of Inbound and Social Media Marketing visit our Twitter and Facebook sites and sign up for the Friday Digest of breaking news on all things social, mobile and video. For a sample Digest, click here.
June 1, 2016 by · Leave a Comment
Follow @NetVideoMaker Applications (apps) intended to be installed on Smartphones and tablets have been around for years. App Stores first appeared in 2008 and quickly became busy destinations. In 2013 Apple released a protocol known as iBeacon and various manufacturers built devices supporting the protocol in fulfilling its purpose of broadcasting a radio signal over Bluetooth Low Energy (BLE) which could be received by Smartphones and other mobile devices. (BLE, unlike previous versions of Bluetooth, has a tiny impact on battery life if turned on all day.) Apple introduced iBeacons to its retail stores and other retailers followed suit. In general terms, the purpose was to alert users of an Apple app that there was content available nearby. When thinking about iBeacons, it is helpful to remember that they are recognized by an app, to which the user gave certain permissions at the time of install. Those permissions might include the right to know your location, your name and other personal details, and this information allows the app provider to build a database about you – when and how often you visit, what you purchased, how long you were in the store, how you moved through the space and more. In return for divulging your personal identity, you are likely to receive offers, loyalty points, expanded product information and other value adds both in and away from the store. Apple’s iBeacon versus Google’s Eddystone Until the summer of 2015 the Apple iBeacon standard owned the road. Then Google introduced a protocol they named “Eddystone”, after a legendary British lighthouse. While Apple’s protocol is proprietary, Eddystone is open source, with several frame sets, the key one being Eddystone-URL. A beacon running the Eddystone protocol can be made to broadcast a URL, a web address that anyone suitably equipped (on both Android and iOS mobile devices) may receive, discover and choose to visit or not. And herein lies the key distinction between the two protocols. iBeacon needs a dedicated app to receive its broadcast. Eddystone’s signal can be received by the Chrome browser, the Opera browser, with others coming onboard. Dedicated apps are costly to develop, costly to persuade people to install, take up space on both the screen and in onboard storage, and only serve one master, which means the user has to be really attached to the app provider. Otherwise, the app will be ignored and likely deleted to make room for something else. Eddystone requires only the browser Android users are likely to have, and that’s more than a billion people. And the Chrome for iPhone version will receive Eddystone broadcasts too. App-less discovery of beacon-delivered content nearby is a game changer, and Google’s recent initiative, Progressive Web Apps, takes it to a new level. Google has created a toolkit for developers that allows the creation of websites that look and function like apps, including features like an icon on the phone’s home screen and offline functionality. What they don’t require is installation or updating because at heart they are delivered to the phone from the web. Here’s an example: This is the splash screen of the progressive web app created for The Washington Post. You can fetch it yourself from here. As you can see from the invitation below, accessing this content requires only a link, not an app install. And once you’ve clicked on the link sent to your phone you can choose to place an icon on your home screen, providing virtually identical access as to any real app you’ve installed. The PWA delivers on the promise of near-instant load times and scrolling shows virtually no lag. The jury is still out on how much content you can access once you’ve gone offline. I got some but not all. But further to the plus side, these apps never need updating, don’t take storage space and can be created at a cost that makes the solution affordable to many prospects that might not want to take on the cost of a custom app and the effort to get it adopted by a large enough audience who then must get attached to it or the effort is in vain. According to Google, every step in an app install decreases the number of people who will complete the process. From 1,000 who begin the process, something like 240 will complete the installation, and the number who go on to regularly use the app is deeply depressing to developers. As the politicians like to say, “make no mistake about it.” This development will be huge over time. Imagine receiving a beacon notification on your mobile Chrome browser inviting you to click through to content like the invitation above. In two clicks you have the PWA available. If the revolution in proximity, place and context has you by the throat, check back here from time to time. We’re on the story. For more coverage of Inbound and Social Media Marketing visit our Twitter and Facebook sites and sign up for the Friday Digest of breaking news on all things social, mobile and video. For a sample Digest, click here.