In this article, we will document the audit of the ecommerce module in Google Analytics 4 that we conducted for one of our clients. The goal of this article is to present an example and scope of work involved in auditing and setting up GA4 for custom-built services and online stores.
Why Track Additional Data in Google Analytics?
The main purpose of tracking this data is to enable further analysis of advertising channels recorded in Google Analytics. For example, it helps compare the effectiveness of Google Ads versus Instagram ads. Setting up the ecommerce module in GA4 not only allows us to compare lead costs across channels but also lets us collect revenue data from those channels for performance comparison.
Audit Results and Format
The conversion audit and technical requirements for setting up the GA4 ecommerce module are documented in a Google Doc.
Introductory Information
This document captures the analysis of the current state of web analytics, particularly conversion data. It also outlines the technical requirements for additional configuration.
Project Information Website – [project website]
Website Technologies
- Frontend: React.js, Next.js
- Backend: FastAPI (Python 3.11)
- Database: PostgreSQL
- API Type: REST
- Cloud: DigitalOcean Apps, Spaces (S3)
- Version Control: GitHub
- CI/CD: GitHub Actions
- Unit Tests (Backend): Pytest
- Containerization: Docker Compose
Web Analytics Tools
- Google Analytics 4 Property ID: 398895458
- GA4 Data Stream ID: 1265998177
- GA4 Measurement ID: G-FCS3V6HH2L
- Google Tag Manager Container ID: GTM-HHLSGH5B
Web Analytics Code Review
Placement of Analytics Codes The primary and secondary GTM code snippets are generally implemented correctly. The code includes several customisations and additional configurations. GA4 and DataLayer codes are also embedded, along with various other scripts, some of which are not properly implemented.
Web Analytics System Review
Google Tag Manager Overview The GTM container is generally configured correctly.
Tracking Key Actions GTM is configured to track meaningful user actions and transmit them to GA4.
Conversion Tracking Conversion tracking configurations exist in GTM and the website’s source code for ticket sales. However, as the audit will show, the tracking is inaccurate.
Conversion Testing The audit and further setup were prompted by the assumption that GA4 correctly tracks ticket purchases—both immediate online payments and reservations with driver payments. However, the analysis revealed that conversion tracking has multiple significant errors.
Test Purchases We conducted ticket registration tests using the following details:
- Name: TEST
- Surname: TESTOVICH
- Phone: repeated digit pattern
- Email: [email protected]
Testing Results On 2024-05-21, we conducted several test purchases with the “pay the driver” option. Analytics successfully recorded the conversions, but the total conversion value reflected only the last transaction.
Conversion Statistics Analysis
Sales Table Review We analysed the current order stats file, which shows:
- April & early May 2024: only 15–18% of users paid online, accounting for ~12–13% of revenue.
- 82–85% preferred paying the driver, accounting for ~86% of total ticket revenue.
GA4 Ecommerce Report Analysis The ecommerce reports in GA4 do not accurately capture all sales data. Example fragments of consolidated reports are available, but only partial data is being recorded.
Table vs. Report Comparison We compared the ticket sales table and GA4 report for the period 2024-04-01 to 2024-05-21:
- April: 223 sales in total (35 online, 188 driver); revenue = 636,553 UAH (86,795 UAH online, 549,758 UAH in-person).
- GA4 report: 237 sales, 468,489 UAH total revenue.
- May 1–21: 210 sales (37 online, 173 driver); revenue = 590,055 UAH (78,709 UAH online, 511,346 UAH in-person).
- GA4 report: 183 sales, 143,177 UAH total revenue.
Discrepancies are significant and warrant further investigation.
Systematising Conversion Tracking
General Information
Since the conducted analysis revealed that conversion tracking contains significant errors, it makes sense not only to identify and locally fix those errors, but also to carry out a more comprehensive systematization of e-commerce event tracking on the website.
Tickets as Products
Within the scope of this project, it is reasonable to consider tickets as individual products that differ by departure city and destination city.
This will allow building informative reports based on combinations of departure and arrival cities in the future.
Tickets as Product Pairs
Another slightly specific but interesting approach is to record the viewing or purchase of a ticket as a combination of two products — the departure city and the destination city.
In this case, more convenient and insightful reports could be generated in the future regarding the economic popularity of specific cities.
Product Categories
At the top level, the country can be recorded as a product category.
Product Category Hierarchy
A potential structure could include four levels of nested product catalog categories:
- First level – departure country
- Second level – destination country
- Third level – departure city
- Fourth level – destination city
This structure would also allow for highly informative reporting on cities and countries.
Brands
The name of the carrier can be tracked in the web analytics system as the product brand. This will enable reporting by different carriers in the future.
Product Parameters
Additional information from the products should be recorded in the web analytics system as product parameters.
In particular, a very important parameter is the departure date and time of the purchased ticket.
Other purchase parameters include the passenger’s name and phone number.
Transaction Parameters
Date and time of the purchase will be automatically recorded as transaction parameters.
Another key transaction parameter is the selected payment method.
It is also possible to generate and record unique transaction IDs at the site engine level in the analytics system.
Conversion Value
At this stage of web analytics setup, the conversion value can be recorded as the total cost of purchased or reserved tickets.
Accordingly, the product sale value is the price recorded considering possible discounts and benefits for certain routes or carriers.
Conversion Tracking
The main event that must be tracked is the completed conversion — the purchase of one or more tickets.
Product View Tracking
In addition to conversions and product sales, we can also track product views.
In particular, when a user selects a departure city and a destination city in the form, this can be recorded as a product view.
Add to Cart Tracking
Clicking the “Buy” button can be recorded as an “add to cart” action.
In the future, this may enable remarketing for abandoned carts.
Checkout Step Tracking
We can track users’ progress through the individual steps of the checkout process.
Specifically:
- The first step involves entering personal data.
- Then, selecting payment options.
- Then, payment via acquiring.
- Finally, confirmation and delivery of the ticket in electronic form.
Tracking these steps will help ensure users complete each stage properly and reach the final ticket delivery page.
Testing shows some problems exist, but only real-time tracking, data collection, and further analysis can show how often they occur for actual users.
Cancellation Tracking
The actual boarding and payment-to-driver rate may be significantly below one. It can also vary greatly across cities, marketing channels, and time periods.
To monitor this metric and eliminate obviously incorrect transactions, it is advisable to implement cancellation tracking.
This can be realized as product returns. However, this requires not just website configuration but also a basic CRM system to handle orders.
Essentially, this is the first step toward full-funnel marketing and sales analytics.
Profit Tracking
The second step toward full-funnel analytics is tracking not just sales value but gross profit from specific sales for the company.
This will make it possible to monitor and optimize ROI of paid traffic segments across campaigns, ad groups, creatives, audiences, and other parameters.
Technical Tasks for Data Layer Preparation
General Information
This section outlines the technical tasks that need to be implemented on the site engine side.
They relate to configuring a special JavaScript variable called the Data Layer.
On various pages and under different conditions, values of various parameters need to be pushed into this variable. These values must be pulled from the site engine’s code.
Below, the parameters that should be replaced with actual values are indicated in angle brackets (<>). Both the brackets and the content inside should be replaced with actual values.
Attention! It’s very important to keep the surrounding double quotation marks (“”) at the start and end of values if specified in the code templates and examples.
Existing Code
Certain code blocks, similar to those shown below, have previously been added to some sections of the site.
They were intended for tracking sales. However, as outlined earlier in this document, they contain significant limitations and even errors.
Therefore, please document the location of these code blocks. Also, we recommend saving the current version of the site before making any changes.
Afterwards, while implementing the codes shown below, please delete or very carefully update the existing code to match the new structure exactly.
Viewing Tickets by City Pair
Conditions for Code Execution:
This code should be triggered upon page load when available or unavailable routes are displayed for the selected departure and arrival city pair — i.e., during the page load process of the available routes.
Page Template:
The URL of these pages begins with [site URL] and then contains the names and codes of the departure and arrival cities.
Code to be Placed and Triggered for Execution:
Example of corresponding parameter value assignment:
Selecting a Specific Ticket
Conditions for Code Placement and Triggering:
This code should be triggered after clicking the “Select Ticket” button, once the user has chosen a date and a specific route for that date.
Page Template:
The same pages as described in the previous section.
Code to Be Triggered:
Example of corresponding parameter value assignment:
Start of Ticket Checkout
Conditions for Code Placement and Triggering:
This code should trigger upon opening the “Ticket Checkout” page.
Page Template:
The URL of these pages starts with [site URL] and includes the hash code of the selected route.
Code to be triggered for execution:
Example of corresponding parameter value assignment:
Adding a Passenger
Conditions for Code Placement and Triggering:
This code should trigger on the “Ticket Checkout” page after each click on the “Add Passenger” button.
Attention! It must trigger after every click.
Page Template:
The same page as in the previous section.
Code to be triggered for execution:
Example of corresponding parameter value assignment:
Transition to Payment Parameters
Conditions for Code Placement and Triggering:
This code should trigger on the “Ticket Checkout” page after each click on the “Next” button, but only if all required data is filled in and the user proceeds to the payment parameters page.
Attention! If any required data is missing, this code should not run.
Page Template:
The same page as in the previous section.
Code to be triggered for execution:
Example of correctly filling in parameter values:
Selected Payment on Boarding
Conditions for code placement and triggering:
This code should be triggered at the second stage of the “Ticket Booking” process, specifically after clicking the “Payment on Boarding” button.
Attention! This code must only be executed if all validations are passed, particularly if the checkbox “I agree with…” is enabled.
Page Template:
The URL of this page matches the template.
Code to be executed:
Example of filling in the parameter values:
Selected online payment
Terms of placement and activation of the code:
This code should be activated at the second stage of “Ticket purchase”, namely after clicking on the “Online payment” button.
Attention! This code should only be executed if all checks have been completed, in particular if the “I agree with …” checkbox is selected.
Page template:
The same as in the previous point.
Code to be initiated:
Example of filling in the parameter values:
Tickets sold out!
Terms of placement and code activation:
This code should be activated when the final “Done!” page loads, confirming successful ticket booking and payment, if this option is selected.
Page template:
The address of these pages begins with [website URL] and then contains the transaction code.
Code to initiate execution:
Example of filling in the parameter values:
P.S. If you have any questions about this technical task and audit, you can submit a request for consultation on our agency’s website – https://spilnoagency.com.ua/
Leave a Reply