Foundation.mozilla.org: Implement Analytics Event tracking

[xmatthewx]

Building off of https://github.com/mozilla/network/issues/412, we'll wire up events listed in this spreadsheet

[xmatthewx]

@gvn @alanmoo @mmmavis – should we schedule a chat with @vojtechmzl on implementing GA Events? I know we have some experience, but I'm sure there are questions worth answering. We could look at how it's implemented in Pulse currently, so we can quickly dig into specifics. cc @taisdesouzalessa

[gvn]

AFAIK anything that's just a normal anchor link to another page should already be tracked by stock GA (eg: "home feature tap"). Can we confirm we actually need to wire everything on the spreadsheet manually? I wouldn't want to be logging things twice in two different ways.

@vojtechmzl can you look at the spreadsheet and give some guidance on what isn't already tracked?

I believe we'll just need to wire up buttons that trigger actions facilitated by JS (eg: menu open/close).

[vojtechsedlak]

Hey @gvn, you're right about the home feature tap event, if it's pointing to another page on the site, then we don't need additional tagging. I think all of the other events make sense, including the clicks on the sign up button in the header, which we should track to help us understand the full conversion funnel. Let me know if there is anything I can help with. Thanks

[vojtechsedlak]

For outbound links that point to other Mozilla sites, let's use the following standard set of URL params:

?utm_source=mozillaNetwork&utm_medium=referral

[xmatthewx]

For Homepage "Features", only some of those go to other pages. Some go out to external news (our Medium and 3rd party), some go to our other properties. While the destinations are different, the presentation to users is similar. However we track these, let's make sure we have a way to compare Features side-by-side so we can observe what drives people to dig deeper. Make sense?

[vojtechsedlak]

Hey @xmatthewx, the issue with tracking outbound links is that in order to log the event, we have to prevent the link from navigating to its destination until we create the callback to GA, which is not ideal for the UX. We can still track click-throughs to our sites by adding parameters to the URLs (e.g. utm_source=mozillaNetwork, etc.), but with other sites it is a bit of an issue. We can chat about this Monday, if that would be helpful.

[gvn]

Everything else in the spreadsheet is either done, or pending code review. I also updated it to reflect the current status...

[alanmoo]

@vojtechmzl I would think that would be the case for events on links within the site too, no? The event tracking for the homepage splash doesn't suspend the route change (to the signup page), but it seems to be tracking fine. Or is there a sneaky race condition bug in there?

[vojtechsedlak]

Hm, now I am not sure. @gvn, would it be possible to test adding in events for outbound links to external sites? My understanding was that events on links within the site are different, because the session GA cookie remains the same. I just came across this post, which shows how to use something called the browser beacon to submit the event on outbound links. Maybe we could try that?

[gvn]

@alanmoo : That is a link within the site, so I believe GA can just look at the referring page in the HTTP request. It's possible that it sometimes still logs a custom event, but I'd have to imagine there's a potential race condition there because a tracking image has to load before the page is exited. Whether GA is already doing some black magic with pausing outbound link clicks I'm not sure.

[gvn]

We can try this: https://www.npmjs.com/package/react-ga#reactgaoutboundlinkargs-hitcallback which is I believe using browser beacon under the hood.

[gvn]

However, I should mention that this is delaying outbound links until the tracking callback occurs, so again it's degrading UX for tracking purposes.

[xmatthewx]

As we said on video, we can move ahead to land other event tracking. Discuss outbound links later.