How does Tracking Monitor work?

Tracking Monitor is a key Tag Concierge Platform feature that allows to gather insights about eCommerce tracking performance. It gives both high-level overview and detailed reporting about all eCommerce events and their properties.

Reporting

The main part of the Tracking Monitor is set of reports around eCommerce events

Transactions

This is a view of latest transactions that have happened in your eCommerce in selected time window. The report shows every transaction separately with last digit of the transaction ID to help identify it. In addition to main transaction information it shows tracking status. First if the order confirmation page was visited which is a requirement for the browser tracking to happen. Second if the server event was tracked, and lastly if the browser event was captured.

Events

This is detailed breakdown of all trackable eCommerce events that allow to compare the browser side tracking performance. The table shows counts of each event type for browser and server side tracking. As the server-side tracking should be the most reliable source of information there is ratio parameter next to the browser-side number to show percentage of correctly tracked event. With traditional setup browser side tracking is what will end up going into Google Tag Manager web container and associated services.

There is additional column showing how many of the browser events were tracked while an adblock software was detected. As our tool is not a tracking tool there are low chances that it got blocked so it can show how many of the events probably didn’t go to tools such as Google Analytics or Google Ads which are primarily being blocked by privacy software.

What data is tracked and how?

In order to provide the reporting Tracking Monitor needs to capture eCommerce events both from the visitors browsers and from the eCommerce back-end to perform the comparison.

The front-end tracking is implemented as additional GTM preset that triggers the Monitor tag for each eCommerce event triggered. This calls our global, low-latency edge network that captures all events without slowing down the websites.

The back-end tracking does pretty much the same but on the WooCommerce server as PHP hooks. The HTTP calls are wrapped in exceptions blocks so even in case of networking issues they will not impact the back-end performance and stability.

In both cases the data being sent to our servers is the same and it is primarily the eCommerce event itself and contains:

event name
event timestamp
event items (includes product ids, names, categories, prices and variants)
event value
event currency
event metadata (includes adblock detection and generic consent data)

In case of transaction additional datapoints are captured:

transaction id hash – this is not the actual transaction id, but a hash computed based on the id. The hash is fixed length string that and computation logic always gives the same result for the same input, but it is not-reversible. It means that based on hash we cannot tell the actual id, but we can tell that two events with the same hash are related to the same transaction
transaction id part – in addition to the hash that allows performing all the analysis in our platform we also capture last digit of the actual transaction id which allows you to understand which transaction is being shows in our UI
transaction timestamp
transaction items (includes product ids, names, categories, prices and variants)
transaction details (includes status, value, refunded value, currency, payment method and confirmation page url)

Is visitors privacy respected?

Yes, the Tracking Monitor tracks the events and not the users. It does not store or read any first or third party cookie. It does not generate any kind of identifier for the user, browser or the session (known as fingerprinting). It also avoids tracking the only identifier that could be potentially linked to an individual which is transaction ID (see notes about transaction ID hash above). This hashing happens in the browser and in the eCommerce back-end so the actual ID never reach our servers.