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.

Ecommerce Tracking for WordPress: An Overview

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.

How does Ecommerce Tracking work?

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.

Overview of an Ecommerce Transaction

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:

Overview of an Ecommerce Transaction

When a customer completes a purchase on your website, the payment details are now either sent to your server or directly to the payment gateway.

If this information indeed goes through your server, your payment setup needs to be compliant with Payment Card Industry Data Security Standards (PCI DSS). One of these requirements is having a valid SSL (Secure Socket Layer) certificate, which turns your http site into an https site (“s” for “secure”). This allows your customer’s browser to encrypt their credit card information.

The payment information then get passed on to a secure payment gateway (e.g. Stripe or Paypal). This payment gateway connects your website’s checkout submissions to the processing network. It is the virtual equivalent of the point of sale terminal that many brick-and-mortar retailers use.

Next, the payment gateway passes the transaction details on to the payment processor of your bank. The payment processor is the technology that does all the heavy lifting, as highlighted in the graphic above.

The transaction details are now routed to the corresponding card association (e.g. Visa or Mastercard) to request transaction authorization, except in the case of American Express and Discover, who also act as the issuing bank (more on that in step 6 below).

The card association now forwards the transaction information to your customer’s bank, who had issued the credit card (hence the name “issuing bank”), to verify the available credit. Depending on the outcome, the transaction now gets either authorized or declined.

The authorization response is then sent back to to the payment gateway.

The payment gateway now returns the transaction assessment for display on your order confirmation page (also often called “thank you” page).

Lastly, if the transaction was successful, the issuing bank authorizes the transfer of the funds to your “nominated account” (e.g. PayPal or Stripe).

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

Payment Gateways

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.

Hosted (Off-Site) Gateways

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.

PayPal Tracking

Pros: 

  • Security: Customers’ payment details are handled off your website by the gateway service provider.
  • Trust: If you are using a well-known, trusted hosted gateway provider, your customers might be completing their order on the provider’s page.
  • Simple: The platform takes care of the payment setup, you only need to customize the look.

Cons: 

  • Customer Experience: Being redirected to a payment provider’s website might be frustrating for your users, especially if the process on that page is not streamlined and involves multiple steps.
  • Ecommerce tracking: Many hosted gateway providers make proper ecommerce tracking difficult, unreliable, or impossible.
  • Design: Often, these providers offer little customization.

Examples of Hosted Gateways:

  • PayPal Standard
  • 2Checkout
  • Cashnet eMarket
  • TouchNet T-Link
  • Payza

Integrated (On-Site) Gateways

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.

Pros: 

  • Customer Experience: Customers don’t leave your website to complete their purchase.
  • Customization: The look and feel of your checkout process are handled by you.
  • Ecommerce tracking: Most integrated gateway providers allow ecommerce tracking.

Cons: 

  • Security: You are responsible for ensuring proper security of sensitive data.

Examples of Integrated Gateways:

  • Stripe
  • Authorize.net
  • Amazon Payments
  • PayPal Advanced (via iFrame)
  • PayPal Pro (via iFrame)
  • Adyen
  • BlueSnap
  • WordPay

Picking the Right Gateway for Your Business

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

Questions to consider when choosing your payment gateway provider

  • Does the gateway provider support businesses in your industry and country?
  • Does the gateway provider support preferred payment methods of your target market? Customers in Germany, for example, have very different payment preferences than customers in Canada, the US, or Asia. Do your homework before you pick your gateway provider.
  • What fees does the provider charge? Are there any setup fees and cancellation fees involved?
  • How easy is it to switch gateway providers if you need to? Some providers, such as Stripe for example, help you migrate credit card data from membership subscribers and the likes in a secure and PCI-Compliant way to your new provider? PayPal, on the other hand, will not allow you to transfer that data so all monthly subscribers would have to sign up again.
  • How reliable is your payment gateway both in collecting and in paying out funds? Read unbiased online reviews.
  • What is the payment gateway provider’s customer service like? Online reviews can give you great behind-the-scenes insights. Don’t judge customer service by the helpfulness of the provider’s sales team.
  • How are your customers’ payment details processed? Ultimately, you are responsible for that data, since it is submitted on your website, so you definitely want to know the answer to this question.
  • Where are your customers’ payment details stored and how? For example, with Stripe, your customers’ credit card details are never sent to your server (as opposed to PayPal). Instead, the data is sent directly to Stripe. Security-wise, this is a big advantage, because any credit card details that are sent to your server prior to reaching the payment gateway are vulnerable to exploits if there’s a security breach on your site.

Cost of an Ecommerce Transaction

As always in the business world, all involved middlemen take their cut when a transaction happens. For ecommerce transactions, the fees consists of the following four:

  • The Payment Processor charges an “authorization fee,” which is usually a fixed fee.
  • The Credit Card Association (e.g. Visa or MasterCard) receives an “assessment fee.” (Percentage Fee)
  • The Issuing Bank keeps a percentage of each sale, which is called an “interchange.” (Percentage Fee)
  • Your Bank charges a percentage fee for their involvement in the transaction. (Percentage Fee)

When a payment processors (e.g. PayPal and Stripe) indicates their transaction fees, you will usually see something like this:

2.9% + C$0.30

The 2.9% transaction fee here usually combines all percentage-based transaction fees mentioned above (credit card association, issuing bank, your bank), while the fixed transaction fee for the Payment Processor is quoted separately ($0.30 in this example).

Some providers also charge additional fees for their services, such as

  • registration fees
  • monthly fees
  • chargeback fees
  • cancellation fees

Which Payment Gateways does WooCommerce Integrate with?

WooCommerce allows you to choose from over 100 payment gateways to accept payments, such as

  • PayPal
  • PayPal Pro
  • Stripe
  • Autorize.net
  • WorldPay
  • Amazon Pay
  • First Data
  • PayFast
  • Square
  • and many more.

Requirements for a WooCommerce Payment Gateway from an Ecommerce Tracking Point of View

  • It must be an integrated (on-site) payment gateway.
  • It must be compatible with WooCommerce.
  • It must be compatible with Google Analytics ecommerce tracking.

From a digital marketing perspective, PayPal certainly is NOT my preferred choice, because it means trading customization, user experience, and ecommerce tracking for your convenience. There’s nothing wrong with going down that path when you’re just getting started, but if you are serious about growing your organization (that applies to nonprofits just as much as it does for commercial businesses), you should always put your customers first. Keeping them on your site throughout the entire checkout process through an integrated payment gateway is a best practice to follow (needless to say that you need to follow security best practices as well).

If I had to recommend one payment gateway out of the hundreds on the market, that best meets the requirements indicated above, I’d recommend Stripe, although it certainly is not your only option. And “no”, I’m not a Stripe affiliate, just a fan.

Reason why I love Stripe in particular:

  • It’s convenient for your customers, because they stay on your site.
  • It has great ecommerce tracking capabilities (surely you saw that one coming).
  • It’s secure, because the payment details of your customers bypass your server and are sent directly to Stripe. This means that it’s their responsibility to keep your data secure, not yours. This is non-standard for this industry. Even PayPal Advanced (which is only available for US and Canadian customers at this point in time), which is placed on your site via an iFrame, still passes all this sensitive data through your server before it reaches their system.
  • Price. Compared to other providers that offer on-site integration, Stripe is extremely competitive. There are no setup fees, no monthly fees, no cancellation fees, and their transaction fees are the same as PayPal’s.
  • Data portability. If you offer your customers a membership subscription (e.g. recurring monthly donations), it allows you to transfer your customers payment data to a new payment service provider (PSP), which is not the case for most other PSPs, such as PayPal, who make data portability difficult or impossible, likely in an effort to “lock you in.”

I’ll let you be the judge. If you absolutely love your PSP and it has “integrated” functionality, by all means, work with that. If you’re with a hosted payment gateway, on the other hand, I’d recommend switching to an integrated solution, if possible. Ecommerce tracking with hosted payment gateways is a lot more elaborate to set up (I won’t cover that workaround in this post) and unreliable.

That said, there are off-site PSPs, such as Moonclerk, for example, that are an exception. Moonclerk has Google Analytics integration, so you can easily configure cross-domain tracking for your WooCommerce store, and it uses Stripe to complete the transaction itself, so you’re doing well on the security side of things as well.

Now that we’ve covered the basics and understand the requirements for a successful WooCommerce and Google Analytics Ecommerce Tracking integration, the time has come to commence the setup.

Setting up Ecommerce Tracking for WooCommerce

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.

Step 1: Enabling Ecommerce Tracking in Google Analytics

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.

Enabling Ecommerce Tracking in Google Analytics

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.

Ecommerce Toggle in Google Analytics

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

Step 2: Setting up the Data Layer for WooCommerce

a) Download the plugin.

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

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!

b) Configure the settings.

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.

GTM for WordPress

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.

Google Analytics Site Search Tracking

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:

GTM for WordPress WooCommerce Integration

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.

c) Clean up the code.

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.

GTM container Code example

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:

Data Layer Code

This piece of code is initiating the data layer.

GTM Tag Container Snippet

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

Backup GTM code

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.

Step 3: Integrating Stripe with WooCommerce

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.

a) First, you’ll need to create a Stripe account.

Go ahead, I’ll wait.

b) Now, you can integrate Stripe with WooCommerce:

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.

Here are a few pointers:

  • 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.