 Installability is one of the biggest advantages of a progressive web app. Installing your PWA can make it easier for users to find and use. Once installed, it looks and behaves like every other installed app. Users don't have to go to an app store to get it. There's no sketchy files to run and there's nothing to download. But some users don't realize that they can install it. So it can be helpful to provide an in-app experience to promote and enable the installation of your PWA. Let's take a look at how the PWA install flow works, how you can provide your own in-app experience, and the best practices that you should be following for both desktop and mobile. First, the browser checks to see if the page meets the installability criteria. Is it served over HTTPS? Does it have a web app manifest with the required fields? Does it have a service worker with a fetch event handler? Has it met the user engagement heuristics? Essentially, has the user interacted with the page at least a little bit? And it makes sure that the PWA isn't already installed. If the criteria aren't met, the PWA isn't installable and the process stopped here. But if the criteria are met, the browser fires the before install prompt event, then shows the browser-provided install promotion. On mobile, that's the mini-info bar, and on desktop, it's the install chip that's shown in the address bar. The before install prompt event tells the PWA that it's installable and that it can show the in-app install experience. In fact, that's a really important point. To prevent confusion, don't show your own custom install experience until the before install prompt event has been fired. In the event handler, save the event so that it can be used later. Then show the in-app install UI. And to measure the effectiveness of the install flow, log it to analytics. There are many different patterns that you can use to promote the installation of your PWA. For example, a button in the header, some kind of promotion that's shown in line with other content, or a button that's shown at the end of a critical user journey. You can combine more than one of these techniques, but be careful not to overwhelm or annoy the user. And be sure to keep promotions outside of key user journeys and avoid disruptive patterns like interstitials. Let's take a look at the code. I've defined two global variables. Deferred prompt, which will be used to save the before install prompt event, and install source to help us understand where the install came from. In the before install prompt event handler, I like to call prevent default on the event. This will prevent the mini info bar from appearing on mobile. If you want it to appear, you can leave this line out. Then save the event to deferred prompt so that it can be called later. Next, show the in-app UI within your app. And finally, log the event to analytics. For consistency, all of my install events use the same category, PWA install. In this case, the action is promo shown, and I've set non-interaction to true, since this event wasn't generated by a user action. The UI is now updated, indicating that the user can install the PWA. Now the PWA just has to wait until the user clicks on one of the in-app install elements. Oh, with that click, the page calls prompt on the saved before install prompt event, causing the browser to show the install confirmation dialog. This is also a good time to hide the in-app install elements, and log in analytics event to measure the effectiveness of the install flow. Using the information from the web app manifest, the dialog shows the user the name and icon of the app, allowing the user to verify what they're installing. On Android, if the web app manifest includes screenshots and description, a new richer install experience will be shown. If the user clicks cancel or dismiss, the install stops, the browser returns to step one, and the flow starts all over again. Otherwise, the browser installs the PWA, switches the view to a standalone window, and fires the app installed event. So let's take a look at the code. To measure where the installs come from, set install source to the element ID or a unique value, indicating what element the user clicked. Hide the custom install elements, call prompt on deferred prompt to start the install, and show the browser install confirmation dialog. Then wait for the browser to resolve user choice, indicating the user has responded to the dialog. Two quick notes about prompt. First, to help prevent spamming users, calling prompt requires a user gesture. And second, you can only call prompt on each before install prompt event once. But as I mentioned before, if the user clicks cancel, the flow returns to step one, and you'll get a brand new before install prompt event. This is also why we hide the custom install elements in this step. If for some reason, the before install prompt event isn't fired again, you don't want the install UI visible. Now log the event to analytics. Like before, the category is PWA install, but now the action is promo clicked. Use the install source for the label to identify which custom install element the user clicked to start the install, and set the event value to either 1 or 0, depending on whether the user clicked accept or dismiss. In analytics, this will tell us what percentage of users completed the install for that specific element. If the user clicked dismiss on the install confirmation dialog, clear install source, so that if the PWA is installed later, the install isn't attributed to that element, then clear deferred prompt, since it can't be used again. Finally, the page needs to listen for the app installed event, indicating that the PWA has been installed, either through our UI or through the browser. In the app installed event, hide any in app install elements. They may still be visible if the user installed the PWA via the browser promotion, or if they have multiple tabs open and installed it in another tab, then log the event to analytics. So let's take a look at the code. First, hide the in app install elements in case they're still visible, then clear the before install prompt event since we can't use it anymore. Remember, the app installed event is fired in all open tabs, so to prevent duplicate install events from being logged, only log the event if the page is visible. Next, check the install source. Did it come from one of our elements in our UI, or if it's not set, it most likely came from the browser. Finally, log the install event. Let's take a look at the analytics for Squoosh to see how this looks. Under events, then top events. I'll click on PWA install, and it'll show me all the actions for that category. I see the number of times the custom install experience was shown, how often one of them was clicked, and can dive down to see which element was clicked and how often. In the case of Squoosh, we only have one install button. But looking at the event value, I can see that after clicking the install button, 69% of users clicked accept to complete the install. And looking at the details for the installed action, I can see what percentage of the install came from our custom install experience versus those from the browser. There you have it, the complete install flow for Chrome and Edge. Thanks for watching. You can check out these links for more details and the actual code that I used in the examples. I'll see you soon.