 If you're building an application that works offline, understanding how users are interacting with your app when they don't have connectivity is crucial to optimizing that experience. My name is Tom, and as you've probably guessed, in today's episode of Why Build Progressive Web Apps, I want to look at offline analytics. Modern web analytics frameworks make it easy to track all sorts of interactions within web apps, like scroll events, click events, navigation events, et cetera, and, of course, page views. Whenever one of these events happen, a request is sent to the analytics service, which then processes this data and convert it into nice-looking charts. However, they require a network connection to send data to their service, which means if connectivity is unavailable, those requests fail and will be missing from your analytics reports, like they never happened. Let's take a look at everyone's favorite PWA, airhorn.com. When you launch Airhorn, Google Analytics tracks a page view. And when you hit the Airhorn button, an event is being tracked based on annotations in the code. This works great when you're connected to the network. But what happens when the network connection goes away? The event isn't reported, and we have a blind spot. We don't know how Airhorn is being used, well, users are offline. And we are missing data about some of our users. Analytics requests are just regular network requests that can be intercepted by a service worker. The core idea for making offline analytics happen is to store these requests in a database. And then once the network comes back, replay them. You could write the code for doing this yourself. But we've already done it for you. Introducing Workbox. Workbox is a set of JavaScript libraries for adding offline support to web apps. The cool thing about Workbox is that you can mix it with your own service worker code. So for example, you can use your own network strategies but rely on Workbox for offline analytics. To use Workbox's offline analytics support, you just need two lines of code. Include the library and initialize the module. Let's have a look at how this works in practice. I've built a stripped-down version of Airhorn purely focusing on offline analytics. When the app loads, a page we event is tracked. When we horn the Airhorn, a horn event is tracked. And when we offline, none of these events will go through. And this is where Workbox comes into play. It stores the events in an index DB table so that once a network connection is restored, the previously failed requests are automatically replayed. An hourly leaked data is updated. You can also add an extra custom dimension so you can differentiate offline requests from regular online requests. Be sure to check the documentation for more. Thanks for watching this episode of Why Build Progressive Web Apps, and keep tracking offline. Or it didn't happen. I'll see you next time when we dive into some tips and tricks you need to know about leveraging lightning fast microsites for bootstrapping your progressive web apps.