Install with Google Tag Manager

If your shop already runs Google Tag Manager and already pushes a GA4 ecommerce dataLayer, you can go live with AxiTrace without touching a single line of shop code. One Custom HTML tag loads the AxiTrace loader, one switch in Workspace settings tells it to read your dataLayer, and your existing view_item, add_to_cart, begin_checkout and purchase pushes become AxiTrace events automatically. The full reference for reading the dataLayer is GA4 dataLayer Auto-Tracking.

Who this page is for

You run a custom shop, a headless storefront, or any site that has no AxiTrace plugin. Your two documented options so far were to hand-write JavaScript (JavaScript SDK) or to send events from your own backend (HTTP API). This page is the third option: install through Google Tag Manager, which is what most shops in this position already have.

If you run WooCommerce, Shopify, Magento, Shopware or BigCommerce, do not use this page. Install the plugin for your platform instead: it captures the order server-side, which is strictly better than anything a browser can do. See the platform integration guides.

The one prerequisite: a GA4 ecommerce dataLayer

Everything on this page depends on a single question: does your site already push GA4 ecommerce events, or the classic Google Analytics ecommerce transaction, into a dataLayer? If it does, the install below takes about ten minutes. If it does not, someone still has to write those pushes into your shop's templates, and Google Tag Manager does not remove that work, it moves it. Be clear about which of the two situations you are in before you start.

Check your own dataLayer in 30 seconds

Open a product page on your site, open the browser devtools console, and paste this. The first part prints what the page has pushed already; the second part prints every new push live, so you can click Add to cart and watch what happens. Then do the same on the order confirmation page after a test order: on many shops that is the only page where the order data appears.

// 1. What this page has already pushed.
(function () {
  var dl = window.dataLayer;
  if (!Array.isArray(dl)) {
    console.warn('No dataLayer array on this page. Nothing to map.');
    return;
  }
  console.log('dataLayer entries:', dl.length);
  dl.forEach(function (entry, i) {
    if (entry && entry.transactionId) {
      console.log(i, 'classic ecommerce transaction', entry);
    } else if (entry && entry.event) {
      console.log(i, entry.event, entry.ecommerce || '(no ecommerce object)');
    }
  });
})();

// 2. Print every future push. Now click "Add to cart" and watch the console.
(function () {
  var dl = window.dataLayer;
  if (!Array.isArray(dl)) { return; }
  var originalPush = dl.push;
  dl.push = function () {
    try { console.log('PUSH', arguments[0]); } catch (e) {}
    return originalPush.apply(dl, arguments);
  };
  console.log('Watching dataLayer pushes. Reload the page to stop.');
})();

Reading the result

In your web Google Tag Manager container, go to Tags → New, choose Custom HTML, and paste the snippet below. Replace axi.yourdomain.com with your own tracking domain and pk_live_... with your workspace Public Key (both are shown in the AxiTrace admin panel).

<script src="https://axi.yourdomain.com/axitrack.js"></script>
<script>
  Axitrace.init({
    publicKey: 'pk_live_...',
    apiUrl: 'https://axi.yourdomain.com'
  });
</script>

The options, and what the Workspace setting does instead

The JavaScript SDK page documents many more initialization options (consent gating, cookie domain, session length, pixel bridging). They all work here too. The two required above are the only ones this install method needs.

Switch on dataLayer auto-tracking

In the AxiTrace admin panel, open Workspace settings, the Data collection section, and turn on GA4 dataLayer auto-tracking. You may find it already on: the AI shop check on the Manual connection page looks for a GA4 ecommerce dataLayer on your shop and sets this switch for you. The SDK picks the setting up by itself, so the tag above never has to change. See the Workspace setting for the details.

Give the tag the built-in Initialization - All Pages trigger, not All Pages. Initialization triggers fire before every other tag on the page, which is what you want for a loader: the SDK has to be listening before your shop pushes view_item, or the first event of the page is the one you lose.

Leave Tag firing options at Once per page and leave Support document.write unchecked. Name the tag something like AxiTrace Loader and save.

Submit the container. If your Meta Pixel and TikTok Pixel are also managed by this GTM container, give them the same Initialization - All Pages trigger so they are present as early as possible. AxiTrace calls fbq() and ttq() with its own event ID so the browser and server copies of each event deduplicate, and since SDK 0.7.6 those calls are queued and replayed for up to 30 seconds if the pixel is not loaded yet. This pairing on a shared event ID is done by Meta, TikTok, Pinterest and Microsoft Ads. GA4 does not deduplicate at all: if your own GA4 tag already sends these events, keep Forward browser-bridged dataLayer events off on your AxiTrace GA4 connection, or GA4 counts them twice. A pixel that arrives late is still bridged - loading it early just makes the browser event fire sooner.

Install your Meta and TikTok pixels init-only: no fbq('track', 'PageView') and no ttq.page(). AxiTrace fires those itself, with the shared event ID that makes deduplication work. Leaving the manual calls in place double-counts every page view. See Pixel Deduplication.

What gets mapped, and what does not

With dataLayer auto-tracking on, these GA4 event names become AxiTrace events. Nothing else on the page has to change: the SDK reads the ecommerce object of each push and fills in the AxiTrace event properties from it.

purchase is AxiTrace's accepted alias for transaction.charge, which is the name you will see in the Events Reference and in your error log. They are the same event.

view_item_list, select_item, remove_from_cart and add_shipping_info were added to this list on 19 September 2026. Before that they were ignored, which meant a shop with a complete GA4 ecommerce dataLayer got seven of the eleven events it was already publishing. If you built a workaround for that - a backend call, or a custom event - you can remove it: keep only one source per event, or the same action is counted twice.

Not covered yet

These GA4 events are not mapped. They are ignored, silently and harmlessly - no error, no partial event:

• view_cart
• refund

Do not try to send these from a GTM tag by hand. The browser endpoint has no handler for them, so the call is answered 400 unsupported event and the attempt is recorded in your workspace's error log. Unlike the four above, these two have no server-side endpoint either, so there is nothing a backend integration can do about them yet.

Path 2: no dataLayer, fire events from GTM tags

If the check above found no ecommerce data, you can still build events inside GTM out of triggers and variables. Keep the loader tag from Path 1 without autoTrackDataLayer, keep GA4 dataLayer auto-tracking off in Workspace settings (the shop check leaves it off when it finds no GA4 ecommerce dataLayer), and add one Custom HTML tag per event. Never combine the two: events sent by hand and the same events read from the dataLayer are counted twice.

Under Variables → User-Defined Variables, create one DOM Element variable per value you need. For an add-to-cart event that is typically the SKU, the name and the price:

Prefer a data- attribute over element text wherever your templates offer one. An attribute holds a clean machine value (49.99); element text holds whatever the page displays ($49.99, or 49,99 EUR), and you would have to clean it up in JavaScript before sending it.

Under Triggers → New, choose Click - All Elements, set it to fire on Some Clicks, and add the condition Click Classes contains add-to-cart (substitute whatever class or ID your own button carries). Name it Click - Add to Cart.

Add a Custom HTML tag with the snippet below and give it the trigger from Sub-step 2. The double-brace names are GTM variable references: GTM substitutes the value at fire time.

<script>
  (function () {
    // The loader tag fires on Initialization, so the SDK is normally ready by
    // the time a visitor clicks. Guard anyway: a click in the first few hundred
    // milliseconds of a slow page should be skipped, not throw.
    if (!window.Axitrace || !window.Axitrace._instance) { return; }

    var price = parseFloat(String({{DOM - Product Price}}).replace(',', '.'));

    window.Axitrace._instance.track('product.addToCart', {
      content_id: {{DOM - Product SKU}},
      content_name: {{DOM - Product Name}},
      content_type: 'product',
      sku: {{DOM - Product SKU}},
      name: {{DOM - Product Name}},
      price: price,
      quantity: 1,
      currency: 'EUR',
      value: price
    });
  })();
</script>

Repeat the pattern for the other events you need, using the names from the mapping table and the property shapes documented under E-commerce Tracking and in the Events Reference. Hard-code the currency only if your shop sells in one; otherwise it needs its own variable.

What you still do not get from a browser-only install

This is worth reading before you decide the install is finished. A GTM install is a browser install, and a browser install has three limits that no amount of GTM configuration removes.

1. The purchase exists only if the browser reaches the confirmation page

A purchase event is a tag firing on a page. If that page never loads, the event never happens and the order is simply absent from AxiTrace and from every ad platform you forward to. That covers more real orders than most people expect:

• the payment gateway takes the buyer to its own domain and the return redirect fails, times out, or lands on an error page;
• the buyer closes the tab on the bank's 3-D Secure screen after the money has already moved;
• the order is placed by phone, by email, in a physical shop, or entered by your staff in the back office;
• the buyer's connection drops between the payment confirmation and your thank-you page.

Each of those is a paid conversion your ad platforms will never learn about, and they optimise on what they learn about.

2. Match keys are only as good as what the page exposes

Meta and TikTok score every conversion on how many buyer identifiers arrive with it: email, phone, first name, last name, city, postcode and country. That score is Event Match Quality, and it directly affects how well their algorithms can attribute and optimise. A typical GA4 purchase push carries the order value, the currency, the transaction id and the items - and nothing at all about the buyer, because GA4 never needed it.

What the page does not print, the browser cannot send. Your Event Match Quality is capped at exactly what your confirmation page happens to expose, which is usually far below what your order record already contains.

You can raise that cap by adding GA4 user_data to your pushes: plain-text email, phone_number and an address with first name, last name, city, region, postcode and country. AxiTrace reads it and hashes it itself before sending. Already hashed values and sha256_* keys cannot be used. See customer details from user_data.

3. There is no retry

The browser gets one attempt. If the request is blocked by an extension, cut off by a closing tab, or lost to a dropped connection, that conversion is gone and nothing notices. A server that owns the order can retry until the event is accepted, and AxiTrace's server-side path does exactly that.

Verify the install

Click Preview in GTM and browse your own shop: a product page, an add to cart, and a test order if you can place one. In the Tag Assistant panel, confirm that your AxiTrace Loader tag appears under Tags Fired on the very first Initialization event of every page, and that it fires once, not repeatedly.

With devtools open, filter network requests by your tracking domain. You should see axitrack.js load once, then one request per event. Each should return 200.

Open your workspace and check, in this order:

• The dashboard. Page views appear within seconds. Conversion events (product.addToCart, begin_checkout, transaction.charge) are held in the queue for 10 seconds on purpose, so the visitor's profile can pick up fbp and fbc first. Wait 15 seconds before deciding an event is missing.
• Event feed → Errors. This is where a rejected event explains itself. A validation failure, a wrong public key, an origin that is not allowed - each one is recorded here with a reason. An empty Errors tab and an empty Overview together mean the request never arrived at all.
• The Orders list (Orders & journeys). A test order should appear with the right amount, currency and transaction id. This is also where you see whether your purchase push carried the buyer details, or only the order total.

Troubleshooting

A note on server-side GTM

Nothing on this page needs server-side GTM. Your AxiTrace tracking domain is already a first-party, server-side endpoint: events from the browser go to your own domain and are forwarded to Meta, TikTok, Google Ads and GA4 from AxiTrace's servers, not from the visitor's browser. That is the benefit people usually buy sGTM for, and you have it the moment the loader above is live.

Separately, AxiTrace can host a managed Google server-side GTM container for you on Business and Custom plans, on that same domain, with no Cloud Run bill of your own. It is useful if you want your Google tags to run server-side too, or want one place to inspect and reshape outbound tag traffic. It is not a prerequisite for anything here, and it does not improve AxiTrace's own tracking. See Server-Side GTM Hosting if that is what you are after.

Need Help?

If you have any questions or need assistance:

• Email us at info@axitrace.com - we typically reply within one business day.
• See the JavaScript SDK reference for every option the loader accepts.
• See the HTTP API reference to add the server-side purchase described above.