URL shortening that tracks resolves?

[macpham]

Pardon me if this is a bit off topic.

I'd like to use Eddystone URL to advertise a web app. Is there a URL shortening service that can track the number of resolves so that I can distinguish between people reaching our app via beacons as opposed to other means?

I understand there is some privacy concerns on who resolves the URL.

I've seen a difference between goo.gl, bit.ly and tiny.cc and how Beacons advertising their URLs trigger any sort of click/counts.

I think tiny.cc is the only one that shows a click count that goes up however they return a:

X-Robots-Tag: nofollow, noindex

so we never get their notifications in Chrome.

[itsMattShull]

You and use our resort service https://aris.ai. Contact me via email and I can give you the API information to create and edit the long URL for each short URL and the API documentation for getting analytics. My email is mshull@aristotleweb.com.

-Matt

On Aug 2, 2016, at 3:18 PM, Mac Pham notifications@github.com wrote:

Pardon me if this is a bit off topic.

I'd like to use Eddystone URL Beacons to advertise a web app. Is there a URL shortening service that can track the number of resolves so that I can distinguish between people reaching our app via beacons as opposed to other means?

I understand there is some privacy concerns on who resolves the URL.

I've seen a difference between goo.gl, bit.ly and tiny.cc and how Beacons advertising their URLs trigger any sort of click/counts.

I think tiny.cc is the only one that shows a click count that goes up however they return a:

X-Robots-Tag: nofollow, noindex so we never get their notifications in Chrome.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mmocny]

Sorry, but at the moment, there is no way to use a redirector which is hosted on another domain to do click tracking through the Physical Web.

I suggest you instead use an analytics tracker on the final landing page (either via JS or via web-server), and track separate inbound campaigns by adjusting your destination URL slightly, to include a clue within the URL itself (e.g. by setting your beacon to .../some-deep-link?campaign=physical-web).

The reason is that we don't actually link users to URL shorteners. Or to any redirectors for that matter. We only ever send users to the final resolved URL after a chain of redirects.

We do this because we show page metadata and an expected URL to the user. When the user taps that metadata within our results list, we want to be as sure as possible that they will actually land on the page we said they would when they open it in their browser.

If we did link to the short-url as was encoded in the beacon, then the redirection chain could change when the user follows it and take them somewhere we didn't expect (via user agent sniffing, "random" redirectors, or just mutable-redirectors). This isn't hypothetical, it's actually quite common.

So today, if you have:

• Beacon URL: http://tiny.cc/imcjdy
• Redirecting to: http://physical-web.org
• Redirecting to: https://google.github.io/physical-web/

We will actually send the user to https://google.github.io/physical-web/ when they tap the result. And this works today with the above tiny.cc URL (I just tried). (Also notice that only the final URL was https.)

So click counts for tiny.cc cannot increase whenever users visit the website via a PW result.

Click counts may still go up sometimes for your redirector analytics, but only when our PWS crawler visits the page, not when the user taps the result. For developer beacons, those numbers may appear similar, but for real world traffic they will diverge quickly.

Also, our crawler does identify as Googlebot, so most short-url services should completely ignore these visits from their analytics results. Possibly tiny.cc does not (I am not sure).

Now, the above policy isn't perfect, and we are striving to improve it in a variety of ways while still doing the right thing for users in most cases.

Here is one example:

• Beacon URL: goo.gl/fake-short
• Redirecting to: fake-domain.com/fake-deep-link
• Redirecting to: fake-domain.com/fake-deep-link-for-desktop

The above is a contrived example where fake-domain redirected our crawler to a desktop version of the page. When users taps fake-domain.com/fake-deep-link-for-desktop from a mobile device, they are sadly not redirected to the mobile version.. but they would have been if only they visited the middle URL fake-domain.com/fake-deep-link.

Another example:

• Beacon URL: goo.gl/fake-short-2
• Redirecting to: fake-domain.com/fake-deep-link-2
• Redirecting to: fake-domain.com/login

In this case, our crawler did not have access to the middle URL resource and was redirected to a generic login page. This isn't great, but whats worse is that if a user taps that result, they are sent to the login page, even if they are already logged in. If they had just visited the middle URL, it could have worked.

So: we are shortly making a change to start linking users not the the last URL in the redirection chain, but to the first URL within the same domain as the last URL. (Thanks @oahziur!)

We think there are other ways we could improve -- both by being more permissive, and other times by being more restrictive. If you have any suggestions, please do share!

Hopefully you can track your analytics campaign using the suggestion I gave at the start, and hopefully the whole redirection situation is better understood now.

Cheers.

[wowpages]

So: we are shortly making a change to start linking users not the the last URL in the redirection chain, but to the first URL within the same domain as the last URL.

Shouldn’t it be the first https URL within the same domain? I am setting up my beacon URL’s as https, but I am redirecting all http requests to https in case it’s an older beacon, so I just want to make sure those will get picked up.

[macpham]

@mmocny Thanks Michal for the exhaustive explanation and useful suggestion.

[mmocny]

@wowpages Yes, you are correct, we will use the first HTTPS URL within the same domain -- I just forgot to mention the detail.

[macpham]

Is there something in Chrome preventing notifications from URLs with query parameters?

I've configured a beacon with a goo.gl'd URL that has query params, and I see it when I go to chrome://physical-web but never as any notification (both on Android and iOS).

[kanodia]

You can add UTM parameters to track URL's through physical web

[macpham]

Ah, yes. My mistake was the URL I was adding the parameters to was being redirected one more time.