mhoad / oaf-analytics

Outstanding issues to fix up the analytics implementation on the new OAF website
0 stars 0 forks source link

Add Google Optimize snippet #2

Open mhoad opened 7 years ago

mhoad commented 7 years ago

Immediately after the <meta charset="utf-8"> tag on all pages we should have the following code snippet in order to allow OAF to correctly conduct A/B tests across their website:

<style>.async-hide { opacity: 0 !important} </style>
<script>(function(a,s,y,n,c,h,i,d,e){s.className+=' '+y;h.start=1*new Date;
h.end=i=function(){s.className=s.className.replace(RegExp(' ?'+y),'')};
(a[n]=a[n]||[]).hide=h;setTimeout(function(){i();h.end=null},c);h.timeout=c;
})(window,document.documentElement,'async-hide','dataLayer',4000,
{'GTM-N42D2N4':true});</script>

Note: This snippet should come before the Google Tag Manager snippet as discussed in issue #1

phil-mcminn commented 7 years ago

This code only includes the page-hiding snippet, and doesn't include the actual container code necessary to run Google Optimize. You also need to add modified Universal Analytics tracking code directly onto the page.

It's strongly recommended that you don't use Google Tag Manager to implement Optimize.

Google's implementation documentation is here, for posterity.

Here's what your full code should look like. Add this to all of the pages you wish to A/B test.

<!-- Google Optimize page-hiding snippet  -->
<style>.async-hide { opacity: 0 !important} </style>
<script>(function(a,s,y,n,c,h,i,d,e){s.className+=' '+y;h.start=1*new Date;
h.end=i=function(){s.className=s.className.replace(RegExp(' ?'+y),'')};
(a[n]=a[n]||[]).hide=h;setTimeout(function(){i();h.end=null},c);h.timeout=c;
})(window,document.documentElement,'async-hide','dataLayer',4000,
{'GTM-N42D2N4':true});</script>

<!-- Amended UA code for Google Optimize only  -->
<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-53259972-1', 'auto', {allowLinker: true});
  ga('require', 'GTM-N42D2N4');

</script>

The correct order for this (and your updated GTM code as discussed in issue #1) is as follows—instructions lifted directly from Google's documentation again:

Tag order Placement of the Optimize code snippet is important. Generally, the order of the tags should be:

  1. Any JavaScript (e.g. jQuery) that you wish to use in Optimize experiments. We recommend you keep these to a minimum.
  2. Initialization of any variables needed for targeting (data layer, JavaScript, cookies, etc).
  3. Page-hiding snippet and Modified Analytics tracking code with Optimize plugin.
  4. Tag Manager container snippet.
  5. Other JavaScript, trackers, and ad tags.

Here are some best practices to keep in mind when adding the code to your web pages:

  1. The page-hiding snippet should be placed immediately before the modified Analytics tracking code (after the declarations). (I've structured the supplied code exactly like this) so you can ignore this step).
  2. Move your Google Analytics tracking code up to the , if it's not already there.
  3. The following should come before the modified Analytics tracking code:
    • <meta charset>
    • Data layer initialization.
    • Setting cookies.
    • Any scripts that you may want to use or that declare JavaScript variables that you wish to use in Optimize experiments. For example, jQuery and JavaScript used to target an Optimize variant.

The following should come after the modified Analytics tracking code I've supplied:

Lastly, I don't have access to your GTM container so I'm not sure if you're using any custom Analytics tracker settings but if you are, you need to include them in the Analytics create command in the code I've supplied above. For example, the following “create” command enables automatic cookie domain configuration (for tracking across subdomains) and sets allowLinker to true (for cross-domain tracking):

ga('create', 'UA-53259972-1', 'auto', {allowLinker: true});

These are fairly standard but you might want to remove the {allowLinker: true} parameter if you're not using it in your GTM page view tag, and update if you're doing anything more complex with tracker settings. Happy to look at your container if needs be and provide updated code. It won't hurt having this parameter in your code either way.

mhoad commented 7 years ago

Thanks for that. Just as an FYI we weren't planning on requiring jQuery in any of the tests and instead would usually just use standard JS for basic DOM manipulation. Usually it's nothing crazy and just something along the lines of moving some elements around on the page like so:

var someElement = document.getElementById('text-4');
var pressMentions = document.getElementById('text-6');
someElement.insertAdjacentElement('beforebegin', pressMentions);

If you think that might not be ideal let me know but if I can avoid you having to add in a dependency like that especially so early in the code I would love to.

Also thanks for the clarification regarding how to approach this independently of GTM. I believe the only other modification we would usually have on the GA tracker is setting the siteSpeedSampleRate to something like 100 or 90 (reference here).

Also just one other thing here I am not sure how much of a pain this is or if it is worth it from you perspective but I usually have a different GA UA tracker when sites are in development in both GTM and I guess for this. Is there any way to have some kind of variable that lives in Wagtail or somewhere else that we can easily edit without needing to redeploy that would encapsulate this?

Alternatively what about something like (excuse the Rails example it is all I know sadly):


<% if Rails.env.production? %>
  <!--  Production GTM / GA code -->
<% else %>
  <!-- Development GTM / GA code -->
<% end %>
phil-mcminn commented 7 years ago

Just as an FYI we weren't planning on requiring jQuery in any of the tests and instead would usually just use standard JS for basic DOM manipulation.

That's beyond me I'm afraid. One for Andrew!!

Also thanks for the clarification regarding how to approach this independently of GTM. I believe the only other modification we would usually have on the GA tracker is setting the siteSpeedSampleRate to something like 100 or 90 (reference here).

That's not an approach I'm familiar with, but it looks straightforward. Page view tag would need to have this added as a field to set in GTM and ga('create', 'UA-53259972-1', 'auto', {allowLinker: true},); would need to be amended.

Also just one other thing here I am not sure how much of a pain this is or if it is worth it from you perspective but I usually have a different GA UA tracker when sites are in development in both GTM and I guess for this. Is there any way to have some kind of variable that lives in Wagtail or somewhere else that we can easily edit without needing to redeploy that would encapsulate this?

Good shout. We typically use a variable in GTM that says

Does that solve your issue? That's probably a less complicated way of doing what you're trying to do as it only requires one GTM container. I don't have GTM access to OAF and haven't seen their setup so I'm not sure if this approach is already being taken but it doesn't appear to be.

mhoad commented 7 years ago

Can I get your contact info and I can add you to the GTM setup? Sounds like you might have a better way of doing this than I had in mind perhaps but right now there is a different container for the "new website" and we were planning on sunsetting the old one and just updating the GA property ID upon launch.

phil-mcminn commented 7 years ago

Could you add torchbox@gmail.com to GTM? Can I get access to both containers?

Sounds fine re. the two containers. I'll take a look.

Just a sense check: you're still planning on sending GA data on the new site to property UA-53259972-1 right? (Please don't say you're going to sunset the existing Google Analytics property and start a new one?!)

mhoad commented 7 years ago

Haha no absolutely not planning on switching GA containers at all :)

You should have access now though to everything in GTM

phil-mcminn commented 7 years ago

I've created a new, unpublished workspace in the GTM container GTM-MZTFPGC called "Torchbox Workspace". This is a branched version of the live container (version 1) on the staging site, and doesn't include the 7 unpublished changes you've made to the container in your Default Workspace.

I've created two new constant variables: {{gaProperty ID Staging Site}} and {{gaProperty ID Production Site}}. At this stage, both of these store the value UA-53259972-2, which is the Google Analytics Staging property I have access to. It's unlikely you'd want to send data to a third, independent production property but if you did, there's the option here to amend this.

I've renamed your variable {{gaPropertyID}} to {{gaPropertyID Live Site}} and updated the value stored in this to UA-53259972-1 (the "live" Google Analytics property).

I've created a new Lookup Table variable called {{gaProperty ID Lookup}} that takes the variable {{Page Hostname}} as its input and outputs the relevant constant variable.

I've set the default value for this table to UA-53259972-1.

Lastly, I've created a new Google Analytics settings variable called {{googleAnalyticsProperty}}. This is a new variable in GTM that means you don't have to amend every single tag with the same set fields (e.g. cookieDomain). If you decide, for instance, to implement cross domain tracking in future, or enable Display Advertising Features, here's where you'll update those settings. Please note your current pageview tag in the staging container doesn't have the tracker setting siteSpeedSampleRate in place. If you want to add this, please set this in the variable {{googleAnalyticsProperty}}. I'll leave this to you.

I've updated all of the tags in the workspace with this new Google Analytics settings variable. I've unticked the "Enable override settings in this tag" option and added in this variable to all tags.

I've successfully tested these changes on oaf-production.torchboxapps.com but they'll need to be tested on the live site once it's alive.

If you're happy with this approach, please publish this workspace. You'll then be prompted to merge these changes into your Default Workspace, which you'll then need to do.

Any q's, just ask.

mhoad commented 7 years ago

@phil-mcminn Thanks for the detailed breakdown, I really appreciate it. I didn't even think to use a lookup table for the hostname / UA ID combination but that is a much better solution than what I originally had in mind so thanks again for setting that up.

I will go take a deeper dive into what is left of the GTM / GA front today but a few quick things that come to mind:

  1. Do you know when you are pushing those other changes to staging just so that we can test the implementation is all working as expected? What I am currently seeing at https://oaf-production.torchboxapps.com/ is the same as before at the moment
  2. I noticed that right now they are getting hits in GA for people logged into the admin backend of the site. Not knowing Wagtail super well but I assume we might be able to do some kind of "if the user is signed in to Wagtail then don't send hits to GA". I imagine we could either do this via a dataLayer variable or even just straight up not showing the GTM snippet if they are logged in. I could picture advantages to each but you may have another idea on it as well.
  3. On a totally different note, where are you guys actually deploying the final site to? Are you guys actively hosting it yourselves or is this on OAF to nominate. The reason I ask is I was wondering what if any capacity there is for some further speed optimisations using things like mod_pagespeed and HTTP2 any insight on that would be amazing!
pvetch commented 7 years ago

Hi Mark

1 - I'll check - we're not really using the oaf-staging much now but working directly on oaf-production which will actually be the live site 2 - Phil coming back to you on this 3 - the site is hosted on our infrastructure. We look at speed optimisations as part of our prelaunch process (tho NB not mod_pagespeed which we've had mixed results with on nginx). HTTP2 should already be in place AFAIK

phil-mcminn commented 7 years ago

On point 2:

I've added an exception to the tag "Google Analytics - Pageview - All Pages" so that pageviews don't fire on any page containing /admin/. That should stop Wagtail pages from appearing in GA.

This has been added to the workspace "Torchbox Workspace" and left unpublished—as with my other changes, please review and merge if you're happy with what I've done.

pvetch commented 7 years ago

Sorry Mark one other consideration: as things stand with the launch planned for next week we don't have the ability to add granularity to where the Optimize code is installed. Ideally we'd update the site to include an admin option to include the code on a per page basis, but we won't be able to do that pre launch. That would mean including it everywhere, which Phil has flagged as a potential performance issue.

Would we be best off leaving this out for now until you have a sense of the testing regime you'd like to implement?

pvetch commented 7 years ago

(Note that Wagtail has some inbuilt support for A/B testing too which it might be worth considering at some point depending upon what you're looking to explore)

nimasmi commented 7 years ago

The page-hiding snippet and amended UA code are now added, after the <meta charset> tag and before the GTM snippet (and it will also be after the dataLayer snippet—where included—when and if #5 is deployed). This is deployed to oneacrefund-staging.torchboxapps.com.