search

google / eddystone

Specification for Eddystone, an open beacon format from Google
Apache License 2.0
3.07k stars 761 forks source link

Questions: Caching and URL blacklisting/rating #240

Closed fdietz closed 6 years ago

fdietz commented 6 years ago

We currently ramp up more and more customers with Beacons and the Google Nearby API. In the process we noticed that the behaviour and performance is sometimes unpredictable and we hope you could help clarify things for us.

First of all our setup includes using a short URL (similar to bit.ly and others) which is registered with Google Nearby API.

Sometimes only a handful of requests (5 requests a day) are done on this short URL endpoint and sometimes a 100 per day. Note, that for our tests we verified by using the same beacons in the same locations and measured various URLs. Even though we don’t see requests on the short URL endpoint we definitely see notifications popup on mobile phones.

Is there some kind of caching involved? And if so how often do you clear the cache?

Additionally, is there any kind of blacklisting or rating for specific URLs happening which might affect our tests? And if so, is this blacklisting of URLs scoped on the specific beacon or somehow globally? We are kind of anxious to “burn” some good URLs in our testing phase.

If this is not the right place to ask these questions, we kindly ask you to point us to the right repo. Many thanks in advance!

helenclarko commented 6 years ago

What shortener are you using?

I have found that the google shortener would not register a hit for every visit. Bit.ly seems to handle this much better.

fdietz commented 6 years ago

We've run a lot more tests in the last couple of weeks with beacons and our own url shortener.

We found that using the same destination URL for 10 beacons leads to different request numbers than say 100 beacons. Whereas we've seen 50 requests/beacon (using 10 beacons), we only see 5 requests/beacon (using 100 beacons).

There seems to be a caching layer involved which is caching more aggressively when using the same URL with more beacons. To verify we generated "unique URLs" by appending query params to the same destination URL and this time the numbers don't change.

I'd like to add here that what we measure is just the Google Indexer hitting our URL shortener endpoint. For actual measurements we recommend using Google Analytics or similar on the destination URL. It is still valuable for us to measure these numbers since they loosely correspond to the foot traffic of a beacon relative to another beacon.