> Part of the walkerOS documentation. Project overview and full index: <https://www.walkeros.io/llms.txt>

# walkerOS tagging vs. dataLayer.push

Google's `dataLayer` has been the standard way to push data to Google Tag Manager, but every event needs manual work.

## Quick comparison[​](#quick-comparison "Direct link to Quick comparison")

| Feature                | dataLayer.push          | walkerOS tagging                                                                     |
| ---------------------- | ----------------------- | ------------------------------------------------------------------------------------ |
| Tagging approach       | Manual JavaScript calls | HTML attributes (data-elb)                                                           |
| Event state management | Manual updates required | Automatic, real-time                                                                 |
| Consent handling       | Manual setup in GTM     | Consent Mode in GTM with walker.js, consent rules per destination in your own bundle |
| Version control        | Hard to track changes   | In your codebase                                                                     |
| Component reusability  | Copy-paste code         | Tag once, use everywhere                                                             |
| Metadata enrichment    | Manual                  | Automatic (timing, trigger, page URL)                                                |

## Who should use what?[​](#who-should-use-what "Direct link to Who should use what?")

### Keep using dataLayer.push if[​](#keep-using-datalayerpush-if "Direct link to Keep using dataLayer.push if")

* Your tracking is minimal and rarely changes
* Your team prefers JavaScript over HTML attributes

### Switch to walkerOS tagging if[​](#switch-to-walkeros-tagging-if "Direct link to Switch to walkerOS tagging if")

* You want to keep GTM without writing pushes by hand
* You want tracking integrated into your components
* You're tired of manual event management
* You want consent rules applied before events leave the page (your own bundle)
* You want version-controlled, reviewable tracking
* You're building with modern component frameworks

## Key differences[​](#key-differences "Direct link to Key differences")

### How tagging works[​](#how-tagging-works "Direct link to How tagging works")

**dataLayer.push:** You write JavaScript to collect values, build the event object, and push it at the right time. Every event needs its own code.

```
dataLayer.push({

  event: 'add_to_cart',

  ecommerce: {

    items: [

      { item_id: 'sku123', item_name: 'Cool Hat', price: 29.99, quantity: 1 },

    ],

  },

});
```

You gather all values yourself and make sure the push happens after DOM ready and after consent is granted.

**walkerOS tagging:** You add HTML attributes to your components. walkerOS reads the DOM, detects interactions, and pushes events automatically.

PreviewHTMLCSSJS

GlobalsContextEntityPropertyAction

Events

Loading...

Click the preview to see its events.

Mapping

Loading...

Result

Loading...

Each event's gtag call appears here.

You tag the button once, and walkerOS listens for clicks and collects data from the attributes. [walker.js](/preview/pr-749/docs/getting-started/quickstart/walkerjs.md) pushes the result to the `dataLayer` for your GTM tags; your own bundle sends it to any destination, with consent rules per destination.

### Component integration[​](#component-integration "Direct link to Component integration")

**dataLayer.push:** Tracking is often hard-coded separately from components, or managed entirely in GTM. New features frequently launch without tracking because nobody thought of it until later.

**walkerOS tagging:** Tracking lives in your HTML alongside your components. When you build a component, you tag it once, and the same tracking works on every page and in every context where that component appears.

### Maintenance[​](#maintenance "Direct link to Maintenance")

**dataLayer.push:** Every event needs individual updates. A changed product schema means updating every push call, and a new field means touching every file.

**walkerOS tagging:** Global attributes apply everywhere automatically, and because tagging happens at the component level, one change updates all instances. walkerOS also adds event metadata such as timing and the trigger on its own.

## Can they work together?[​](#can-they-work-together "Direct link to Can they work together?")

Yes. Keeping GTM no longer means hand-written pushes: [walker.js](/preview/pr-749/docs/getting-started/quickstart/walkerjs.md) is one script tag that turns `data-elb` attributes into dataLayer pushes for your existing GTM tags, with a complete [GTM setup](/preview/pr-749/docs/getting-started/quickstart/walkerjs.md#use-it-in-gtm). For pushes shaped by a flow you build yourself, use the [GTM destination](/preview/pr-749/docs/destinations/web/gtag/gtm.md).

## Getting started[​](#getting-started "Direct link to Getting started")

The [tagging guide](/preview/pr-749/docs/sources/web/browser/tagging/html-attributes.md) shows how HTML attributes replace manual push calls.