 Discoverability is important for your progressive web applications. Your PWA is still a web page that customers can find in their usual ways. You want to apply reasonable search engine optimization and ensure the page is available to search engines. You can use JavaScript on your pages and Google will index it as long as you follow some best practices. You can use the Fetch as Google tool from the Google Webmaster site to see how your app looks when crawled. Discoverability helps get customers to your site, but how can you measure their behaviors once they get there? That's where analytics comes in. Google Analytics is a service that collects, processes, and reports data about an application's use patterns and performance. Adding Google Analytics to a web application enables the collection of data like visitor traffic, user agent, the user's location, etc. This data is sent to Google Analytics servers where it's processed. The reports are available in the Google Analytics web interface and through a reporting API. Google Analytics is free and highly customizable. Integrating Google Analytics is simple. First, you must create a Google Analytics account. Each account has properties. Now these aren't JavaScript properties, but refer to individual applications or websites. Google Analytics then generates a tracking snippet for each property. This is a piece of JavaScript that you paste into your page. It sends data to the Google Analytics backend. You can also use the analytics library to create custom analytics such as tracking specific user actions or tracking push notifications. I want to say a bit more about properties. An account has properties that represent individual collections of data. These properties have property IDs, also called tracking IDs, that identify them to Google Analytics. If an account represents a company, one property in that account might represent the company's website while another property might represent the company's mobile application. If you only have one app, the simplest scenario is to create a single Google Analytics account and add a single property to that account. This is the key part of the tracking snippet. The entire snippet needs to be pasted into every page you want to track. At a high level, when this script runs, it creates an async script tag that downloads analytics.js, the analytics library. It defines the GA function called the command queue. It creates a tracker that gathers user data and it sends this data as a page view hit via HTTP request to Google Analytics. This data is analyzed and stored in your analytics account. In addition to the data gathered by tracker creation, the page view event allows Google Analytics to infer what pages the user is visiting, how long they are visiting them, and in what order. For simpler applications, this is the only coding required. Note, you can replace analytics.js with analytics underscore debug.js for console debugging. Using this version will log detailed messages to the console for each hit sent. It also logs warnings and errors for your tracking code. The data is sent to Google Analytics backend where it is processed into reports. These reports are available through the Google Analytics dashboard. Here is the audience overview interface. Here you can see general information such as page view records, bounce rate, ratio of new and returning visitors, and other statistics. You can also see specific information like a visitor's language, country, city, browser, operating system, service provider, screen resolution, and device. Here we are looking at the user city. It's also possible to view analytics information in real time. This interface allows you to see hits as they occur on your site. I encourage you to take some time and explore. There's an extensive set of features in the dashboard. You should explore the standard reports and look at creating your own. Knowing how to use analytics for improving your business or increasing revenue is a skill within itself. Fortunately, the Google Analytics Academy offers a free set of online courses. Google Analytics supports custom events that allow fine-grained analysis of user behavior. This code uses the GA command Q, which is defined in the tracking snippet. The send command is used to send an analytics event. Values associated with the event are added as parameters. These values represent the event category, event action, and event label. All of these are arbitrary and used to organize events. These custom events allow us to deeply understand user interactions with our site. For example, here we are sending a ViewMore event. This might be used to indicate that the user has viewed an item from our site. The event label tells us that it was a premium product. I mentioned earlier that you might use events to track push notifications. You can add events to fire when users subscribe or unsubscribe to push notifications, as well as when there is an error in a subscription process. This can give you an understanding of how many users are subscribing or unsubscribing to your app. Here we send a subscribe event letting us know that a user has subscribed to our notifications. Let's talk about what happens when analytics meet service workers. They won't work without a little help. That's because the service worker script runs on its own thread and doesn't have access to the GA command Q object established by the tracking snippet code on the main thread. It also requires the window object. Service workers must use the measurement protocol API instead of the command Q. This is a simple set of HTTP parameters documented at the Google Analytics site. Here's an example of recording when the user closes a push notification. The service worker manages the notification life cycle so it receives a notification close event. When the event fires, the service worker sends a hit via post with tracking ID, custom event parameters, and the required parameters for the API. Remember that we don't want the service worker to shut down before we complete the post so we wrap this code in event.waituntil. Since hits are effectively HTTP requests, they can't be sent if the user is offline. Using service worker in index DB, hits can be stored when users are offline and sent it a later time when they have reconnected. Fortunately, the SW offline Google Analytics NPM package abstracts this process for us. To integrate offline analytics, install the package in your project with the NPM install command. Then in the service worker script, import the offline Google Analytics import.js library and initialize the goog.offlineGoogleAnalytics object. This adds a fetch event handler to the service worker that only listens for requests made to the Google Analytics domain. The handler attempts to send Google Analytics normally. If the network request fails, it will be stored in index DB instead. The stored hits will be re-sent when online. You can test this behavior by enabling offline mode in developer tools and then triggering Google Analytics hits on your app. Index DB will show a list of URLs that represent the unsent hit requests. You may need to click the refresh icon inside the index DB interface to see them. If you disable offline mode and refresh the page, you should see that the URLs are cleared indicating that they have been sent. Now it's your turn. Go to the Analytics API lab. In there, you will create an account, add analytics to an app, look at the results, and make this work in a progressive web app. Good luck and have fun. If you're an instructor, this final slide links to more information on analytics. If you're a student, these links can be found in your textbook. You may want to use these while you are working on the lab. There are additional slides at the end of this presentation that show the major analytics screens and explain how to get there. Use these to deepen your knowledge or create live demonstrations.