Web Share Origin Trial results (final; M57)
Matt Giuca
Summary
The Web Share origin trial started in Chrome 55 and ended after Chrome 57. We have now collected various feedback and are sharing it according to the Origin Trials process.
Intent to experiment: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zuqQaLp3js8
Previous email about the M56 results: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/rgIpGcOyDKI
Contact email
Spec and chromestatus.com entry
https://github.com/WICG/web-share/blob/master/docs/interface.md
https://www.chromestatus.com/feature/5668769141620736
Developer interest
Note: My previous summary was incorrect as of 2017-03-23: I reported 208 origins registered; the actual number as of that date is 234.
As the end of the trial (2017-04-17), 271 origins had registered for access to the origin trial (37 new signups since previous email). Of those origins, 62 had tokens renewed at least once for this feature (10 more than previous email).
We had a major client, Twitter, roll out Web Share usage in the trial’s final week (2016-04-11). They added a Share button to their new “Twitter Lite” progressive web app at https://mobile.twitter.com/ (at the time of writing, still accessible with the #enable-experimental-web-platform-features flag). A short conversation about this: https://twitter.com/necolas/status/851953474459676672.
Developer feedback
This feedback is based on the Origin Trial survey sent to developers who signed up for a trial key, and the bug reports on https://github.com/WICG/web-share/issues. There’s nothing new of interest here, just echoing the sentiments from the previous round of feedback.
An excellent developer write-up of the API: https://philna.sh/blog/2017/03/14/the-web-share-api/
We received the following new positive feedback (number indicates the number of new responses that echoed that sentiment):
Better user experience (4)
Easy for developers to use (2)
Being able to share to native apps (2)
Generic “works like a native app” (2)
User choice of share target (2)
Size / performance compared to third-party share plugins (1)
More share targets than an existing targets available on the Web (1)
The following requests came for improvements to the feature:
Bug (outstanding): navigator.share does not reject promise when user cancels picker (1)
Support from other browsers (1)
Requests for things we already plan to add in the future:
Web Share Target (ability for websites to receive shares) (2)
Improved documentation (1)
Support for sharing other media types (images, MediaElement, etc) (1)
Lessons learned from our goals for experimentation
See previous email.
Timeline
First stable release enabled: Chrome 55: 2016-12-06
Last date of token expiry: 2017-04-17
First stable release with feature disabled: Chrome 58: 2017-04-24
Usage data (UMA)
The following metrics come from UMA and are not adjusted for UMA opt in rates.
Note: We consider three metrics: Blink.UseCounter.Features.WebShareShare, WebShare.ApiCount.Share and WebShare.ShareOutcome.Success. WebShare.ShareOutcome.Canceled (and therefore the ShareOutcome bucket total) is currently broken (explained below).
Total shares per day (WebShare.ApiCount.Share):
At the beginning of this period, we were getting about 300 shares per day, following a slow ramp-up starting on 2017-03-08. This volume continued for the remainder of the trial.
Starting 2017-04-11, a huge spike up to 2.5-3.5k shares per day. Shares remained at this level until the trial ended on 2017-04-17. Presumably, most of this can be attributed to Twitter Lite.
This is only about a quarter of the volume we had on 2016-12-24 (13.7k) but was more sustained.
Number of page loads with a share (Blink.UseCounter.Features.WebShareShare):
This is the first release where this data was valid (UseCounter.Features wasn’t working in M56).
This data shows 200-270 page loads with a share per day (about 1/14 of what WebShare.ApiCount shows us). This suggests that on average, users make 14 shares per page load. It’s unclear how plausible this is; alternative explanations are that UseCounter isn’t always being recorded, or that a bot or automated testing tool is performing the bulk of the shares on a single page view.
Dialog acceptance rate (WebShare.ShareOutcome.Success / WebShare.ApiCount.Share):
During the large volume period after 2017-04-11, about 50--60% of dialogs were accepted. This is better than we had during the previous high-volume periods.
Notes on bad metrics:
Due to a broken API on Android, we are unable to detect dialog cancellation (https://crbug.com/636274). Therefore, WebShare.ShareOutcome.Canceled is under-reported, so we ignore it and just compare Success against the total Share count.