Tracking of newsletter sign ups by page



Web Analytics
6 years ago
5 years ago


(Reporter: cmore, Assigned: dpoirier)





6 years ago
There is click tracking on the newsletter signup form here:

In WebTrends are we able to see what pages those clicks came from or would those need to be passed along with the onClick calls?

We have newsletter signups on multiple pages.

Comment 1

6 years ago
Everytime we track an event a parameter,, is generated with the URL of the generating page. The report, Download Firefox by Source Page, is a good example of a rerpot that uses this parameter.

Comment 2

6 years ago
Ok. so is dynamic and will the URL into webtrends. Specifically for the Newsletter signup multi track call, are the pages that it is being called with pulled into any existing report that we have now?

Comment 3

6 years ago
Not that I can find. I can crate one.
Hi, Bill. If you could create one, that would be helpful. We want to gauge which pages generate the most newsletter sign-ups.

Comment 5

6 years ago
From email sent 8/8:

I’ve been digging into trying to get this report out but I’m seeing issues that can’t be overcome without tagging. I’ve looked at several pages and have seen the 3 examples below. There may be more. The first 2 I can segment on but the last one which turns out to be a page refresh there is no way to segment it out from the regular page views. The last one I think is also the most common. We’ll need to at least add some parameters to the reload if possible.

Comment 6

6 years ago
Checking in on this bug to see if you need anything more from me. Let me know.
Hi Bill, 
Was I copied on the email from 8/8? I am curious about the examples you mentioned, but I can't find an email from you. 

We are working on a redesign for the Firefox download funnel, which includes all of the pages that the user sees in the path from downloading Firefox to opening it for the first time. Within this path is where we may be picking up a lot of our newsletter sign-ups, which is why we are looking for more specific data for which pages are leading to sign-up (and which are not). It sounds like in this redesign we will have to do a better job tagging what we want to track. 

Could you post the examples you mentioned here or forward me the email you sent on 8/8?

Comment 8

6 years ago
Hi Holly,

I forwarded the examples to you. Let me know if you don't receive them.
Thanks, Bill. I got them.

Comment 10

5 years ago
Moving this over to the Web Analytics component since it will be implemented in GA and not Webtrends.
Assignee: bill.baker → nobody
Component: Webtrends → Web Analytics


5 years ago
Duplicate of this bug: 759595
Can we please update this across all newsletter registration pages on Is the section of the page where the newsletter registration resides part of a template? 

We already have Newsletter tracking implemented on our firstrun page here: 	

Please set the following GA event on successful submit of the newsletter form for every page it resides on. 

_gaq.push(['_trackEvent', 'Newsletter Registration','submit', '[Type of Newsletter]');

Assigning to malexis to assign to the right dev to make this happen.
Assignee: nobody → malexis


5 years ago
Assignee: malexis → dpoirier
OS: Mac OS X → All
Hardware: x86 → All

Comment 14

5 years ago
Pull request opened:

Comment 15

5 years ago
How accurate does this tracking need to be?

We've got a solution that'll track on submission of the signup forms. The only drawback is that on browsers that don't validate the forms on the client side (e.g. Safari, IE), it's possible when the form gets to the server, a problem will be found with it and the person won't actually be subscribed.

To reduce that possibility, we'd need to add custom client-side form validation code to check out the form before submitting, but before doing that, we wanted to see if that was overkill for this case.
Flags: needinfo?
Do you have an estimate as to how often a person won't actually be subscribed in the case you mention?
Flags: needinfo?
This would boil down to anyone using either IE or Safari (OSX/iOS), who does one of the following

- Enters their email address incorrectly
- Forgets to check the privacy policy

Hitting submit in either of the above circumstances would still register a GA subscription without some form of client side validation.
Thanks for the additional clarification Alex.

So, if a visitor forgets to check the privacy policy, generating an error (and a GA call), i would assume that they would more than likely check the box and resubmit. Then we would have two total GA events being triggered. 

I'm ok with this scenerio, because when I measure the effectiveness of a page I am looking at the unique number of events (ie. newsletter registrations) being triggered, which would be 1 in the above scenario.

As for the scenario where a visitor enters their email address incorrectly...

When using safari and incorrectly entering an email (ie. on, i got sent to the following page for validation:

This page also generated the following error: "↑Must be a valid email address"

If we wanted to see how often this occurs, we could place an event on that page when that error message is rendered. However, that is a separate task.

I guess the question is, should their be client side validation on sign-ups for these scenarios?

Comment 19

5 years ago
Commits pushed to master at
Bug 780935: Track newsletter signups in Google Analytics

Add on-submit handlers to newsletter signup forms and submit
events to GA.
Merge pull request #994 from dpoirier/bug-780935-track-newsletter-signups

Bug 780935: Track newsletter signups in Google Analytics

Comment 20

5 years ago
Is this working now?
We thought this was fixed initially, but it seems there is still an issue which is being addressed in Bug 896001.
Depends on: 896001
Thanks for the fix. I've verified that data is now coming into production and am closing this bug.
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.