Skip to content
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

Open
aarongustafson opened this issue Nov 12, 2020 · 9 comments
Assignees
Labels
enhancement New feature or request

Comments

@aarongustafson
Copy link
Collaborator

aarongustafson commented Nov 12, 2020

Use case is disambiguation of the following:

  1. Casual browsing to the PWA
  2. Installed via the browser
  3. Installed from an app catalog/store

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 a start_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):

  • Casual browsing to the PWA: no change to referer (standard browser behavior)
  • Installed via the browser (Edge): referer: "edge://apps"
  • Installed from an app catalog/store (Microsoft Store): 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.

@aarongustafson aarongustafson added the enhancement New feature or request label Nov 12, 2020
@aarongustafson aarongustafson self-assigned this Nov 12, 2020
@aarongustafson
Copy link
Collaborator Author

@JudahGabriel
Copy link

JudahGabriel commented Jan 28, 2021

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.

@comp615
Copy link

comp615 commented Jan 28, 2021

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)

@davatron5000
Copy link

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.

@dmurph
Copy link

dmurph commented Feb 1, 2021

If we introduce and ID field for the manifest, does that eliminate the cons for using the start_url?

@aarongustafson
Copy link
Collaborator Author

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 Referer header to the initial launch of any PWA that has been installed from the Microsoft Store.

Referer: app-info://platform/microsoft-store

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 start_url identified in the Web App Manifest are being redirected to their regular website.

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 platform values and inserting them into this template:

Referer: app-info://platform/PLATFORM_VALUE

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 Referer header’s contents is another potential source of passive entropy for fingerprinting a user which can, in turn, be used to help more distinguish an individual user from other users. For cross-site navigations, sites don’t control when the Referer header gets sent to them or with how much detail; rather, it’s based on the site the user’s coming from choosing the level of detail (note that some browsers restrict the max level of detail, but none more restrictive than strict-origin-when-cross-origin). Since the value this proposal inserts into the Referer header is approximately the same level of detail as an Origin, it’s not a significant expansion of context beyond what happens today with normal cross-site browsing flows.

@aarongustafson
Copy link
Collaborator Author

Apologies @comp615 I totally forgot to address this:

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)

If there is a true referrer, that takes precedence. The implementation we launched in Edge supplies the store Referer header only when the app is initially launched. So int he case of ESPN triggering a launch of the Twitter app, ESPN should be the referrer.

Still gathering use cases for the "is installed" signal which would give you both bits of info.

@dmurph
Copy link

dmurph commented Sep 13, 2021

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.

@aarongustafson
Copy link
Collaborator Author

I think payment / proof of purchase is a whole other ball of wax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants