Google Analytics 4 (formerly App + Web) Ecommerce Tracking Part 2: Purchase Tagging
October 28, 2020 -
How to deploy your GA4 tags, using your Universal Analytics dataLayer schema
It’s been a busy few weeks for Google products! With the launch of Google Analytics 4, and Google Tag Manager’s new preview functionality, there’s been a lot of exciting things happening.
While this isn’t a new feature to the GA4 release (it’s been around for at least a couple months now), it’s definitely one I’ve been excited about exploring more from the implementation side, and that’s the backwards compatibility between the Google Analytics 4 (formerly App + Web) tagging and the Universal Analytics dataLayer.
Just a quick recap: when the Ecommerce schema was released for App + Web tracking on a desktop site, earlier this year, I was a little bit concerned to see that the ecommerce object differed just enough that it would require duplicating data in our dataLayer to support a dual deployment of Universal Analytics and App + Web. At the time App + Web tagging itself was not backwards compatible with the Universal Analytics schema, BUT, I’m happy to say that it is backwards compatible now, meaning we can reuse the dataLayer we already have for Universal Analytics, to a certain extent.
In my first post on this topic, I focused on our Ecommerce events leading up to the Checkout / Purchase funnel. Today, I’m going to focus on using what I learned in Part 1 to build out my purchase tracking.
Before we start.
I originally wrote Part 1 RIGHT before the relaunch of App + Web as Google Analytics 4, and all of the new features that came with it. So if you’re revisiting my Part 1 post, and see App + Web or A+W referenced, just replace it with Google Analytics 4 or GA4. As such, it also means some of my tag naming conventions have changed. I had been referring to many of my tags, and variables with App + Web or A+W prefixes. In this post, you’ll see these referred to now with GA4 prefixes. Do you need to update these? No, it doesn’t change the functionality of the tags at all, it’s really just to align with the relaunched name.
Will now look like this:
What’s different about the Purchase event?
For the most part, how we need to configure the items parameter to capture our ecommerce.purchase.products array is exactly the same as the items mapping we walked through in Part 1. But, we also need to capture additional parameters like our transaction id, revenue, tax, shipping, and any coupon codes or affiliations that might be associated with our purchase. Whereas, with our GUA tagging these would be picked up automatically from the dataLayer and mapped to their equivalent parameters, they each have to be mapped to their own GA4 Event parameter on our purchase tag manually (as far as I can tell). I’m not gonna lie… this is a bit of a pain when compared to how we were able to do this previously on our Universal Analytics tags, BUT the positive is that it does allow more flexibility in where we pull this data into our tagging from. See the below table for the associated mappings for each event parameter between GA4 and GUA.
Purchase Data Variables
The first thing I’ll do is configure each of our Data Layer variables needed to map to our purchase tag.
If you read part 1, this is similar to what we have to do for our products array.
In GTM, go to our Variables tab > User-Defined Variables > new Data Layer variable
Create one for each parameter. We’ll start with our items variable.
Name our new variable Data Layer – ecommerce.purchase.products
In the Data Layer Variable Name, enter: ecommerce.purchase.products
Following this same process, go ahead and define one new variable for each of the parameters listed in the table drafted above (or, at the very least, the ones you’re using), with your Data Layer Variable Name field, mapping to the equivalent purchase key in your ecommerce object.
For each variable, you should end up with something that looks like this:
Once done, you should have a set of variables similar to this:
GA4 – Purchase event tag
Now that I’ve created all these variables, I’ll go ahead and set up my purchase tag.
This is worth mentioning because of the recent new release for Google Analytics. Previously, these tag templates would’ve referenced App + Web, but the tags we’re now going to work with will reference GA4.
In GTM> Tags > create a New Google Analytics: GA4 Event tag.
As we did in Part 1, the first thing we need to do is assign a Configuration tag to our new event tag. If you don’t yet have an existing Configuration tag , set that up before you go any further, as it will be required for our Purchase tag.
From the Configuration Tag drop down, select the Config tag that’s being used for the bulk of your GA4 tags, so far.
Next, in the Event Name input field, we’ll specify purchase. This is the value that will tell Google Analytics that this will be a purchase event.
Then, under our Event Parameters, we need to create one mapping, per Data Layer variable that we defined above for our purchase data. Once done, your mappings should look similar to this:
And then finally, we need to bind the same trigger we’re using for our GUA purchase tag, to this new A+W purchase tag.
I now have a purchase tag that looks like this:
- Create a variable to output your ecommerce.purchase object
- Create a Custom JS variable to evaluate the existence of the ecommerce.purchase object as a boolean
As I mentioned previously, this is a simple way to go about this in GTM only, but I do recommend (especially because this is your Purchase event) that if you can, work with your development team to split up your existing ecommerce.purchase data from the bulk of your page load data, sending your purchase data as a custom event instead.
Purchase Data collection in GA4
Now that we’ve set up our tag, let’s enable GTM preview, and move over to our browser and trigger some purchase events to see what this data will look like.
So first off – again – a lot has changed since my first post, including GTM preview. So now, when we preview, things will look a little different than they did before. You’ll need to go through a slightly different process to enable GTM preview, but once enabled, it will now run in it’s own tab, whereas before, it ran in the foot of your existing web page.
Now, when I trigger my purchase event, I can see my tag firing in GTM preview:
If I jump over to Chrome’s Dev Console > Network tab, and check my collect hits, I can see that my GUA purchase event data, still looks like this:
And my, GA4 purchase hit, looks like this:
My product data is nested under the pr1 variable as we’d seen in the pre-purchase events, and the additional purchase parameters each track as their own event parameter (ep) value. Something else you may notice in the event parameters themselves is the %20 character inclusion. Not to worry this gets cleaned up on the reporting side, so won’t show in your actual data.
Checking our Data
Once more, to echo various other parts of this post: A lot has changed since my first post. Including our reporting structure. Whereas before we’d go to our Ecommerce tab to have a look at our Product data, we’ll now click in to Monetization > Overview.
And this will give us a landing page very similar to our original Ecommerce landing page, with many of the same Report cards available to us, plus some new ones.
First thing we’ll notice in our Overview page is that the Ecommerce revenue field holds a value this time, and it lines up with the value event parameter we captured on our GA4 purchase event.
Scrolling down to the second row of Report cards, we’ll recognize a couple we worked with last time: Ecommerce purchases by item name, and Ecommerce purchases by item list name.
Starting with Ecommerce purchases by item name, this time we’re able to see the number of purchases by product name in the report card itself, as we triggered an actual purchase event.
Click in to this report, and we can get a further break down of ecommerce eventing on our Triblend Android T-Shirt product:
We can see that when reporting by the product name, we have our one Item view, One Add-to-carts, and one Ecommerce Purchases, as well as the Item revenue of $15.25 that we see on our purchase hit under the pr1 event param. Great!
Next, we’ll jump back out to the Overview page, and scroll down to the second row of Report cards, this time focusing on the Ecommerce purchases by item list name card. Now, as in Part 1, this still shows as having no purchases by list name. This isn’t surprising, as we had noted that product list tracking for my particular test pages isn’t working consistently across GUA and GA4 tracking, due to a feature of GUA tagging that hasn’t been carried over to GA4 tagging (Product list ‘attribution’). However, when I click in to the report itself, I’m able to see some data showing up relating to my product lists. I can first see that the Product Impression event that was triggered (with a list name of awNoProdAttribution), was captured as expected, against that list name.
But again, as we saw in Part 1, all of my other ecommerce events like Item list clicks, Add-to-carts, and Ecommerce Purchases are being attributed to (not set).
All the data is there, the ecommerce events are being recognized and captured as expected, so are working properly. But, due to the lack of a recognizable product list parameter on my Product Click through Purchase events, leads to it getting bucketed under my (not set) list. For a full explanation of why this is, checkout the ‘Checking our data’ portion of Part 1.
If we again jump back out to our Overview page in GA4, and scroll down to row 3, we’ll also see that we’re capturing some coupon data this time, under the Ecommerce revenue by Order coupon report card.
If we click in to this report, we can get some further details on the revenue associated with this FALL_SALE coupon code. So we’re able to see one Ecommerce Purchase, and it’s accurately capturing the dollar value we’d passed in our value event parameter.
And then finally, if we scroll down to Explore, and then click in to Analysis Hub, and revisit (or recreate) the Exploration report we worked with in Part 1, we can break down each of the ecommerce events themselves for the Triblend Android T-Shirt to see all events triggered on the product, similar to this:
The customizations I’ve made to this are:
Under Dimensions, in the Variable column, add Item ID and Item name. Then, under the Tab Settings column add these Dimensions to your Rows.
Under Metrics, in the Variable column, add Item list views, Item list clicks, Item views, Add-to-carts, and Purchases. Then, under the Tab Settings column add these Metrics to your Values.
This time, by also including the Purchases Metric under Values, we can see there was one event each for Item list views, Item list clicks, Add-to-carts and Purchases.
Checking all of this, I feel fairly confident all of my ecommerce events are triggering as expected, and collecting as expected. I’m getting the right number of ecommerce events that were triggered. I’m able to see proper quantities, and accurate values for purchase revenue and product revenue.
So now I’ve:
- Set up my Google Analytics 4 purchase tag to dual deploy alongside my Universal Analytics tag, using the existing Universal Analytics ecommerce object schema present on my purchase page.
- I’ve triggered a series of test hits onsite to verify that the data set in them is accurate, and complete.
- I’ve validated that the hits are appearing in Google Analytics 4 reporting as expected (with limitations relating to Product List tracking, unfortunately).
As I mentioned at the top of this article, there has been an insane number of updates made to Google products since my last post. Whether it’s updates to the GA4 reporting suite, or updates to Google Tag Manager – what with the new preview mode, or bulk updates features – there’s a lot to be excited about.
As for our Ecommerce tagging and GA4, there’s nothing that’s changed as to how we need to configure our tags, so nothing we need to keep an eye on that we did in Part 1, that will impact what we’ve set up so far, so all good there.
As mentioned in Part 1, GA4 is still in Beta, so we can expect there to be further additions, updates, etc. to what we’re seeing now, so it’s still highly recommended that GA4 be deployed alongside a Universal Analytics deployment.