Track GA event when we send a notification.

[ebidel]

In https://github.com/GoogleChrome/ioweb2016/blob/master/app/scripts/sw-toolbox/push-notifications.js#L69, we should send an event to GA using our IOWA.Analytics.trackEvent helper.

This will make it much easier to answer "how many notifications did we send" and we can also get the time series data.

[wibblymat]

This is actually non-trivial - IOWA.Analytics isn't available in the service worker, and analytics.js won't work either.

At first I thought I'd be able to just use the Measurement Protocol directly - send a simple GET request to GA with the right parameters. It can even hook into the offline replay code quite easily.

The problem is getting the parameters. The clientId, which allows the events to be correlated to other things the same client has done, is available in a window through the analytics library or by directly looking at GAs cookies, but there is no way to get it in a service worker.

You can postMessage from the SW to a window to retrieve the data, but that assumes that there will be a window already active when the push is sent, which is unlikely.

We could also gather the clientId when the window is open and store it somewhere, like in simpleDB. But this is making a copy of a tracking cookie, which I think the privacy team wouldn't like.

If the question we want to answer is simply about numbers of notifications sent and received then we can use something else as the client ID, losing the ability to associate it with other actions.

[ebidel]

All of that sounds a lot harder than I realized :\ I think the measurement protocol is what @gauntface did.

@philipwalton what happens if you send GA requests without a client id? Will the world fall apart?

From a pure numbers perspective, I guess we could just find out how many notifications were sent just by looking at server logs. So all is not lost. But it would be really nice to have this info in GA-proper to create live dashboards from. Seeing notifications sent over time is cool too. It's not necessarily important that we have correct session ids for that.

[gauntface]

Mine is super simple and very stupid. I was considering ways of adding data to the push that could be used in the push analytics but not sure that it would be overly useful.

[philipwalton]

@philipwalton what happens if you send GA requests without a client id? Will the world fall apart?

Yes, or rather, the hit would be invalid and not be processed.

Do users have to be logged-in to receive notifications? If they do, and you have access to the user ID, you could set that on the MP hit instead of the client ID. If not, you could just assign a random client ID to get a raw count, and then you could send an additional event or set an additional custom dimension (or whatever) if the user arrives on the site from a notification link.

[ebidel]

you could just assign a random client ID to get a raw count

That will inflate our actual user count, right?

For the latter, we have a utm_source=notification for tracking return visitors.

[philipwalton]

That will inflate our actual user count, right?

It would. One option is to send the hits to a different property.

I assume you at least have the ability of associating a particular user with a notification, correct? Even if you can't associate that user with the client ID in the I/O app, if you can accurately identify a particular user each time they receive a notification, then you could get an accurate user count (in this separate notifications property)

You could take that a step further and set that ID on the notification link and store that as a custom user-level dimension in the original property, allowing you to link the two at the reporting level.

If there's a way to share the client ID between service worker and client, that's probably the easiest though.

[ebidel]

I assume you at least have the ability of associating a particular user with a notification, correct?

Not until they reach the app (they click the notification and open IOWA). But before that time, we're in SW-landed. That exists in a world of its own, outside the page, and gets woken up by the push event. I think we'd need to a way for the server to know the GA client id and include that in the notification payload.