Google introduces App + Web tracking for Ecommerce
APRIL 2020 / BY FLORIAN PERTYNSKI, SENIOR ANALYTICS SPECIALIST
One of IIH Nordic’s senior analysts, Florian Pertynski, shares his experience reviewing the new ecommerce features offered within Google Analytics: App + Web. This article is written for readers with a high degree of interest in digital analytics.
Since the launch of Google Analytics: App + Web in August 2019, Google have been working hard developing features and functionalities for the new platform. One of the critical items on the road map has been ecommerce tracking, which for many organizations provides the most valid use cases. We are excited to see that now, finally, Google have started to roll out ecommerce tracking for App + Web.
Most of us come with experience working with Google’s flagship analytics product: Universal Analytics. To make it easier to understand the difference between Universal Analytics Enhanced Ecommerce and the new measurement model App + Web, we have made a comparison overview.
The overview will give you a good idea of what ecommerce data you can now collect with App + Web and how it stacks against it.
_
Contents:
_
1. App + Web ecommerce data collection
1.1 Ecommerce actions (App + Web events)
1.2 Product parameters
1.3 Impression/view parameters
1.4 Checkout parameters
1.5 Purchase and refund parameters
1.6 Promotion parameters
1.7 Notes on tracking setup
2. Notes on reporting
_
3. Summary
_
4. Closing thoughts
_
1. App + Web ecommerce data collection
Let’s have a look at what we are going to gain – or, in some situations, lose – with the new App + Web ecommerce data when compared against UA Enhanced Ecommerce.
_
1.1 Ecommerce actions
App + Web ecommerce practically covers the whole scope of UA Enhanced Ecommerce.
The most significant difference is the way to measure checkouts: instead of ‘checkout steps’, we get predefined events reflecting the common steps in a checkout funnel: view_cart, begin_checkout, add_shipping_info, add_payment_info. It will definitely help Google standardise the data while giving us an easy way to understand what the data actually means. On the other hand, it means less freedom in defining out checkout tracking. So, swapping flexibility for clarity.
Also, we can track add_to_wishlist as an integral part of ecommerce reporting. A side branch of ecommerce user journey, overshadowed by the elder sibling of add_to_cart, the new measurement item is bound to encourage a less linear approach to ecommerce, including estimation of ROPO (Research Online, Purchase Offline).
| App + Web ecommerce action | Equivalent UA Enhanced Ecommerce object |
|---|---|
| view_item_list | impression (commonly referred to as ‘product impression’) |
| select_item | click (often referred to as ‘product click’) |
| view_item | detail (often referred to as ‘product detail’) |
| add_to_cart | add |
| add_to_wishlist | No equivalent in UA! This is bound to be useful for any website with a wishilst/save for later functionality. |
| remove_from_cart | remove |
| view_cart | checkout – in UA we can use ‘checkout step 1’ to record this action. App + Web.however, offers a more descriptive ecommerce event. |
| begin_checkout | checkout – again, instead of ‘checkout step X’, we get a predefined event in App + Web |
| add_shipping_info | checkout – same as above |
| add_payment_info | checkout – same as above |
| purchase | purchase |
| refund | refund |
| view_promotion | promoView |
| select_promotion | promoClick |
So it is practically 1:1 transposition of Enhanced Ecommerce (apart from Checkout and Add payment info actions, which form 2 predefined steps of a checkout flow).
_
1.2 Product parameters
With product parameters, App + Web covers the same standard items as Enhanced Ecommerce, with one great addition: the discount parameter, which allows to pass data regarding product price discount amount or percent.
Outside the standard scope, the App + Web documentation doesn’t mention anything about custom product-scope parameters, which would be equivalent to UA EE Custom Dimensions. I can imagine such parameters could be passed as a part of javascript product objects, but since ecommerce reporting is not in place yet, we can only wait and see.
Also, a small difference: that category names (5 levels) are passed as separate values, while UA uses a single variable with the values nested.
| App + Web parameter | Equivalent UA Enhanced Ecommerce parameter |
|---|---|
| item_id | id |
| item_name | name |
| item_brand | brand |
| item_category | category |
| item_category_2 | category (nested value) |
| item_category_3 | category (nested value) |
| item_category_4 | category (nested value) |
| item_category_5 | category (nested value) |
| item_variant | variant |
| discount | None! This is a new addition which addresses the common scenario of product discounts. Extremely valuable for analysis of impact of discounts on checkout behaviour. |
| price | price |
| coupon | coupon |
| currency | currencyCode (action-level) |
| affiliation | affiliation |
| quantity | quantity |
_
1.3 Impression/view parameters
Apart from the product parameters, the following are available with product impression and product view ecommerce actions:
| App + Web parameter | Equivalent UA Enhanced Ecommerce parameter |
|---|---|
| item_list_name | list |
| item_list_id | none – this is a new parameter in App + Web only |
| index | position |
_
1.4 Checkout parameters
One new parameter, associated with the add_payment_info event: payment_type. In UA, we can pass it as a custom dimension or the slightly awkward to use option parameter. The challenge with the former is that it is not part of Enhanced Ecommerce data and so cannot be viewed as a part of checkout flow. The latter is Enhanced Ecommerce, but is not available as a dimension. So this could be a very useful addition to the ecommerce module.
On the other hand, it looks like we are going to miss checkout step data. Instead of steps we’re getting 2 events: begin_checkout and add_payment_info. So less freedom to analyse checkout flow.
Along with this, we may be losing the aforementioned step option. (I won’t miss it badly, though. Anyone?)
| App + Web parameter | Equivalent UA Enhanced Ecommerce parameter |
|---|---|
| payment_type | No equivalent! |
| (parameter missing) | step (checkout step number) |
| (parameter missing) | option (additional checkout step data) |
_
1.5 Purchase and refund parameters
No new parameters here, no parameters missing either: purchase and refund parameters are 1:1 rendering of Enhanced Ecommerce.
| App + Web parameter | Equivalent UA Enhanced Ecommerce parameter |
|---|---|
| transaction_id | id |
| value | revenue |
| tax | tax |
| shipping | shipping |
| coupon | coupon |
_
1.6 Promotion parameters
Promotion tracking may be an underused element of UA Enhanced Ecommerce. One reason could be the dissociation from products, which often are the core subject of promotions. The EE tracking model is very simple: promotions come with an id and/or name, a name of the creative and a variable describing its position on the page.
App + Web, on the other hand, integrates promotions into user’s ecommerce journey, allowing to bind promotion data with products. This may be one of the most significant changes in ecommerce data collection.
| App + Web parameter | Equivalent UA Enhanced Ecommerce parameter |
|---|---|
| promotion_id | id |
| promotion_name | name |
| creative_name | creative |
| creative_slot | position |
| location_id | No equivalent! This is a new parameter to describe promotion location. |
| PRODUCT PARAMETERS: item_id item_name item_brand item_category item_variant index quantity price | No equivalent in UA EE! |
_
1.7 A note on setup…
GTAG is the only way to send ecommerce data for now (check out the new document specifying measurement methods).
If you still would like to go with GTM, there are no tag templates but you can use Custom HTML tags. Before sending the ecommerce data, you need to add the GTAG object (see documentation), also via a Custom HTML tag.
_
2. App + Web ecommerce reporting
Right now, no reporting is available in App + Web interface:
(from Google documentation page)
This means that while we can see the ecommerce action events (view_item, add_to_cart etc.), we have no access to the associated parameter values.
Similarly, BigQuery collects ecommerce event data but not anything beyond that. Still, we can see that the schema is ready to receive the data:
Looking at a view_item request, the product data is passed as a single query parameter, with product parameters delimited with a tilde character. Thus, you can see highlighted below: item_id, item_name, item_list_name, item_list_id, item_brand, item_category, item_variant, index (position in the listing), quantity and price:
So the schema and data collection methods are in place. We’re just waiting for Google to push the ‘GO’ button…
_
3. Summary
In short, what’s new:
- add_to_wishlist – this will allow tracking of the interaction as a part of ecommerce reporting
- new checkout steps – the checkout funnel is built of predefined events: begin_checkout, add_shipping_info, add_payment_info (also, possibly, view_cart)
- no checkout step parameter
- no more option parameter
- discount product parameter
- possibly, no product-scope custom parameters
- item_list_id impression parameter
- product parameters in promotion events – this will tie promotion data with product data, incorporating promotions into ecommerce flow
_
4. Closing thoughts
This is a huge milestone for App + Web. With more business use cases emerging, it is bound to increase the number adoptions. The more adoptions, the merrier the App + Web team is bound to be working on product development.
It’s great to see Google steadily completing ticking the boxes on the roadmap published in September 2019. With ecommerce, App + Web will now cover most UA’s key features:
If you need help future proofing your current tracking set up into the new App + Web standard, reach out to us at IIH Nordic.
