Add GA for campaign tracking and instrument reporting form

[digitarald]

Right now it is hard or even impossible to track performance of the reporting form. Users are reported as "direct" referrals. The form can appear in /issues/new but also /.

• Add a UTM campaign when sending users from the Firefox integration
• Instrument the critical path for filing issues using GA events

[karlcow]

@digitarald hmmm… I was much in favor of getting rid of Google Analytics altogether. 😛
Could you explain a bit more why would we want to have more information about this? What do you expect of this information? And how do we plan to use it?

[zoepage]

@adamopenweb what are your thoughts?

[adamopenweb]

We had some discussions this week about increasing incoming webcompat reports.

It would be good to understand how effective each reporting path is. For example, we currently don't know how many people press the Report Site Issue button, but do not complete the form.

[karlcow]

It would be good to understand how effective each reporting path is.

This can be tracked already through the web requests without Google Analytics, we just need to collect the data in one place. Let's say as a thought experiment, we know, that 30% is coming from "Report Site Issue…" button in Firefox and 70% from the Webcompat site directly. What does it tell us? Are we able to have a meaningful action about it. I'm curious to better understand the goals. We currently have 3 paths.

• Addon to website
• Report Site Button to website
• Website directly

To really measure the data, we need to associate the browser version this is reported from because the pools are different (report site button is not everywhere) for example.

For example, we currently don't know how many people press the Report Site Issue button, but do not complete the form.

This on the other hand I'm super dubious. Both paths land on the website form. Knowing the bounce rate might tell us if the site form is crappy or not and not why and how. It's where we enter into A/B testing, where you can test two options with pool of users and see if there is a better option. And even here, I don't think we have enough users/reports to have meaningful data. Stats with small numbers are flawed.

The one thing I could see about the first stat is that we realize that only 0.1% of Nightly/devedition users use the Report Site Issue button. Then we can ask ourselves if it's worth the effort to keep it around. We can imagine we kill the feature inside Firefox and gives the real estate back to firefox dev team.

Why I'm pushing back for Google Analytics?

• As being mainly developed at Mozilla, I think we should do the maximum to minimize the tracking of users. Specifically if we have other ways to do the same stats without feeding Google.
• Our reporting users (Report Site Button) are on Nightly or DevEdition are likely advanced users with uBlock, AdBlock, etc. (Given the number of false reports we already already because people didn't realize that uBlock was breaking the site they were using). They will not be counted on a already low pool of users. The HTTP header stats will be more meaningful.
• If we still want to measure the bounce rate (I'm still not convinced 😜 ), we can probably do it from the form, by tracking the POST + HTTP header transferred to a hidden input field.

[miketaylr]

I think this is already in place for the form v2.