Re: Web Install Meeting

Hey Ben & Kagami,

We have some data around ambient click-through rates that might be helpful.
We have this ambient install option via the 'omnibox install icon' in
Chrome desktop. The % of people who click on it vs shown was ~0.01%. We
thought this was pretty bad (why take up UX space if the clickthrough is so
low), and tried to run some ML experiments to try to show install UX at
more opportune times. (We definitely cannot remove it, as it's a
significant entry point for installation, and we have a significant chunk
of users using installed PWAs in chrome, but we want to improve). We are
still iterating here.

For "how good can a browser be at prompting for install" / "can an ambient
badge be useful" - on Android we ran an experiment where we started using
ML to train a model on page attributes and the user's visit history to show
a prompt here. As Kagami said - there is really no screen real-estate to
show an install entry point here in a reasonable way, so here the UX is a
bit more blocking.

So - this experiment should show something closer to the "ceiling" for
users wanting to install, kinda, as it's showing a blocking prompt, so the
users cannot just 'miss' seeing it or not understand it, like they could
with the omnibox install button.

See below - I think the most relevant thing here is the 1.2% click-through
in the random control group. To be specific, if you show a
prominent install UX for users (and I don't think you could be more
prominent than our Android install UX), then the best we ever got was
around 1.2% clickthrough, which IMO is bad. Especially because this is
blocking UX on mobile that blocks users from interacting on the site - it
can be really annoying!

We were able to, with ML, reduce the show rate 70%, which is really good,
and still achieve the same install rate. Howver, that clickthrough rate is
still ... not great! 3.2%

I think it's vastly superior for this UX to be a non-disruptive part of the
website where the developer can place it. While the in-site button might
also have a low clickthrough - it will at least not block users using
the page, etc (and that is only if devs always show it).  This is also why
devs really want it.

Or, another way to put it - if you rely on ambient badging, then likely
your UX folks will be bothering you saying "hey, why do we have this button
here, it has very low clickthrough". And I don't have evidence it's
possible for browsers to have enough smarts (well, without significant eng
investment in ML/ AI or whatever) to show the icon when the user actually
wants it. However - web developers need a way of telling users who want to
install their app HOW to do it - so if you only show the badge sometimes
based on smarts, that also ends up being annoying to devs as it's
inconsistent.

I also don't see the parallel with cookie consent and ads. How does install
compare with those? Cookie consent is regulation-related, ads are for
making the site money. Install is giving the user the option to experience
this site in a different UX. Sites have the ability to pull a 'fullscreen'
button on their page, but they only do that when it makes sense right? It's
obviously not a perfect comparison, but I would argue against the issues
connected with ads and cookie consent banners.

Dan


TL;DR
>
> ML Install Prompt has launched on Clank, offering better install prompt
> and CTR based on user value.
>
>
....


> We learned from UXR (link removed) that users prefer apps in certain
> circumstances and not others.
>
> Wherever possible the UI should only promote actions with utility to the
> user. We hypothesized that using machine learning to personalize app
> install prompts would create a simpler, more focused experience for most
> users, and target them towards users most likely to be interested would
> lead to more successful installs and a less intrusive user experience. This
> approach aims to better serve user needs by minimizing disruptive prompts.
>
>
...


> Prompt & CTR:
>
> Shown
>
> Clicks
>
> CTR
>
> Installs from prompt
>
> All Installs
>
> Control Group
>
> <redacted>
>
> <redacted>
>
> 1.2%
>
> <redacted>
>
> <redacted>
>
> Experimental Group
>
> <redacted>
>
> *%Δ -71%*
>
> <redacted>
>
> %Δ -23.95%
>
> 3.2%
>
> <redacted
>
> %Δ +7.37%
>
> <redacted>
>
> *%Δ +3.47%*
>
>
> Metrics highlights:
>
> We can observe that far fewer users are being disturbed and the CTR is
> much higher Key highlights:
>
>    -
>
>    70% reduction in prompt show rate while maintaining the same install
>    rates. The CTR is significantly higher than the legacy criteria (1.2% ->
>    3.2%).
>    -
>
>    Users are more engaged with installed PWA experience - With about the
>    same WebAPK installed, the experimental group shows 4% increase in WebAPK
>    launches
>
>
On Thu, Feb 12, 2026 at 10:06 AM Kagami Rosylight <krosylight@mozilla.com>
wrote:

> Hi Ben,
>
> I also had the same opinion in the last TPAC. One counterargument can be
> that it may not be feasible to show any UI element on mobile browsers, when
> they have limited UI area in the toolbar and often fully hides the toolbar.
> Adding anything to there can feel very intrusive to users.
>
> There was also some concern that if browsers start to show some extra UI
> for such explicit opt-in, then random websites may start to add the same
> manifest field, ending up the same UI being shown on every website.
>
> Another concern was that websites may want to have an in-page button
> rather than browser provided experience, but not sure how much I buy that
> argument. I think that's potentially because there's simply no good
> existing browser provided experience.
>
> Kagami
>
>
> On 12 February 2026 18:32:04 CET, Ben Francis <ben@krellian.com> wrote:
>
>> Hi Christian,
>>
>> Thank you very much for sharing the minutes of this meeting, and your
>> summary of the outcomes. I look forward to hearing more as the discussion
>> progresses.
>>
>> In the meantime I hope you don't mind if I share another perspective as a
>> smaller implementer, who no longer works for one of the big browser
>> vendors, but still has a commercial interest in the outcome of this
>> discussion.
>>
>> Firstly, I'm very glad to see this topic get some serious cross-vendor
>> discussion because I think getting this right could be really good for the
>> web.
>>
>> However, I have reservations about the solutions currently being
>> considered:
>>
>>    - The beforeinstallprompt event is a confusing and unpredictable API
>>    which is also likely to lead to nagging popups, banners or install buttons
>>    inside web apps
>>    - The navigator.install() method is more explicit and predictable,
>>    but similarly risks littering the web with popups, banners and install
>>    buttons
>>    - The <install> element is a clever declarative solution, but again
>>    risks littering the web with install buttons and is problematic for some
>>    classes of applications.
>>
>> My main concern is that the web is already plagued with interruptions
>> like ads, paywalls and cookie consent banners and moving the web app
>> install UI inside the viewport under developer control would just add to
>> the noise – further eroding the experience of web apps compared with native
>> apps.
>>
>> In my view the web already has a declarative solution for a web page to
>> point to a web app that can be installed, and that is a Web Application
>> Manifest <https://www.w3.org/TR/appmanifest/> linked using a manifest
>> link relation
>> <https://www.w3.org/TR/appmanifest/#using-a-link-element-to-link-to-a-manifest>
>> in a link element. I think the best solution to this problem is through UI
>> design, not API design..
>>
>> In my opinion, the user interface for installing web apps should be
>> trusted, consistent, easy to discover, but keep out of the way when it
>> isn’t needed. I think an "ambient badging" approach is the best way to
>> achieve this, with browsers visibly but subtly surfacing trusted
>> browser-native UI for installing web apps, which are treated as first class
>> citizens on operating systems.
>>
>> I've quickly put together a blog post
>> <https://tola.me.uk/blog/2026/02/12/how-i-think-web-apps-should-be-installed/>
>> which goes into more detail around pros and cons of the solutions currently
>> being considered, proposes an alternative solution with an example
>> implementation, but also acknowledges the hurdles that would have to be
>> overcome for this to become a reality.
>>
>> Kind regards
>>
>> Ben
>>
>>
>>
>> On Wed, 11 Feb 2026 at 21:08, Christian Liebel <
>> christian.liebel@thinktecture.com> wrote:
>>
>>> This is to inform the WebApps Working Group that the Web Application
>>> Manifest editors met with representatives from Apple, Google, Microsoft,
>>> and Mozilla to discuss APIs to allow developers to programmatically open
>>> install dialogs for web sites. Web sites are already installable across all
>>> major engines and operating systems. The goal of this effort is to enable
>>> developers to advertise installation more prominently from within their
>>> viewport.
>>>
>>> Here are the meeting minutes:
>>> https://docs.google.com/document/d/16OTq60o7pJMlQeO0KwuxzlMljsBZrt30LzpswQiP5Ko/edit
>>>
>>> Summary:
>>>
>>>
>>>    - The meeting participants decided to split the conversation between
>>>    installing the "current app," and installing "some app."
>>>    - The meeting participants favored the existing beforeinstallprompt event
>>>    for solving the "current app" use case. There is a draft PR to re-introduce
>>>    this event to the Manifest specification (
>>>    https://github.com/w3c/manifest/pull/1206). Gecko and WebKit
>>>    representatives have been asked to clarify their formal positions on
>>>    supporting beforeinstallprompt (pending).
>>>    - Regarding "some app" installation, vendors are asked to clarify
>>>    which install use-cases (same-origin, eTLD+1, cross-origin) they would be
>>>    willing to support (pending).
>>>    - The Manifest editors will schedule a follow-up meeting with the
>>>    participants in March.
>>>
>>>
>>> --
>>> Best regards,
>>> Christian
>>>
>>
>>