GTM4WP v1.9: AMP, WooCommerce, Google Optimize and more

GTM4WP v1.9 has been released with lots of additions, improvements around AMP, WooCommerce and Google Optimize integration and better compatibility with cache plugins.

AMP plugin: initial support

The official AMP plugin of Automattic is nearing its first stable 1.0 version. There are already some alternatives available in the WordPress.org plugin repository and the official AMP plugin could need some support with a brand new integration in this plugin. Using the AMP plugin and GTM4WP you can have lots of data layer variables in your AMP container to build a much more sophisticated measurement for your AMP pages as well.

Just visit the Integration page in plugin settings and click on the Accelerated Mobile Pages tab. Enter your GTM container IDs for AMP pages and your are ready to go! Remember that to use AMP with GTM, you need to create a separate GTM container, do not use your normal, web based containers in this option. we also strongly advise you to read the guide of Simo Ahava about AMP containers before you start using one as there are many limitations that you need to learn more about.

And a big thank you for Vincent Koc who helped us have this integration in the plugin.

WooCommerce improvements

Again and again we think of this integration to be almost complete and it turns out that there is still lots of room for improvement 🙂

If you read the changelog, you will see that lots of changes are connected to the WooCommerce integration again:

Exclude tax from revenue data

A new option allows you to remove tax from revenue data on order received pages. In WooCommerce, you can set whether you would like to enter prices inclusive or exclusive of tax. You can also change how prices are being shown. Depending on this options, the data layer generated by this plugin will also include tax amount which might be not your goal. With this new option, you can keep net prices in your tracking codes.

Stock levels

Although stock levels are not part of the enhanced ecommerce dataset of Google Tag Manager, many of you asked for this data so here it is: a new non-standard data layer variable has been added to the ecommerce datasets. You will need a custom JavaScript variable to utilize this in your tracking codes but hopefully this will give you enough support to start using it:

event: "gtm4wp.changeDetailViewEEC",
ecommerce: {
  currencyCode: "EUR",
  detail: {
  products: [{
   "name: "Your Product",
   "id: 337,
   "price: 10,
   "category: "Your Category",
   "stocklevel: "5",
   "variant: "red,m"
  }]
}

Is the product a variable product?

A new productIsVariable data layer variable has been added into the global data layer on each product detail page so that you can setup different measurement on variable and simple product detail pages

Send product impression data in separate hits

If you are using enhanced ecommerce and you setup your Google Analytics tags to capture this data, you might notice that on product list pages with lots of products, your Google Analytics pageview hit is not sending data at all. This is due to a limitation of the collection library: if the size of the collected data (the so called payload) exceeds 8kB, the tracking code will simply drop the hit and not send any data to your Google Analytics property.

On larger product list pages, including all product names, category names and other longer texts in your Google Analytics payload could easily exceed this limit which could also mean that even the pageview information will be lost on that page. Having such pages as campaign landing pages could also mean that you loose important acquisition dimensions.

Now you can set a new plugin option where you can enter a maximum number of products sent in each batch giving you the ability to send the pageview hit separated from product impression data and to send product impression data in multiple event hits.

Enter a number greater than 0 to active the separate Google Tag Manager events. Leave this to 0 (default option) to keep the already existing behavior.

Please make sure you review the setup guide as with this option enabled, you will need to update your Google Tag Manager setup: the pageview trigger needs to be updated and a new non-interaction event tag has to be created for product impressions to be sent to Google Analytics.

You may also want to know that there are another limitations that could be easily reached on sites with larger traffic: each session of a user can have only 500 hits and your property can collect 10 million hits in each month. Lets count a little bit: lets say you have product list pages with 40 products on each page and you setup this option to split product impression data into 10 product / hit chunks. On each page load, you will have 1 pageview hit and 4 event hits sent to Google Analytics. If your user visits 20 product category pages during a session, that is already 5 * 20 = 100 hits in a session and we still need the quota for product detail page views, add to cart events, checkout page visits, etc. Lets say the average hit / session is 120, with that, you can have ~83k sessions in a month. That is ~2700 sessions a day. Seems to have plenty of room but you should keep an eye on this number as well.

A big thank you for Tim Zook for the contribution for this improvement.

Do not flag orders as being already tracked

Although many measurement and ad systems have quite a lot of defense lines to prevent tracking the same order multiple times, this plugin also has some protection built in: ecommerce data (both classic and enhanced) on order received pages are only loaded once, during the first page load of this thank you page. Any subsequent visit of the same order received page will not include transaction data to protect the accuracy of your measurement.

In same cases however codes on the order received pages are executed twice: first in the background and then during the generation of the thank you page. This seems to be the case at least if you are using iDeal in the Netherlands. This can prevent you from properly tracking ecommerce data even in Google Analytics.

To overcome this, our plugin has now a new option in the WooCommerce integration that gives you the ability to turn of this protection within the plugin.

More accurate tracking

Loading your Google Tag Manager container code as early as possible is usually a best practice to keep your tracking implementation accurate. However many of you are utilizing the jQuery library bundled with WordPress in your custom HTML tags. To support such container setups, the plugin only loads the container after all other libraries has been loaded but this can add a latency into your tracking that could give you a less accurate data collection.

Now you can enable a new plugin option on the Advanced option page which will move the container code to the top of the page source, as high as possible giving you the opportunity to have a more accurate tracking on your sites.

Google Optimize: (almost) full support

A/B testing on your websites is a great opportunity to improve performance and conversion rates without even changing your acquisition strategy. Personalisation is also a big buzz in 2018 and we are sure this will be a hot topic in 2019 as well.

Google Optimize can help you in both cases but this requires you to add its own container code into your site. The technology is based on what you have seen with Google Tag Manager but the way Google Optimize’s code can be added to your site if different. Until now, this plugin only supported the so called page hiding snippet which helps you to hide the content of the page while Google Optimize renders the test version of the content which prevents users to see some flickering during page load. To load the Google Optimize container itself, you had to add it within your Google Tag Manager container using the Google Optimize tag template.

But this is not the best way to load Google Optimize on your site. Why? Because this adds an extra latency which is crucial if you want to run your tests as smoothly as possible.

To load Google Optimize while keeping Google Tag Manager, the recommended setup is to load it using a truncated Google Analytics tracking code at the very top of your <head> element in your pages. Before v1.9, you had to add this manually and this also prevented you to use the data layer provided by this plugin in your Google Optimize experiences.

Now you can enter your Google Analytics tracking ID in plugin options on the Integration page, under the Google Optimize tab which will also load the Google Optimize container on your site. Using this in parallel with the previously introduced option, your site will include tracking codes in this order:

1. Data Layer data
2. Google Optimize page hiding snippet
3. Google Optimize container code using the truncated Google Analytics tracking code
4. Google Tag Manager container code

Why is the Google Analytics tracking code truncated and in what way?

Good question and here is the answer: it includes almost everything that is included in a normal tracking code except one line: sending the pageview data. This will make sure that your Google Analytics tags in your Google Tag Manager container can be kept and that they will not interfere with the Google Optimize container code in your site.

Why do you say that this is “almost” a full support?

Another great question 🙂

Using this truncated tracking code, we should keep some advanced tracking options aligned with the options in your Google Tag Manager container. This is explained on the official help center page of Google Optimize. Basically most of those options are rarely used and our intention was to keep this integration free from lots of options that could sound a bit scary for intermediate users. Of course we will improve this integration in the future to truly support every aspects of the documentation but for now, in most cases, keeping the default behavior should work.

Better uninstallation

It is really exciting to see how more and more people are using this plugin but of course it is part of our life that some of you are leaving us. We are always said to hear about such cases but we can also understand that building a proper and sophisticated measurement using Google Tag Manager can require more in depth skills since this is not a “one checkbox and things start to work” tool.

Sometimes this uninstallation is simply part of a cleanup process.

In both cases, options saved to your WordPress database were not deleted leaving garbage after removing this plugin. Tough this was never a big dataset, it is important to remove everything once you decide to remove GTM4WP. And now the plugin will remove this database entry when you decide to uninstall it from your WordPress instance.

Better privacy control

Keeping the privacy of your users safe should be one of your top priorities in 2018 and 2019. Some users block tracking codes using browser extensions, some however simply turn on a quite simple option which tells websites not to track them while browsing.

Out of question: you must accept this choice and disable tracking codes inside your Google Tag Manager container. Since you might have codes in your container that are not directly related to user behavior tracking, this plugin will not remove the container code if a user has setup this “do not track” option. But now, you can include this option as a data layer variable if you visit the Advanced page in plugin options and enable the corresponding checkbox.

This will add the visitorDoNotTrack variable into the data layer which will equal to 1 if the user has setup this browser option. It is up to you whether you block your tracking codes or not but we strongly advice you to do so.

Tracking user account events

Especially for subscription sites, tracking new user registrations is a must and a great KPI to optimize your site and campaign performance. Now you can enable a new option in plugin options on the Event page to fire a Google Tag Manager event after a user has successfully registered on your site. This will also work with your customer registration in WooCommerce. You just need to create a new event trigger for gtm4wp.userRegistered and attach this trigger to your tags that send this event to Google Analytics, a Facebook pixel or wherever you want.

You can also track when users are being logged in using the new gtm4wp.userLoggedIn data layer event.

GTM4WP ♥ Cache plugins

Having a cache plugin on your site can really speed up your site performance and we all know that having low page load times can even improve your conversion rates.

But on the other hand cache plugins can really mess up things when merging JavaScript codes. Not because they are bad doing so but they can not be prepared for every possible complexity. With GTM4WP you might already faced that with some cache plugins and with some cache plugin options enabled, some of the features of this plugin could break.

From now on, most of the JavaScript codes connected to this plugin are stored in separate .js files giving cache plugins the ability to properly do they work keeping the dependencies of each .js file. A new addition will also give WP Rocket some hint which codes might need more care in this plugin.

Wheather and geo data

Now that freegeoip.net has been transformed into a free+paid service, GTM4WP had to be updated as you require now an API key even if you are using the free tier of their service. This is mandatory to have wheather and geo data in you data layer.

Warning: deprecated features will be removed in v1.10

Some plugin features are deprecated since years and now it is time to say goodbye to them:

• Tracking social actions
• Outbound link click events
• Download click events
• Email click events

Those features has been added in the very first version of GTM4WP (which was v0.1 and not 1.0). This was some years ago when Google Tag Manager itself was not that advanced and many tasks needed a lot of coding on your website. Since the main goal of this plugin was always to keep away you from coding with Google Tag Manager as much as possible, we have added some features in the first versions that gave you the opportunity to track several user interactions easily.

Now that Google Tag Manager has lots of interesting triggers, those features are obsolete. All above plugin features will be removed from v1.10 so if you are using them, please migrate all tracking using the native Google Tag Manager triggers.

Update your PHP

Now that PHP 5.6 and even 7.0 is nearing its end of support even for security fixes, it is really time for everyone to move on to at least 7.1. Especially migrating from 5.x to 7.x can boost your site performance a lot.

This plugin requires now at least PHP 5.6 which is still a quite old version of PHP so migrating from older PHP versions to PHP 5.6 could need less effort. To make the move, consult with your hosting provider and with the authors of your WordPress plugins and themes. The WordPress core and this plugin clearly supports PHP 7.x 🙂

Summary

Again, lots of additions and improvements, hopefully each addition will add value to your site. For 2018, only bug fix versions are being planned so with v1.10 we will keep a longer release cycle so that you can have plenty of time to adapt and to prepare for new features. There can be only one exception: if some really interesting feature of Google Tag Manager or Google Optimize is being released, we will make sure can utilize this new feature as quickly as possible.

Now head over to your WordPress admin area and update GTM4WP to v1.9 to start using all those exciting new plugin features!