Donation amount conversion tracking (GA and Optimizely)

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: adam, Assigned: thecount)

Tracking

Details

(Whiteboard: [EOYFR2014][studio mofo][donation flow][nov28][p1])

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
We need to implement conversion tracking on the thank you page after people donate, so that we can run A/B tests and display the EOY campaign results on fundraising.m.o

The GA and Optimizely code snippets required to do this are found here:
https://wiki.mozilla.org/Foundation/Metrics/Landing_Page_Tracking#Donation_Pages_.28sendto.mozilla.org.29

Currently in BSD, we are redirecting the user to this sign-up page after they have made a donation ( https://sendto.mozilla.org/page/s/EOYFR2014-donor ). So that sign-up page is effectively our 'thank you' page where we need to fire the GA and Optimizely tracking tags.

This page will need to fire these conversion tracking tags for traffic from BSD paying by CC, and also traffic that goes out to PP and is redirected back. PP, for example will pass the donation amount back to the page in the URL parameters which we will need to parse and use in the conversion tracking tags.

--

This bug is an updated version of Bug 1013832
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1013832
(Reporter)

Updated

4 years ago
See Also: → bug 1100314
(Reporter)

Updated

4 years ago
Whiteboard: [EOYFR2014][studio mofo][f.m.o][nov14][p1] → [EOYFR2014][studio mofo][donation flow][nov14][p1]
* [nov14] is past -- please update to [nov28] train or later

Comment 3

4 years ago
Just flagging Simon here so he could help me with bug triage.  Thanks, Simon!
Flags: needinfo?(simon)

Updated

4 years ago
Whiteboard: [EOYFR2014][studio mofo][donation flow][nov14][p1] → [EOYFR2014][studio mofo][donation flow][nov14][p2]

Updated

4 years ago
Assignee: mavis → andrea
Hey Adam -- if we set this up as you describe, do you see any reason we need to record PayPal payment data in Blue State Digital? (wondering if this solves 2 problems :)

Comment 5

4 years ago
Removing flag on Simon as this bug has been triaged.
Flags: needinfo?(simon)
(Reporter)

Comment 6

4 years ago
(In reply to Andrea Wood from comment #4)
> Hey Adam -- if we set this up as you describe, do you see any reason we need
> to record PayPal payment data in Blue State Digital? (wondering if this
> solves 2 problems :)

Having the records in BSD allows you to do things like send a thank you email to all the donors (who have opted-in of course) in January with an update about the campaign. As one example.

GA data is all anonymous.
Whiteboard: [EOYFR2014][studio mofo][donation flow][nov14][p2] → [EOYFR2014][studio mofo][donation flow][nov28][p2]
Increasing this to P1 as tracking is currently not possible, and we're launching snippet testing 11-20. Re-assigned to Scott to take or assign to someone else.
Assignee: andrea → scott
Whiteboard: [EOYFR2014][studio mofo][donation flow][nov28][p2] → [EOYFR2014][studio mofo][donation flow][nov28][p1]
(Assignee)

Comment 8

4 years ago
Created attachment 8525844 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/21

Does this look sane to you Adam?
Attachment #8525844 - Flags: review?(adam)
(Reporter)

Comment 9

4 years ago
(In reply to Scott [:thecount] Downe from comment #8)
> Created attachment 8525844 [details] [review]
> https://github.com/mozilla/bsd-forms-and-wrappers/pull/21
> 
> Does this look sane to you Adam?

The code looks sane, but we'll need to test something with regards to how BSD works that I don't know about:

(1) I don't know if the BSDTracker object exists on that page. Typically a BSD form has a thank you page, but instead we're forwarding the user onto a separate sign-up form. I don't know how BSD does this behind the scenes and in particular if the BSDTracker object 'travels' with the user. This link gives some clues: http://tools.bluestatedigital.com/kb/article/what-is-the-bsdtracker-and-how-do-i-use-it but basically we need to test it.

(2) Right now, this won't account for PayPal donations (~70% of the donations). I don't know how you'll want to implement the PP tracking, but I think you have two possibilities: 

  (A) If the PayPal donations are recorded in BSD, this data might be available in the BSDTracker object (I don't know if this is the case, but it's something to investigate) (See also Bug 1096293)

  (B) If the PayPal donations are not available in the BSDTracker object, we need to parse the URL to extract the values when a user is returned from PayPal. And then build this into the logic on that page. E.g. check for the BSDTracker object, or alternatively check for PayPal parameters, and use these values in the GA and Optimizely tracking events instead. (See also Bug 1100314)

-- 

I suggest we get this live and tested for the Credit Card / BSD transactions asap, and then work through the PayPal version after that. How does that sound?
(Assignee)

Comment 10

4 years ago
Sounds good.

I'm not sure about the answers to any of those questions, and I cannot test until this is live...
(Assignee)

Comment 11

4 years ago
Comment on attachment 8525844 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/21

Mavis, I need this online so I can test, and I also want a quick check that nothing here can break something existing.
Attachment #8525844 - Flags: review?(mavis)
Attachment #8525844 - Flags: review?(adam)
Attachment #8525844 - Flags: review+
(Assignee)

Comment 12

4 years ago
Comment on attachment 8525844 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/21

Updated, re review.

Adam, I could not put any of this in the <head> because of the way BSD works.

Is that going to be a problem?

I also noticed the wrapper already included the optimizly script, so I don't need to add it.

Updated

4 years ago
Attachment #8525844 - Flags: review?(mavis) → review+
(Assignee)

Comment 13

4 years ago
Comment on attachment 8525844 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/21

Sweet, landed, it's there I can confirm it.

Adam, I'm going to put this back onto you to confirm it if you don't mind.

Check GA/optimizely, should be data going through now.

I want to double check this because I was not allowed to put the scripts in the head, so they are in the body instead...
Attachment #8525844 - Flags: review+ → review?(adam)
(Assignee)

Comment 14

4 years ago
Adam, also can I get creds to view these results?
(Assignee)

Comment 15

4 years ago
Created attachment 8527145 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/27

Looks like there was already some ga tracking script includes in the footer.
Attachment #8527145 - Flags: review?(aki)
Comment on attachment 8527145 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/27

the default ga code needs to come first for a lot of our stuff, so I think a better route would be deleting it here and adding it to the end of the wrapper header.
Attachment #8527145 - Flags: review?(aki) → review-
(Reporter)

Comment 17

4 years ago
(In reply to Aki Rose Braun [:akirose] from comment #16)
> Comment on attachment 8527145 [details] [review]
> https://github.com/mozilla/bsd-forms-and-wrappers/pull/27
> 
> the default ga code needs to come first for a lot of our stuff, so I think a
> better route would be deleting it here and adding it to the end of the
> wrapper header.

That's right. 

I see mavis has commented on the PR:
> Maybe we could also move the GA code from footer to 
> 0-wrappers/EOYFR-2014-Donation-Form/wrapper-header.html <head>?

That makes sense to me. The GA code loads asynchronously so loading it in the head shouldn't cause performance issues.
(Reporter)

Comment 18

4 years ago
Answering one of these questions.

(In reply to Scott [:thecount] Downe from comment #10)
> I'm not sure about the answers to any of those questions, and I cannot test
> until this is live...

(In reply to Adam Lofting (:adamlofting) from comment #9)
> (1) I don't know if the BSDTracker object exists on that page. Typically a
> BSD form has a thank you page, but instead we're forwarding the user onto a
> separate sign-up form. I don't know how BSD does this behind the scenes and
> in particular if the BSDTracker object 'travels' with the user. This link
> gives some clues:
> http://tools.bluestatedigital.com/kb/article/what-is-the-bsdtracker-and-how-
> do-i-use-it but basically we need to test it.

I've just put through a test donation, and can confirm the BSDTracker object with my donation info is available on the thank you page even though we're redirecting to the subsequent sign-up form. (screenshot to follow)
(Reporter)

Comment 19

4 years ago
Created attachment 8527231 [details]
BSDTracker.png
(Reporter)

Comment 20

4 years ago
Comment on attachment 8525844 [details] [review]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/21

Following our debugging on IRC today, R- this old PR.

But the latest PR R+:
https://github.com/mozilla/bsd-forms-and-wrappers/pull/29
Attachment #8525844 - Flags: review?(adam) → review-
(Reporter)

Comment 21

4 years ago
We are now tracking CC donations in GA.

Next we need to solve for those that go via PayPal.
(Assignee)

Comment 22

4 years ago
Recording this from paypal in the thank you page itself requires this to be fixed: #1100314
Depends on: 1100314
(Assignee)

Comment 23

4 years ago
Created attachment 8529157 [details]
https://github.com/mozilla/bsd-forms-and-wrappers/pull/41/files

This gets us the percentage of people that return from paypal.
Attachment #8529157 - Flags: review?(jon)
Attachment #8529157 - Flags: review?(jon) → review+
Confirmed, this is tracking correctly in GA.

:adamlofting - any other changes we need to make?
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 25

4 years ago
(In reply to Jon Buckley [:jbuck] from comment #24)
> Confirmed, this is tracking correctly in GA.
> 
> :adamlofting - any other changes we need to make?

This is working great, thanks.
You need to log in before you can comment on or make changes to this bug.