When you have an ecommerce site that you run out of WooCommerce, you may be looking at your sales statistics every month asking yourself “so, that’s great, but how can I push the needle?” The thing is, your sales data won’t tell you. It can’t. Your sales data simply doesn’t know what channels were driving high-converting traffic to your site, neither can it tell you which landing pages performed the best. That’s what analytics programs, such as Google Analytics are for.

That’s why in today’s post, I’ll be walking you through the setup of Google Analytics for your WooCommerce ecommerce store. And I’m not talking about configuring a pageview goal when someone reaches your “thank you” page. Pageview data is giving you a tiny bit more insight than your sales data alone, but still not the whole story. And we want the whole story!

With proper ecommerce tracking setup for your WooCommerce store on WordPress, you can harness the power of Google Analytics to track your ecommerce transactions, understand what channels drove high-converting traffic, and eventually plan out your path to maximum ROI.

So, follow along and shoot me an email if you get stuck.

Please note: For this post, I’m assuming that you’re using the Google Tag Manager (after all, you’re interested in enhanced ecommerce tracking and GTM gives you the most flexibility to track website interactions the way you wish to).

If you don’t have GTM set up and want to get started with it,  you might want to read up on GTM in the Google Tag Manager Help Center first.

If you don’t want to use the Google Tag Manager, you can still follow along, however, the workaround for you will be slightly different.

I know you’re eager to get started with the setup and so am I. To help you avoid the most common pitfalls, I’d like to cover a few important concepts first, however.

In the grand scheme of things, ecommerce tracking for WooCommerce looks like this:

1. A customer starts the checkout process and submits his/her payment information.
2. The transaction gets passed on to your Payment Service Provider (also known as Payment Gateway) and either gets approved or declined.
3. After a successful transaction, the customer lands on a “Thank You” page or “Order Confirmation” page.
4. Your server passes information about the transaction (such as average order value, etc.) on to your analytics program.
5. Your analytics program records this transaction data and matches it to other data in your analytics reports.

Sounds simple right? Well, it is up until the point where your server is supposed to send transaction data to your analytics program. This is done via something called a “data layer.” How this is configured, I’ll explain in more detail below.

If you are using an off-site Payment Service Provider, such as the PayPal Standard, you have one additional problem: The transaction doesn’t happen on your website and PayPal doesn’t have Google Analytics integration, so the transaction data can’t be passed on for every purchase. I’m saying “for every purchase” here, because for it is possible to redirect users back to your “thank you” page (and retrieve the transaction data) IF the user pays with their PayPal account (as opposed to paying with credit card) and IF the user clicks on the “return to merchant” button after the purchase. The chances that both IFs are true for every purchase on your website are pretty much null.

This is why it’s important to understand how the Payment Gateway works and select a provider that meets your needs.

When you are selling products to your customers online, purchases are not completed “on your website” directly, even if this is how ecommerce transactions are often summarized. In reality, the technology piece that bridges the gap between you and your virtual customer consists of a few steps.

This is a high-level overview of the process every online transaction goes through:

This process usually takes about 2-3 seconds and the funds usually arrive in your provider’s account within 24 hours.

As we just discovered, a payment gateway is an e-commerce technology that authorizes payments for online retailers. There are three kinds of payment gateways and it is important to understand the difference between them, because we will refer back to them below when we’ll be discussing the tracking setup of ecommerce transactions. I know these technical details are not the most exciting prose for some, but please bear with me for a minute. I promise, I’ll be quick.

If you are regularly shopping online, you’ve likely already submitted a payment via a hosted gateway before, even if you didn’t know it… via PayPal. The standard PayPal setup is a classical example of a hosted gateway. Most startups, small businesses, and nonprofits use a standard PayPal account for their online transactions. (That is, until they meet an analytics-focused digital marketer who would like to measure ecommerce conversions. More on this below).

If you have never completed a PayPal transaction, then this paragraph will describe how it works. When your customer, wants to complete the purchase of a product in their shopping cart on your website Example.com, they get redirected to https://www.PayPal.com, PayPal’s payment gateway. There, they enter their credit card details (or log into their PayPal account) and a few seconds after they hit “Pay Now”, they receive an order confirmation.

An integrated gateway, on the other hand, allows your customers to complete their purchase without ever leaving your website. This seamless process comes in two flavours:

• payment gateways that store payment information on your server.
• payment gateways that bypass your server.

From a security standpoint, I would recommend the latter. If you do store transaction details on your server, you need to ensure that you are complying with Payment Card Industry Data Security Standards (PCI DSS).

Integrated gateways usually require the work of a professional developer.

There is no one-size fits all approach, which explains why there are hundreds of payment gateway providers.

Those of you who follow my blog know that I’m not a fan of proposing plugins. Today, I’ll make an exception, because setting up payments gateways and data layers via WordPress are for advanced users and require more advanced coding and this is an introductory guide.

To put your mind at ease: The plugins I recommend are regularly updated (a big thank you to those wonderful developers who make sure that these plugins stay safe). From experience I can say that I’m quite happy with them. For those of you who have read my WordPress Security guides (for beginners and advanced) know that it’s a big deal for me to recommend certain plugins, because I usually try to work without them for security reasons.

If you do not with to use plugins for this integration, you can certainly also ask your developers to help you get started with ecommerce tracking by coding the data layer and payment gateway integration. The option you choose depends on your preference. I will only highlight the integration with plugins below.

In your Google Analytics account, head to “Admin” (gear icon at the bottom left) and then navigate to the correct account (left column), property (middle column), and view (right column) that you’d like to record the ecommerce tracking in.

Now, you will be greeted by the ecommerce setup. Make sure to toggle at the least the first option to ON. I’ll be toggling both to ON, because I adore data and will be setting up enhanced ecommerce tracking. I’ll keep the “checkout labeling” blank for now, but feel free to add clearly defined labels here that will make sense to you, such as “Checkout, Billing Payment”, for example.

And that’s it! You’ve now enabled ecommerce tracking in your Google Analytics account. Give yourself a pat on the back.

Now, there are two plugins that you can choose from.

• One plugin is called Enhanced Ecommerce Google Analytics Plugin for WooCommerce and it allows you to do just that.
• The other option (and the one I’ll be using today), is called DuracellTomi’s Google Tag Manager for WordPress. The reason I’m opting for this is that I’d like to set up enhanced ecommerce (hence the title of today’s post), not “just” ecommerce.

As always, if you haven’t recently done a backup of your site, do a quick backup (theme files and database) before you proceed. Some plugins don’t play nicely with some themes and it’s better to be safe than sorry. When you’re sure that you’ve got an up-to-date backup of your site, download and activate the plugin. I’ll wait.

Ready? Let’s go!

If you’re still on the plugin page itself, you can simply click on “Settings” link for that plugin. If you’ve navigated away, you can find it either under “Plugins” >> Installed Plugins or under “Settings” >> Google Tag Manager.

The configuration you choose greatly depends on your requirements. Below I’ll give you some ideas and explain what they’ll do.

Under General I’d recommend the following, but this depends on your needs.

Enter your Google Tag Manager ID.

Next, pick where you want the container code to be placed.

• Footer: The reason this is not recommended by Google is that GTM is a container for a variety of tags. The code of a page first loads the header, then the body and then the footer. If a user navigates away from the page (e.g. your “Order Confirmation” page) or interacts with your page before the footer has loaded, the tags in GTM wouldn’t have had time to fire and hence your tracking wouldn’t execute. Google is not the only one who wouldn’t recommend this option.
• I chose “Custom” because I like being in control in regard to where tags are on my site, and I’d like it placed as high up in my theme header as possible, so that my tags fire as early as possible.
• Codeless injection: As we’ve already discussed, some themes don’t play nice with some plugins. This option confirms this statement. Depending on your theme, this option may or may not work. If you want to select this option, you may want to try out the plugin in a test environment. If you see the code in the right spot, all went well. If it didn’t, you may need to tweak your header file to place it in the right spot. This is where the backup of your files comes in handy, in case you break the site and need to switch out the header file, for example.
• Off: This selection only adds the data layer to your website. If you already have the GTM container on your site, this one might be for you.

One note of caution: Do not just select this option and move on with your day. This option of the plugin ads the data layer AFTER your page title in the header. If you added your GTM container code BEFORE your page title, your GTM container won’t be able to pull data out of the data layer. The data layer has to be above your GTM container. For more information on this, please reference Google’s Developer Guide

Now you can either head to your theme’s header file and move the code up a notch or complete the configuration for this plugin first. The choice is yours.

Here you can now choose what data you would like to capture in the data layer. Please note that merely “capturing” data in the data layer doesn’t pass (push) the data on to Google Analytics. For that to happen, you’ll need to configure “events” either in Google Analytics or via the Google Tag Manager.

Posts:

This may be useful when you’d like to “score” the content of your website, for example, when you wish to determine the popularity of your content within a 30 day window of publishing (check “post date”); when you have multiple authors and you’d like to determine which ones produce the most engaging content or may be deserving a raise (check “post author”), etc.

How you use this data is ultimately up to you. The data that is passed on to the data layer when you enable this is as follows:

• pageTitle
• page Attributes
• pageCategory
• pagePostAuthor
• pagePostAuthorID
• pagePostDate
• pagePostDateYear
• pagePostDateMonth
• pagePostDateDay
• pagePostType
• postCountOnPage
• postCountTotal

Search:

If you’ve already enabled site search tracking in Google Analytics, you can ignore this option. Not sure? Head to Admin >> Select the View in question >> Settings. Please note that site search tracking needs to be configured for each view.

One more note on site search: If your search results by default return something like this: www.example.com/sitesearch without providing the search term in the URL, you now have the option to capture the following values via the data layer. How you use this information is up to you:

• siteSearchTerm
• siteSearchFrom
• siteSearchResults   (this variable will include the number of results on the search results page.

The latter may be helpful if you’d like to optimize your search results pages, because it tracks the number of search results that were shown and allows you to identify search terms that return empty result pages.

Visitors:

If you allow your website visitors to log in to your site to access their account, here’s how you can tell the data layer to capture whether or not a website visitor is logged in. This can be important if you’d like to compare your conversion rate for new and already existing visitors. For a general overview, I’d recommend checking Google’s Help Forum on User-ID Tracking.

With this checkbox ticked, this plugin will pass the following data on to the data layer:

• visitorId
• visitorLoginState
• visitorType

AdWords (soon to be called Google Ads):

If you’re using remarketing, feel free to check this box. Please note: Remarketing requires additional transparency when it comes to cookies and privacy policies. Ensure that you are transparent about how these are used on your site. If you are marketing to individuals in the European Union, ensure that you follow GDPR regulations. Not sure? Reach out for help.

Browser/OS/Device

If you just want to analyze browser data for your website visitors, there’s no need to check this box, because Google Analytics does this already by default. If you need the browser data for your GTM tags, however, (e.g. to display a certain message to a certain browser), then this is how you can configure it. With this checkbox ticked, the data layer will receive the following information:

• browserName
• browserVersion
• browserEngineName (e.g. “Blink” for Chrome, “Gecko” for Firefox, etc.)
• browserEngineVersion
• osName
• osVersion
• deviceType
• deviceManufacturer
• deviceModel

Weather data

It’s a cute thought and I’ve seen some neat implementations of this (e.g. song suggestions based on weather), however, I assume that most of us can refrain from checking this box. Here are the data layer variables that enabling this checkbox lets you access:

• weatherCategory
• weatherDescription
• weatherTemp
• weatherPressure
• weatherWindSpeed
• weatherWindDeg

Site

Unless you’re working in a multi-site environment, you won’t need to worry about this. If you are interested in this option, it lets you access the following data layer variables:

• siteId
• siteName

Misc

Currently the only option to choose from here is “Geo data.” If you’re scratching your head about whether or not you’ll need to check this box, here’s a rule of thumb: If it’s for “tracking purposes” only, leave it unchecked. For the most part, Google Analytics will place the user into the right bucket in your reports.

If, on the other hand, your website serves people internationally and you want to customize their experience (e.g. display the visitor’s currency or direct them to a translated version of your website), then you may want to check this box. Obviously the checkbox itself doesn’t take care of the currency settings or redirect, that part you’ll need to configure separately, but it provides the data about the visitor’s location via the data layer.

I wouldn’t recommend checking any of the boxes under this tab, because event tracking is best configured in GTM directly.

For on-page scroll tracking that you’d like to see in your analytics reports, I’d recommend using GTM’s scroll tracking feature. In GTM you can then also configure, for example, that a certain popup appears when a user has passed a certain scroll threshold.

If, on the other than, you’re in testing phase and don’t want scroll tracking events to clutter up your Google Analytics data, then you can select this option and check the box next to “Debug mode.”

For the time delay option, I’d like to add a note of caution: Google Analytics tracks a maximum of 500 “events” during a session. It’s therefore important not to fire this tag every second. As a rule of thumb: For timed events, usually a 30 second threshold will do the job. It depends, however, on your tracking needs.

I’d follow the recommendations of the author not to touch this section unless you know what you’re doing, especially if you are working with a team of individuals on your tag deployment. Before you adjust the settings here, it is highly recommended to check with your developers and marketing team and ensure that your settings won’t affect their work. If you do adjust the settings, publicize it to all parties involved so they can include this plugin in future troubleshooting protocols.

Contact Form 7

Contact form submissions can be accurately tracked via GTM and I wouldn’t recommend checking this option unless you have a particular reason to.

WooCommerce

In this section, you enable transaction data to be passed to the data layer. If you don’t check any of the boxes here, you won’t see transaction data in your analytics reports. Here’s an example of what the configuration of this section could look like:

Google Optimize

Google Optimize is a fantastic multivariate testing platform and allows personalization of your website content to optimize user experience on your website. If you’re using it, I’d recommend enabling this integration.

I’d recommend not touching these unless you know exactly what you’re doing. Changing the name of data layer variables can have consequences on your tracking. The “environment” parameters refer to your GTM environments. If you need to activate a certain environment (e.g. for testing), this is one option to set them up.

If you’d like to see where you can send your “thanks” for having created such a wonderful plugin, here’s where you can find that information.

Now we need to make sure that the code that we wanted to “customize” is as high in the header as possible (or if you chose the “off” option, that your data layer code is ABOVE the GTM container snippet).

Refer to your web hosts support documents and knowledge base articles to locate your theme’s header file. Once you have found it, download a copy of your header file (as a security backup) and then edit the theme header file on your server.

This is what my theme header code looks like after the edit. Yours will look different, depending on your theme.

When you move the GTM code around, make sure not to interrupt any PHP code. This could potentially break your site. There’s no shame asking your developers for help, even if this task seems simple. Again, it’s better to be safe than sorry. If something does go wrong, upload the security copy you made of the theme header file before the edit to your server, so it will overwrite your latest changes. Then, try again.

As you can see, I don’t interrupt the PHP code that initiates the <body> content and added the code that the plugin developer provided before the <!–comment–>

After you’ve successfully added this piece of PHP code, you’ll see the following snippets in your website code appear:

This piece of code is initiating the data layer.

This code places the GTM container on the site, in the <head> section below the data layer, as recommended by Google.

And finally, this one is the “backup” script (in case JavaScript doesn’t execute), which was placed into the <body> section of your website, as recommended by Google.

Everything is where it’s supposed to be.

Again, I’d recommend Stripe, but you can integrate any other integrated (on-site) payment gateway. WooCommerce has supporting documents for the setup.

And yes, theoretically, you could create an automated redirect for PayPal. As indicated before, however, this is suboptimal, because you’ll be missing all transaction data of purchases made by credit card and only record those that were made via a PayPal account.

Go ahead, I’ll wait.

Finally, you’re ready to make a test purchase and see if everything goes smoothly. I’d recommend making a purchase in test mode first and then an actual purchase through your site. You can reimburse yourself after.

• If you offer coupon codes, test purchases with and without coupon codes to see if all data gets captured correctly.
• If you’re filtering out your own IP address from Google Analytics, ensure to look for the transaction data in a view that doesn’t filter out your own (internal) traffic.
• If you are using PayPal Standard with an auto-redirect, make sure to include PayPal.com and your own domain, in your Referral Exclusion List in Google Analytics: Admin >> Property >> Tracking Info >> Referral Exclusion List. If you see any other checkout related referrals in your referral reports (e.g. secure.checkout.com), add them to this list as well. You want your data as clean as possible, so that self-referrals aren’t taking credits for conversions that other channels should get credit for.

You’ve now (hopefully) successfully configured ecommerce tracking for your WordPress WooCommerce store. Congratulations! If your setup wasn’t successful and you got stuck, please reach out for help.