Data Layers

(m2-data-layers)
30-day money back guarantee

30-day money back guarantee

Data Layer for Magento 2 & Mage-OS gives agencies full control over GTM and GA4 tracking through admin-editable JSON event templates, cache-safe ecommerce events, Consent Mode v2 and server-side transmission to GA4, Meta, TikTok and GTM Server-Side — without requiring a deployment every time the tracking schema changes.
SKU m2-data-layers

Gitlab access is only given to Agencies and Freelancers after
approval process.

Please note: we do not provide installation or implementation services for our extensions.

Installation should be handled by the developer or agency managing your store. This approach ensures:

  • Compatibility with your current setup
  • Proper configuration based on your specific version
  • Implementation by someone familiar with your codebase

Although we don’t offer installation, we maintain a curated list of recommended development agencies experienced with our solutions.

If you'd like to receive this list, please contact us at [email protected].

Partnership Inquiries

Data Layer for Magento 2 & Mage-OS — Change Tracking Without a Deploy | qoliber

Magento 2 & Mage-OS GTM / GA4 Data Layer Extension

Data Layer for Magento 2 & Mage-OS — Change Tracking Without a Deploy

qoliber Data Layer gives Magento agencies, analytics teams and merchants control over GTM and GA4 tracking without hard-coding every event into templates or JavaScript.

Every tracking event is rendered from an admin-editable JSON template. Add a campaign parameter, rename a key, change an ecommerce payload or create a store-specific variation directly from Magento Admin — without waiting for a developer, release window or deployment.

The same event can also be transmitted server-side to supported analytics and advertising destinations, reducing the conversion data lost to browser restrictions while keeping consent, deduplication and attribution logic under control inside Magento.

PHP
8.1 – 8.5
GA4 events
14 built in
Server-side
4 destinations
The template is the product · admin-editable, per store view

Stores → Configuration → qoliber → Data Layer → Templates → purchase

{
  "event": "purchase",
  "event_id": "{{event.id}}",
  "@djson if order.coupon": {
    "coupon": "{{order.coupon}}"
  },
  "ecommerce": {
    "transaction_id": "{{order.id}}",
    "currency": "https://qoliber.com/",
    "value": "{{order.revenue}}",
    "items": {
      "@djson for order.items as item": {
        "item_id": "{{item.sku}}",
        "price": "{{item.price}}",
        "quantity": "{{item.qty}}"
      }
    }
  }
}

↓ renders to

window.dataLayer — and the corresponding server-side event

{
  "event": "purchase",
  "event_id": "ord-000000148",
  "ecommerce": {
    "transaction_id": "000000148",
    "currency": "EUR",
    "value": 249.00,
    "items": [
      {
        "item_id": "MS-04-XL",
        "price": 83.00,
        "quantity": 3
      }
    ]
  }
}

The important field is event_id. Purchase identifiers are deterministic rather than randomly generated, allowing platforms that support browser/server deduplication to recognise both transmissions as the same conversion.

Why Data Layer

Give Marketing Teams Flexibility Without Giving Up Technical Control

Tracking changes should not automatically become development projects. Data Layer separates the event structure from the storefront implementation, helping agencies reduce small analytics tickets while keeping the tracking architecture predictable and auditable.

Fewer Tracking Deployments

Change event payloads in Magento Admin instead of opening development tickets for every new marketing parameter or analytics requirement.

Recover More Conversion Signals

Server-side transmission gives supported destinations another path for events that browser-only tracking may fail to deliver.

Keep FPC Intact

Shopper-specific events use Magento private customer-data rather than being embedded inside shared cached HTML.

Debug With Evidence

Validate payloads, inspect dispatched events and see responses instead of treating the analytics platform as a black box.

Magento tracking in production

Where Magento GTM & GA4 Tracking Usually Goes Wrong

Pushing a standard ecommerce event is easy. The difficult part is maintaining correct tracking behind Magento full-page cache, handling changing marketing requirements, respecting consent and knowing whether the event actually arrived.

01

A Campaign Needs One More Field

Without it: ticket → developer → release window.

Events are editable templates in Magento Admin, with separate configuration per event and store view. Change the JSON structure and save — no phtml edit or deployment required.

02

Full-Page Cache

Without the right architecture: shopper-specific data can end up in shared output.

Cart, wishlist and login events travel through Magento's private customer-data section, keeping them shopper-specific and outside cached HTML.

03

The Browser Never Sends It

Without it: a conversion can simply disappear from the destination.

Supported events can also be queued and transmitted server-to-server from Magento, providing a second delivery route that does not depend on the browser pixel.

04

One Order Counted Twice

Without deduplication: reported revenue becomes unreliable.

Purchase events use a deterministic identifier derived from the order. Supported advertising platforms can therefore recognise corresponding browser and server events as the same conversion.

05

Consent Is Withdrawn

Stopping future capture is not always enough.

Consent is checked on subsequent page views, and captured advertising identifiers are removed after relevant consent is withdrawn rather than simply remaining until their normal expiry.

06

GA4 Quietly Rejects the Payload

An HTTP success response does not necessarily mean valid analytics data.

The GA4 validation CLI sends a real rendered payload to Google's validation endpoint and returns the platform validation messages to the developer.

The event list is not the difficult part. The engineering value is in making tracking cache-safe, configurable, observable, consent-aware and recoverable when production conditions are less predictable than a demo store.

Magento GTM extension comparison

qoliber Data Layer vs Typical Magento GTM / GA4 Extensions

Most established Magento analytics extensions cover the standard GA4 ecommerce events. The bigger differences appear when you need to modify the schema, maintain tracking behind full-page cache or move part of the data flow server-side.

qoliber Data Layer compared with typical Magento 2 GTM and GA4 extensions
Capability qoliber Competing modules
Changing event structureAdmin-editable JSON templates
per event, per store view		Commonly code or configuration-driven
Shopper events behind FPCMagento private customer-data
shopper-specific, outside cached HTML		Implementation varies
Browser tracking blockedFour server-side destinations
GA4 MP, Meta CAPI, TikTok and GTM Server-Side		Often browser-side; server support varies
Browser/server deduplicationDeterministic event ID
same conversion identifier where supported		Not commonly documented
Consent Mode v2Denied by default
same consent state gates server-side transmission		Implementation varies
Paid-click attribution on cached pagesBrowser capture, first touch wins
identifiers persisted onto order		Not commonly documented
Consent withdrawalStored identifiers removedVaries
Payload validationCLI validation + dispatch logOften not publicly documented
Destination outageQueue-backed dispatch with retries
checkout does not wait on analytics destinations		Architecture varies
Published automated testing699 unit · 54 integration · 53 E2EUsually not published

“Typical Magento GTM Extension” is a general description of commonly published capabilities in Magento GTM and GA4 products reviewed in August 2026. Capabilities differ between vendors. “Not commonly documented” does not mean that no competing implementation provides the capability.

Already running another Magento GTM extension?

You can keep your existing GTM container. Data Layer ships with standard GA4 event structures and lets your team reshape individual payloads from Magento Admin to match the tags and triggers already implemented in your container.

Advanced tracking infrastructure

The Capabilities That Matter Once Advertising Data Has Business Value

Once analytics affects budget allocation, bidding and revenue reporting, tracking reliability becomes infrastructure rather than a frontend convenience.

1 · Server-Side Tracking

Supported events can be transmitted directly from Magento to GA4 Measurement Protocol, Meta Conversions API, TikTok Events API and a GTM server-side container.

Transmission runs through a message queue. An unavailable advertising platform therefore does not block checkout, and failed attempts can be retried and inspected.

2 · Deterministic Event IDs

Purchase events use an identifier derived from the order rather than a random value. This provides a stable key for platforms such as Meta and TikTok to match browser and server events representing the same conversion.

Important: GA4 Measurement Protocol does not automatically deduplicate an event against an equivalent gtag browser event. The GA4 server-side destination should therefore be used intentionally rather than as an automatic duplicate of existing browser tracking.

3 · Consent Mode v2

Consent Mode v2 defaults are set to denied before the container loads. The resulting state also controls applicable server-side transmission instead of protecting only the browser channel.

The implementation can work with a CMP as well as Magento's native cookie restriction mechanism, giving agencies more flexibility across existing project setups.

4 · First-Touch Attribution

Advertising click identifiers including gclid, gbraid, wbraid, fbclid, msclkid and ttclid, together with UTM parameters, are captured in the browser.

First touch wins, and attribution data is copied onto the order when it is placed. This allows campaign information to survive Magento full-page cache and remain available after checkout.

See It Live

Enable a storefront debugging panel on staging to inspect each dataLayer push and the exact JSON received by your GTM container.

Validate From CLI

Test destination credentials, validate real GA4 payloads and render templates directly from the command line.

Explain It Afterwards

The dispatch log records destination, status, response and skip reason for server-side attempts with configurable retention.

Technical specifications

Built for Modern Magento Analytics Projects

Platform

Magento Open Source and Adobe Commerce 2.4.7+, plus Mage-OS.

PHP

8.1 – 8.5, tested across the supported range.

Templates

DJson templates: editable JSON structures owned by your project.

Destinations

GA4 Measurement Protocol, Meta CAPI, TikTok Events API and GTM Server-Side.

In the box

  • 14 GA4 events pre-loaded as editable templates
  • Admin template grid and JSON editor with preview
  • Per-store-view templates, individually configurable
  • Full-page-cache-safe customer event delivery
  • Browser-side deduplication ledger
  • Queue-backed server-side transmission with retries
  • Dispatch log with configurable retention
  • Google Consent Mode v2
  • First-touch click-ID and UTM attribution
  • Attribution persisted onto Magento orders
  • Storefront debug panel
  • CLI testing, validation and template rendering
  • REST API for template configuration
  • CSP whitelist included
Engineering quality

Tracking You Can Test Instead of Trusting Blindly

699
unit tests
54
Magento integration tests
53
end-to-end browser journeys
L8
PHPStan

The automated suite covers PHP 8.1–8.5 and includes tests that drive an actual storefront and verify what reaches window.dataLayer, alongside Magento coding standards and PHPMD checks.

Magento Data Layer FAQ

Questions

Do I need a developer to change a Magento data layer event?

No. Each event is an editable JSON template in Magento Admin, configurable per store view and previewable before saving. Adding fields or changing payload structure does not require a storefront deployment.

Does Data Layer support Google Tag Manager and GA4?

Yes. The extension ships with 14 preconfigured GA4 ecommerce events and pushes rendered payloads to the Magento storefront data layer for GTM usage. Server-side destinations include GA4 Measurement Protocol as well as supported advertising APIs.

Will server-side tracking double-count conversions?

Meta and TikTok can use the deterministic event identifier shared by corresponding browser and server purchase events for deduplication. GA4 Measurement Protocol does not automatically deduplicate against gtag, so the GA4 server-side destination should be configured intentionally rather than used as an automatic duplicate.

Does it work with Magento full-page cache and Varnish?

Yes. Page-level events can remain cacheable, while shopper-specific events such as cart, wishlist and login are delivered using Magento private customer-data rather than shared cached HTML.

Does it support Google Consent Mode v2?

Yes. Consent defaults are denied before the container loads, and applicable consent state is also used to gate server-side transmission. The extension can read consent from a CMP and Magento's native cookie notice.

Can I verify that a GA4 payload is valid?

Yes. The GA4 validation command submits the rendered payload to Google's validation endpoint and returns the validation messages, while the dispatch log records server-side transmission attempts.

What happens if an advertising or analytics destination is unavailable?

Server-side transmissions run through a message queue, so the storefront and checkout do not wait for the external destination. Failed attempts can be retried and remain visible in the dispatch log.

Is the extension tested?

Yes. The supplied engineering figures include 699 unit tests, 54 Magento integration tests and 53 end-to-end browser journeys, together with PHPStan level 8, Magento coding standards and PHPMD checks.

Data Layer for Magento 2 & Mage-OS — Change Tracking Without a Deploy