1. Home
  2. Docs
  3. Integration & Setup
  4. Tracking Code & SDKs
  5. Tracking Code Integration
  6. Transferring eCommerce Events
  7. Debug eCommerce tracking with etracker Analytics

Debug eCommerce tracking with etracker Analytics

A reliable database is the be-all and end-all for successful eCommerce management. Only on the basis of good data quality it is possible to measure the success of marketing activities.

A reliable database is the be-all and end-all for successful eCommerce management. Only on the basis of good data quality it is possible to measure the success of marketing activities.

However, in eCommerce tracking, it can happen that significantly fewer orders are recorded than in the store system, CRM or merchandise management system, or that no orders are recorded at all.

Even if 100 percent correlation between backend and web analysis system is hardly possible and deviations below 10 percent are normal (e.g. due to deactivated JavaScript), a closer look should be taken for deviations above this. This mainly concerns two areas:

a. Integration of the tracking code and setup of the general tracking.
b. Implementation of the special eCommerce tracking.

Let’s take a closer look at both areas.

Part 1: Deviations due to tracking code integration deficiencies

1. Tracking only after consent

The main source of data leakage is tracking only after consent. This is because, depending on the design of the consent banner, the consent rate averages only between 20 and 40 percent. Some consent managers also automatically block external scripts. Therefore, it should be checked whether the interaction with etracker Analytics and the consent management tool works correctly (see manuals for the common Consent Management platforms). To check this, the basic report Month & Year can be called up, for example. If the percentage of visits with cookies is 100 percent, action is required.

2. Browser extensions for ad and tracking blocking

Browser extensions like Ghostery or Adblock with strict configuration can block data collection. On average, this affects about 15 percent of website visitors and therefore orders. Data loss due to ad and tracking blockers can be avoided by collecting data via a custom subdomain. This tracking option can be added to all etracker accounts. Here you can find more information about tracking via a custom domain.

3. Do not track parameters in the etracker code

The Do Not Track function is activated in around 15 percent of browsers. In the case of B2B websites, the proportion can be significantly higher, as the browser configuration is specified throughout the company. The observance of the Do Not Track signal is controlled by means of this parameter in the etracker code:

data-respect-dnt=”true”

However, Do Not Track (DNT) is not directed against web analysis in general, but against the disclosure of website data to third parties. The “World Wide Web Consortium” (W3C) states:

“Tracking is the collection of data about the activities of a particular user in different contexts and the storage, use, or disclosure of data derived from those activities outside the context in which they occurred.” (https://www.w3.org/TR/tracking-dnt/)

Since etracker does not share data with third parties, compliance with DNT with etracker Analytics is thus voluntary and the above parameter is no longer included in the standard etracker code. If the parameter is still included in your etracker code, DNT blocking can be disabled by removing the entire parameter.

Here you can find more information about Do Not Track and etracker Analytics.

4. Tracking code location

The etracker code should be inserted within the HTML source code on all pages – and thus also on check-out pages – between the opening <head> tag and the closing </head> tag. For best data capture rates, we recommend including the tracking code immediately after the opening <head> tag or as close to it as possible.

If the etracker code is not integrated directly into the HTML of the page, but is deployed via a ag manager, this can also have a negative impact on data collection.

Whether the etracker code is integrated at all on the pages of the order process can be checked very easily via the browser console.

Part 2: Deviations due to deficiencies in eCommerce tracking

1. Order completion on external sites

If external payment providers such as PayPal are used, care must first be taken to ensure that purchasers are redirected to a confirmation page after completing the order. In the case of PayPal, auto-return must be activated and the appropriate URL entered. Experience shows that up to 10 percent of orders placed via external payment providers can nevertheless be lost, as some purchasers terminate the process before returning.

If you cannot tolerate this fuzziness, there is the somewhat more complex way of server-side order transfer:

  • The click on the PayPal button is transferred to etracker Analytics as a lead (with a timestamp as the order number). At the same time, this timestamp order number is transferred to PayPal as a custom variable.
  • Using PayPal’s Instant Payment Notification (IPN), the lead is converted into a sale via the Lead to Sale Confirmation interface in etracker.

Using this method, all PayPal transactions are recorded as a “Sale” in etracker Analytics. However, it is only recommended for those who have sufficient expertise to work with webhooks or operate workflow solutions such as Zapier for interface connection.

2. Orders are not transferred correctly

There are four ways to transfer order information to etracker Analytics. This is how you avoid the typical pitfalls:

a) Using eCommerce plug-ins for etracker Analytics

The special extensions for store systems such as Shopware, WooCommerce or Magento make implementation particularly easy. However, they also have their limitations when very individual adjustments are made to the system. Therefore, like other plugins, they can affect tracking. It is definitely advisable to check in case of deviations whether the latest plugin version is used and the setup instructions have been followed correctly.

b) Google Analytics Enhanced Ecommerce Grabber

If the (Enhanced) Ecommerce Tracking of Google Analytics is integrated in the store, the data can be collected by etracker. There are two prerequisites, however,

  • the current tracking code is correctly integrated and the data attribute data-ecommerce-grabber=”true” is added and
  • the integration is done directly via the website and not, for example, via Google Tag Manager.

c) Order parameters in the etracker code

If only transactions are to be recorded and not the complete eCommerce funnel with in-depth assortment analyses, the order parameters in the etracker code can be used. It is important to ensure that at least the three parameters et_tval (revenue or order value), et_tonr (unique order number) and et_tsale (order status 0 for lead and 1 for sale) are set. The order content is optionally passed via the et_basket parameter. The format specifications given in the instructions must be observed.

d) Integration of etracker eCommerce events

The debug mode is used to check the correct integration of eCommerce events. Another is the Last Visitor basic report, which shows in real time whether the events are being transferred correctly. If you trigger the events yourself, make sure that the IP block or the individual opt-out does not prevent the recording.

Attention: Ensure timing!

The eCommerce events may only be transmitted when the etracker code has been fully loaded. For eCommerce events that are fired immediately when the page is called up (such as the transaction being sent to etracker when the order confirmation page is called up), it is therefore essential to use the_etrackerOnReady function to ensure that the etracker code has already been loaded before the eCommerce events are sent.

With these tips, everything should be in place to ensure the best possible eCommerce data quality. Otherwise, we will be happy to help you in our Customer Service.