Caching of Physical Web Destination URLs

[biteknight]

Issue - When using Google Chrome, upon URI sighting a ‘googleBot’ agent traverses all page re-directs and pulls the final destination url, title, and description. This data is then cached (across devices) for approximately 5 minutes and all interactions with this beacon in this time period will land directly on the final destination URL without going through the original redirects. Additionally cache busters are ignored even when they follow Google’s cache busting schema.

This presents two issues: Dynamic Query String Parameters are rendered essentially useless. Take Google’s physical web example of a smart parking meter. Consider the following URL structure: https://foo.com/xxxxx?time_remaining=42 where xxxxx represents the parking meeter id. and time_remaining is measured in minutes. The parking meter web app located at foo.com references both the meter ID and time_remaining attribute to set the page state when the user interacts with the nearby URI. Because Android and Chrome cache the entire URL for 5 minutes and subsequent interactions do not go through page re-directs, users will never see an accurate representation of the time remaining on the parking meter.

Accurate reporting is also made impossible when the destination URL differs from the broadcast URL. Fundamentally Eddystone beacons broadcast a short URL that may or may not direct users to a longer destination URL. Many users rely on reporting Physical Web interactions by counting the number of people who land on the broadcast URL. In this way popularity by beacon location can be captured and compared to overall page statistics. Because users are sent directly to the cached destination URL, reporting on a beacon level is not possible for experiences where the destination differs from the broadcast URL.

[adriancretu]

This is somehow related to issue 134

I see two problems with your logic:

1. You expect your user to reach your URL immediately after that URL has been obtained (PW is just a medium here). Nothing stops anyone from accessing your "42 seconds left" URL days later. You didn't even addressed any ping lag, or even maybe the URL was cached in a browser tab and visited hours later.
2. You expect an URL to be taken into analitycs account just because it might be an URL sent by an Eddystone beacon. Again, it's just a public URL.

Anyway, take a look at issue 134 linked above. The main idea to extract from that is that if you need "eddystone proximity" proof you need to go beyond PW and simple public URLs. You can take a look at my UriIO little project, which tries to solve this problem and also gives you correct timings of "users landing on your page". even if accessed days later.

[biteknight]

Looping in @mdamiani84 @artkay

[scottjenson]

Sorry @biteknight for the delay, we're all over at the Physical Web repo, not on Eddystone. I'm just seeing this now. I'll repost your question there so we can move this along.

I was wondering where you'd gone to... ;-)