Your PWA is still a webpage 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 webmasters 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 applications, 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 customisable. Integrating Google Analytics is simple. First, you must create a Google Analytics account. Each account has properties, and 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 pasted into your page. It sends data to the Google Analytics back-end. 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 AS 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 pageview hit via HTTP request to Google Analytics. This data is analyzed in 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 GS with analytics underscore debug KS 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 the 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 G a 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 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 view more 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 meets 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 queue 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 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 this service worker to shut down before we complete the post, so we wrap this code in event. Wait until since hits are effectively HTTP requests, they can’t be sent if the user is offline using service worker and indexeddb hits can be stored when users are offline and sent it a later time when they have reconnected.
Fortunately, the SW offline, google analytics and PM 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, je and initialize. The google and google analytics object. This adds a fetch event handler to the serviceworker 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 indexdb. Instead, the stored hits will be resent when online. You can test this behavior by enabling offline mode in developer tools and then triggering Google Analytics hits on your app indexdb will show a list of urls that represent the unsent hit requests. You may need to click the Refresh icon inside the indexdb 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 analytic screens and explain how to get there, use these to deepen your knowledge or create live demonstrations. You
Jimmy's Internet Marketing Business Blog 