Why doesnt google provide beacon owner with physical web impressions?

[shailesh17mar]

I want to understand the philosophy behind this decision. If I as a beacon owner is running a informational campaign I should at least get to know if my notifications are even getting delivered or they are getting delivered but, ignored by the user since the notification text is not good.

[exogenesys]

Hello, @shailesh17mar!

There are multiple reasons for that and it is, of course, by design.

First of all, there are no 'notifications' to be 'delivered'. The user must ask to see the list of beacons available. And only after clicking on a link, users can opt-in for notifications, if available.

Secondly, The 'text' is the just tiny amount of metadata which is currently fetched from the web page itself. Exactly like we see in search engine results.

In my opinion, doing otherwise would be a privacy nightmare. I think we want to know about the physical things around us, we don't want the things to know about us. :)

To quote the documentation,

This has another advantage in that it means that a user can walk through a space and leave no trace: the broadcasting devices have no idea who is listening.

Also, this should be relevant.

The reason is to accommodate potentially the worst-case scenario of a large number of devices in an area with many people. A broadcast only approach avoids an N-squared problem of every user connecting to every device. By making each device broadcast constantly, any number of devices can just pick up the information passively with little conflict.

[shailesh17mar]

@exogenesys My goal is not to track users with Physical web beacons, my intent is to find out the reach of my messages i.e number of times the broadcasted message was detected my smartphones around. Because entire physical web ecosystem will be built around information & content. I think its not an ill-expectation to have some fair idea why someone is not clicking on the delivered physical web link. Its similar to 'WEB' where we put correct headings/ meta data and other things such that our content has that expected reach.

[dougdot3]

I wrote a post about this on BEEKn .net if anyone's interested.

It's totally understandable that we need to respect privacy but this 'black box' also makes it incredibly difficult to create a good user experience. Without the ability to get even some kind of stat how can developers tailor their messages to be more useful?

For both Physical Web and Google Nearby you want the notices to be useful. But there's no way to reliably A/B test the notification.

Even if there was SOME sort of way to aggregate data, get a percentage, or get "masked" data it would help I think make sure that both Physical Web and Google Nearby are as useful to end users as possible.

The issue here to me isn't what you quote in the documentation. The issue is that when a user IS exposed to the URL there's no way to know whether you're getting a 2% click through or 80%.

Again, I've always advocated for privacy. But we need some way to balance that against VALUE.

We can have 100% privacy respect but if we have no way of ensuring we're trying to be as valuable as possible then it's a tough trade-off.

[adriancretu]

Google will never be able to offer such insights for a very simple reason: it's impossible. How can one distinguish between the same URL being broadcasted by what beacon? It would just be useless stats to count every found URL and report back to... oh wait, you can't know who actually owns a URL... since the beacon is a public thing. But for "visited" stats we already have goo.gl & friends. There are imaginative ways by which you can accomplish "impression" vs "clicks" analytics just by playing around with the actual URL concept itself. Uniform Resource Locator. Make your beacons actual unique resources, in relation to space / time, and build up on that. Is it simple? Ofcourse not. Is it possible? Definitely. Remember that Google is not the only way a URL beacon can be detected, so I wouldn't rely on experimental projects such as PW or Nearby to tell me how people detect or interact with things.

[dougdot3]

Hmmm Adrian I think maybe I don't understand. When it comes to Nearby we know that Google has some sort of data because they've been "toggling" notifications based on success.

So, they have some sort of data which tells them how a beacon is performing otherwise they'd have no way to toggle the notification limits up or down.

What I'm suggesting is that it be considered both here for PW and for Nearby whether there are aggregated or 'performance' stats in some way that would be useful to generate. For example, for Nearby even a basic dashboard item such as "over-performing" or "under-performing" of notifications would be useful - which is clearly data they have but don't share. I understand why we can't get into detailed stats for privacy reasons but a simple green/yellow/red as an example would be a start.

I understand the technical limitations and I've built beacon projects across every conceivable platform and for dozens of companies and have written about this for 4 years. So I'm well aware of other ways to measure proximity success.

I do think a good discussion here about what forms of data might be useful to the community is of benefit because we all want a "win" for proximity, PW, Nearby, CloseBy, etc.

[adriancretu]

URLs are downranked, not beacons. From everything that has been said and done since the inception of PW in these few years, it was never meant as an advertisement/marketing platform, so things such as "beacon performance" have no meaning. It's like trying to measure performance of a TV ad when the viewer is not even watching TV, or the TV is closed (e.g. BT/Location/opt-in, device compatibility, user clearing all notifications, etc.). It's pretty obvious at this point that the intended use-case is for the user having to be aware of the beacon. To measure URL performance, you use URL-related tooling and clever work-arounds. The fact that they don't exist, that's another story.

[dougdot3]

Yeah I think where this is getting confusing is the conflation of Physical Web and Nearby.

With Nearby, the beacon I think is down ranked although that's opaque so you might be right. But you register a beacon with Nearby and the fact that it can deliver a URL or an app download etc I think might mean that it's down ranked on a beacon rather than URL basis.

Having said that, we're also not just talking here about "pure" Physical Web. We're talking about how PW is handled on different devices. In this case I think it's Google Play (or is it Chrome?).

On Google devices this means that the "developer" (aka Google) has control and code which presents a notice in the notification tray. Therefore, this notice can be tracked at the application level (aka Chrome or Play).

Therefore, it's entirely possible for Google to measure how many notices get presented because they 'own' the app which detects the PW URL and then presents it via the notification tray.

Very similar to how iBeacon is a "dumb" broadcast but you can measure its detection from within the app.

I take issue with "so things such as "beacon performance" have no meaning" - they can HAVE meaning if the various platforms, apps and operating systems agree that they should.

The PW broadcast itself is 'dumb' but the receiving devices can perform various metrics once that broadcast is received.

[adriancretu]

I highly doubt notifications are downranked at beacon-level, since the URL is the beacon itself (MAC address is not a persistent identifier whatsoever, same goes with Eddystone UID which I guess is what you meant). So, what happens if you broadcast a URL/UID and someone decides to spoof it with 100 other beacons? All the analytics and notification counting and whatever becomes useless, exactly as useless as iBeacon "measuring" :) Nearby is just a convenience UI to get a user from a PW beacon to its target destination, it's not a retail tracking analytics platform. If you have a URL/UID beacon and you get a website visit, and Nearby would tell you that someone tapped a notification, it would mean you've tracked the user (via the website hit) - so I highly doubt this will ever happen. And again, Nearby is not the only entry point for a PW beacon visit. What if someone used an app to detect the beacon? My point is, if you want to "measure" PW performance, forget about Nearby and its obscure "notifications" issues (grouped, hidden, min-priority, etc.) and focus on the actual URL advertised by the hardware. I'm just giving a hint that it is possible to separate "detected" URLs from "visited" URLs.

[dougdot3]

Great discussion Adrian. Thanks for all of this.

[dougdot3]

Sorry - so picking up on this one more time.

Using a Physical Web Service the end 'app' helps to address the issue of serving up the URL or notice.

This Physical Web Service serves up the meta-data:

"At the very simplest, it fetches, parses, and presents the content of Eddystone-URL packets on behalf of a client, but without using the client's identity in any way. It's a middleman added for safety and efficiency."

When the URL is parsed we can collect analytics that the phone has gone to fetch the title/notice etc from the trusted intermediary.

This trusted intermediary can collect stats:

Safer, because we can introduce safe-search filtering of inappropriate content. Better, because we can rank results based on various metrics, much as a search engine does.

You can see this in the example code:

> def webapp_add_wsgi_middleware(app):
>   from google.appengine.ext.appstats import recording
>   app = recording.appstats_wsgi_middleware(app)
>   return app

So where do these stats currently sit/reside? What is the trusted intermediary for, say, Google Pixel PW detection?

I imagine you can set your own trusted intermediary up for a Physical Web service within an app, but can you do so otherwise (I don't think the beacon packet itself does any direction to an intermediary but maybe I'm wrong?)

Just trying to understand your point.

It's sounding like you can set an intermediary up such as the Physical Web Service code provided and use it to track the number of times URL meta data is presented. Is this true?

[adriancretu]

I believe a diagram would sum up things better, but the point is: when a device (Nearby) requests a beacon's URL metadata via the PWS, and the URL isn't cached by the PWS, then obviously that URL gets hit, and you can detect that hit as coming from PWS. When the user taps the URL, you can detect as NOT coming as a PWS request. Hence, separate stats. Since the URL can get cached by the PWS, you get no hit (hence, no stats) when that happens. So, if you have one (or N) beacons, a single URL, and 10000 users around those beacons, and the PWS caches your URL during those 10.000 beacon detections, your URL only gets hit once during that time (until the cache expires). The solution to this problem obviously stands in the URL itself, as I already hinted several times. Use separate URLs, change them often, make sure they cannot be cached, etc. and build up on that to separate "detections" vs "visits".

[mmocny]

@adriancretu You are quite right about many things -- except I will add that there are costs involved with rotating URLs too often, or too intensely.

Yes, static URLs get cached, and you can work around this by rotating often. But URLs are also rewarded for sticking around and for performing well over time.

If your beacon changes to broadcast an entirely new unique URL too quickly, you will not build up reputation and rewards. You may even find that your results stop showing up at all.

[rcgbkon]

Let me add a few observations here: I am not sure that a PWS is a particularly good place to capture metrics. The Physical Web is open and there are multiple PW servers that scan beacons, so one has to aggregate scans from all PWS’s in order to have accurate scan metrics.

Curated PW content has benefits but it also makes PW signage somewhat dysfunctional. If I place a PW logo where I have a beacon and train users that there is PW content at my location, then it is a poor UX if the user cannot get to that content. The catchphrase “walk up and use anything” implies that the customer is in control, but there is currently not a deterministic way for a customer to control when any broadly available client application scans. This is further complicated if that client application opts not to display your content because it is curated.

Scan metrics are possible. The PW already typically uses shortened URLs. Given this, one can use a dedicated PW server and give every beacon a unique shortened URL, and then, even if all beacons redirect to the same destination URL, the scans can be accumulated from each individual beacon and from every serving PWS. Because the scanning PWSs are protecting the privacy of the consumers there is no way for these metrics to identify specific customers, though the location of the scans will be known because the installed location of the originating beacons are known.

[rcgbkon]

We are tracking the scan metrics of PW beacons installed in the wild, and see some consistency in the overall scan patterns. At the same time, we are working through controlled experiments to better understand when various PW client applications scan. We do see often see multiple scans from a PWS. Since we host micro-sites (the destination URL) on our server, we see customer taps to the redirect URL and are also evaluating conversion rates.