 Now that you know how to use Analytics for a website, do you know the secret to using it in a web app? Hi, I'm Sarah Clark, and I'm here to show you how to capture and analyze app activity. The problem is that user actions in an app are more than page views. In an app, a single page view might encompass multiple actions, such as checking and replying to email. So you can't just depend on the page loads to trigger the tracking snippet. The answer is to create your own custom Analytics events corresponding to actions in the app. Google Analytics supports custom events that allow fine-grained analysis of user behavior. This code uses the GTAG command, which is defined in the tracking snippet. Values associated with the event are added as parameters. These values represent the event category, event label, and a value. All of these entries are yours to define. These custom events allow us to dig into user interactions with our site. You can track aggregate events and event paths. Here's a sample of using custom events to track push notifications. You can add events to fire when users subscribe or unsubscribe to push notifications. Here we send a subscribe event, letting us know that a user has subscribed to our notifications. You should also track errors, such as errors in the subscription process. These can help you retain customers who might otherwise quit in frustration. Speaking of push notifications, you have to make some changes to use analytics in a PWA. The ordinary tracking snippets don't work. The problem is that the GTAG library, used by the tracking snippet code, depends on the window object. It also depends on being on the main thread. The alternative is to use the measurement protocol API, a set of standard HTTP calls, such as you would make with fetch. This is a simple set of HTTP parameters documented at the Google Analytics site. Here's a sample of sending a notification from the service worker. It reports when the user closes a push notification. The service worker manages the notification lifecycle, 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 wrapped this code with event.waituntills. But that raises the question of how we can send events when the app is offline. We can use IndexedDB to store events when users are offline and send them later when back online. If you use Workbox, this is built in. Just use Workbox's Google Analytics module to send your events. This adds a fetch event handler to the service worker that only listens for requests made to the Google Analytics endpoint. If an analytics network request fails, the handler stores the request in IndexedDB. It will then replay them when back online. You can test this behavior by enabling offline mode in developer tools and then triggering Google Analytics hits on your app. IndexedDB will show a list of URLs that represent the unsent hit requests. You may need to click the refresh icon inside the IndexedDB 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. Finally, here's a useful trick. When using the Google Analytics library, as shown in the previous slide, retried requests are indistinguishable from requests that succeed on the first try. This means you'll receive all the interaction data from offline users, but you won't be able to determine which interactions occurred while the user was offline. To solve this issue, we need to modify or annotate the data that gets sent in the retried request. One option is to specify the parameter overrides configuration option. This option lets you modify the measurement protocol parameters that get sent in the retried request. So even though Google Analytics does not have a built-in dimension for online versus offline interactions, we can create our own dimension for exactly this purpose using a feature called custom dimensions. Once we've created a custom dimension for something like network connectivity, we can use the parameter overrides to flag replayed requests as offline. 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. Thanks for coming all the way through this. Good luck and have fun.