-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we suggest a means of tracking where a PWA was installed from? #19
Comments
Working with a partner on a store app, we have this need as well: to determine on the server whether a PWA was launched via Store or web. The current workaround is, as you described, a special start_url with query string parameter. But this isn't ideal and is easily circumventable by users casually browsing to the special URL. This referrer idea would solve our issue, allowing us to determine on the server where the PWA is being launched from. Limiting that to the initial navigation would suffice for our use case. |
Currently, Twitter accomplishes this by changing the UTM params for start_url for each store submission we make. Then, when the app launches, we read those params back to see where it was opened from. Because we are a SPA, this works OK as a stopgap. The approach of referrer suggested here might be even better since that would persist without additional work on our (or another app's) end. Plus it can piggyback the system we already use for referrer tracking. One interesting question to think about: imagine now I'm in the ESPN app, and I click a https://twitter.com link. This opens the installed Twitter PWA. What should I see in the referrer header? Do I get to know that the ESPN app (or site) opened me? Do I know that it's the Twitter App instead of Website? Are both possible? (I know broadly that noreferrer is becoming more common, but thinking aloud) |
I don't have any clients requesting this specifically but I could see it being very useful. Obviously some privacy considerations here, but it seems very in-line with how standard HTTP referers currently work. And then I could use GA or even serverside analytics to make better product decisions. For example, if I know the US, India, and Japan PWA traffic are all coming from different install methods, I could tune my marketing or in-app messaging accordingly. Right now I'm very ignorant of how PWA users arrived at being PWA users. I could also see this being beneficial for PWAs as a whole, so we could see which venues (win store, google play, chrome, edge, firefox, and heck even iOS) are doing better at converting to homescreen installs. |
If we introduce and ID field for the manifest, does that eliminate the cons for using the start_url? |
I wanted to update this thread: Starting with v93 (possibly 92 if we can backport the code in time), Microsoft Edge will begin adding a
To be clear: This header will only be included with the request for the first navigation of a web app and only if it was installed from the Store. The use cases we are working against are as follows: Use Case 1: A web app is doing a test release of their PWA only to users who install their site via the Microsoft Store. All other requests to the Use Case 2: A web app has in-app marketing that recommends installation via the Microsoft Store to users on Windows 10 (identified via UA identifier). If the app was already installed via the Microsoft Store, they do not want to include those promotions. If others are interested in implementing this in the same way, we are leaning on this spec’s
Addition of this capability to the App Info spec is currently stalled (#32), but if there is interest from other implementors, we can revisit that PR and try to include this optional feature in the spec. A note about our assessment of the Active Fingerprinting risk: The |
Apologies @comp615 I totally forgot to address this:
If there is a true referrer, that takes precedence. The implementation we launched in Edge supplies the store Still gathering use cases for the "is installed" signal which would give you both bits of info. |
I wonder if this can be negotiated by the app catalog and the app itself out-of-band of the manifest - especially if there is supposed to be payment involved / proof of purchase. |
I think payment / proof of purchase is a whole other ball of wax. |
Use case is disambiguation of the following:
Based on what’s out there currently, the first item is already covered. Numbers 2 & 3 could be aggregated by testing the
display
value (via JS and CSS), but would not be distinguishable from one another. In order to truly distinguish those installation sources, it would require the developer to author at least two separate manifests that have astart_url
with a unique query string parameter (e.g.,/?installed=web
,/?installed=store_name
). While doable, this approach could get out of control quickly as developers create unique manifests for each app catalog/store.To simplify things, we could piggyback on the existing
referer
header. Here’s what that might look like (all strings for presentation only):referer
(standard browser behavior)referer: "edge://apps"
referer: "store://www.microsoft.com/store/apps/windows"
This change in the behavior of
referer
could be limited to the initial navigation, which would make it quite similar to the query string approach in terms of analytics tracking.The text was updated successfully, but these errors were encountered: