Open mhoad opened 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:
Here are some best practices to keep in mind when adding the code to your web pages:
<meta charset>
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.
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 %>
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.
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.
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?!)
Haha no absolutely not planning on switching GA containers at all :)
You should have access now though to everything in GTM
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.
UA-53259972-1
UA-53259972-2
UA-53259972-2
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.
@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:
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
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.
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?
(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)
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.
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:Note: This snippet should come before the Google Tag Manager snippet as discussed in issue #1