cannot get url redirection working with eddystone-url

[dasDaniel]

as far as I can tell based on docs, the only restriction is that the urls need to use https.

however I'm finding that there are either additional restrictions or something fishy going on...

if I enter google.com into my device (radbeacon usb), I can (on iOS) get it to show up on both physical-web app and in chrome's widget. if I change it to use a url shortener (custom or public) I only get it in the physical-web app, it does not show up in under the chrome timeline widget.

any ideas as t o why that is?

[ferencbrachmann]

Hey, you can get a list of things to watch for here: http://blog.beeem.co/2016/03/top-4-things-to-watch-out-for-on-chrome-for-android-with-beacons/

[wero1414]

Same here, i have an eddystone beacon, and since a week it doesn't show some url that certainly have HTTPS and some days back the beacon notification

[sabas1080]

+1

[ferencbrachmann]

@mmocny any thoughts?

I can report that - for example - even though http://b3m.it/B2000040 passes the validator and does show up in the nearby list, no notification is fired. When I use https://physicalweb.site all's good.

[wero1414]

We were doing some test and we find out that the nearby notification have problems showing up when the URL have sub-folders with links as "https://www.zonaturistica.com/atractivos-turisticos-en/1/aguascalientes.html" even shorted by goo.gl, but if we put "https://www.zonaturistica.com" it show the nearby notification

[timns]

This is a huge issue for us as well. I have phones literally side-by-side where one will always show the notification, and one never will. Both show the same link in the PW browser just fine.

I can only infer that Nearby is doing some internal checking and is, by mistake, thinking that URL is a duplicate or has been muted. Neither case is true on the phone where they do not show.

I would be very happy to help test this issue as it's making things very very difficult for us as a business.

[dasDaniel]

I have found (though not through official documentation) that in addition to https, the pages are required to use meta tags for titles, which are used by the google bot initially before showing the link.

[ferencbrachmann]

@dasDaniel True, but that's no secret. The Physical Web validator will tell you if that's missing: http://verify.physical-web.org

[jmartsch]

We also have a problem with notifications not showing on Android.

We run the website https://friendchip.net and provide our own Eddystone URL beacons that a preconfigured with a custom URL and profile. We do not use redirects, just simple URLs like https://fchip.net/f/hl9ozl4v or https://fchip.net/f/1.

Sometimes a notification appears after turning on the screen, sometimes not.

I also swiped away a notification when I did not want to open it, but it seems that it will never appear again. Swiping away a notification just means that is is not important this time, but other times I encounter the same URL maybe I want to see it. If you want to block an URL you can do that on the Nearby page. So please show every URL every time as a notification.

(EDIT) Addition: The Nearby FAQ shows: If the notification has been dismissed on a device recently, that device may not show another notification a period of time. The backoff policy is also reset if the user opens the Nearby section of Google Settings.

I don't think this is good. The notification should always be shown every time when a new scan happened, even if I swiped it away. What does "a period of time" mean? Minutes, hours, days? Please be more specific.

If I take a look at the Nearby page in Google Settings > Nearby then all URLs are shown. The metadata and validation via the validator for our URLs are fine.

This is really a huge issue!!! We need to rely on that notifications are shown (although we have an app that works better). One can´t sell a product based on Eddystone URL if sometimes it works and other times not.

Please fix this!

[ferencbrachmann]

Jens, I can confirm the behavior you've described. And it looks to be similar to what we experience (using redirects) on some very much used forwarder URLs. The only thing we know for sure:

1. The URL we see no notifications from has traveled all over the world with several high-density areas covered and has probably seen swipes from quite a few different phone users.
2. Page behind the URL is healthy and is displaying when other forwarders are used.

[dasDaniel]

I've set up my own redirection server, which improved reliability. For example, I've found that many link shorteners don't use https, which will prevent eddystone from working.

[timns]

We've seen that once a URL starts to show this behaviour, there's no way out of it. What we do now is get the beacon back, and put a brand new URL into its config.

There seems to be no way to recover a "poisoned" URL: once Nearby has decided it doesn't like it, you're screwed.

We've been spending the last couple of weeks fetching and re-delivering quite a few beacons because of this.

[jmartsch]

The Nearby FAQs say "The backoff policy is also reset if the user opens the Nearby section of Google Settings", but this seems to not be the case. I can´t get back the skipped URLs either.

[dasDaniel]

I can say the same, once a bad url redirect was cached by google, I ended up having to change the URL. Has anyone successfully seen a URL redirect get "unpoisoned" ?

[timns]

We tried a few things, like redirecting the bad URL to another target: no. Bouncing via a nice new goo.gl shortened URL: no. Getting the same phone that doesn't show that URL in Nearby to visit that URL: no. Rebooting the phone: no.

Once it's bad, it's bad on that device. Very embarassing. Where are the devs to weigh in on this?

[ferencbrachmann]

One of the "poisoned URLs we see is http://b3m.it/B2000040 Even though it was "poisoned" for the last 2 months or so I think that going in the Nearby menu and taping did reset it.

[jmartsch]

When looking at this answer in Google Groups https://groups.google.com/d/msg/physical-web-discuss/kyTEIdRcRcs/p8mkEMneAgAJ there also seems to be a backoff period if you clicked a notification

Ah. Yes, there is a backoff period for re-firing Notifications which were seen+tapped before.

What is the whole point of this? What if I find a company I searched for in Googles search results and clicked it, and the next time I search for that company it won´t appear in the search results, because I visited it once?

@scottjenson mentioned somewhere that their idea is that not one company controls the Physical Web. But with a scoring system and backoff period Google is just doing this (if you use Androids native Nearby function).

To me it seems there is not much movement in the Physical Web, as no developer seems to be around and give answers.