Skip to main content


You can implement all sorts of front-end user events easily with walker.js. From product and UX events like promotion view, filter usage, etc. to e-commerce actions like product add to carts or order complete events. The walker.js handles all trigger initializations and race conditions, builds the events with context, and distributes them based on consent states and mapping definitions to any destinations.

Tag a page with...

<!-- Generic usage -->

<!-- Example usage -->
<div data-elbglobals="language:en">
<div data-elbcontext="test:engagement">
<div data-elb="promotion" data-elbaction="visible:view">
<h1 data-elb-promotion="name:Setting up tracking easily">
Setting up tracking easily
<p data-elb-promotion="category:analytics">Analytics</p>

... to get a full event like the following as a result:

event: 'promotion view', // Name as a combination of entity and action
data: {
// Arbitrary properties related to the entity
name: 'Setting up tracking easily',
category: 'analytics',
context: {
// Provides additional information about the state during the event
test: ['engagement', 0] // Key, [value, order]
globals: {
// General properties that apply to every event
language: 'en'
custom: {}, // Additional space for individual setups
user: {
// Contains user identifiers for different identification levels
// Require consent and set manually for sessions building and cross-device
id: 'us3r1d',
device: 'c00k131d',
session: 's3ss10n1d',
nested: [],
consent: { functional: true }, // Status of the granted consent state(s)
id: '1647261462000-01b5e2-5', // Timestamp, group & count of the event
trigger: 'visible', // Name of the trigger that fired
entity: 'promotion', // The entity name involved in the event
action: 'view', // The specific action performed on the entity
timestamp: 1647261462000, // Time when the event fired
timing: 3.14, // Duration how long it took to trigger this event
group: '01b5e2', // Random identifier for all events during a run
count: 2, // Incremental counter of the events in the same run
version: {
// Information about the used implementation setup
client: 'X.X.X', // Semantic version of the used client
tagging: 42, // A version number of the then-used tagging status
source: {
// Details about the origin of the event
type: 'web', // Source type of the event (also app, server, or custom one)
id: '', // Source of the event's origin
previous_id: '' // Previous source (like referrer)

Learn more about the event model.

You are entirely free to define naming conventions. All you need to get started are the entity, action & trigger attributes. Learn more about the event model in our blog.

  1. You define the entity scope by setting the data-elb attribute with the name of an entity to an element, e.g., data-elb="promotion". The default entity is page when no data-elb is set.
  2. An action can be added by setting the data-elbaction attribute on the same level or all child elements in combination with a matching trigger, e.g., data-elbaction="visible:view" to fire a promotion view event when the element has been in the viewport for at least 50% for one second.
  3. (Optional) To define the entities' properties, set the composited attribute data-elb-ENTITY with the name and value, e.g. data-elb-promotion="name:Setting up tracking easily;position:overlay".


Walker.js comes with a bunch of pre-built triggers. You don't have to deal with event listener or mutation observer initialization anymore.

loadafter loading a page when the DOM is ready
clickwhen the element or a child is clicked
visibleafter the element has been in the viewport for at least 50% for one second
hovereach time the mouse enters the corresponding element
submiton a valid form submission
wait(ms)waits ms seconds (15 seconds by default) until triggering
pulse(ms)recurring trigger every ms seconds (15 seconds by default) if the page is not hidden
scroll(y)fires when min. y percent of the element's height is above the bottom of the window, e.g., scroll(80) for an 80% threshold

Trigger names are predefined and need to be selected from the list, while the action can be an arbitrarily defined name.


If the trigger and action values are equal, e.g., for click events, you can just shorten the implementation:

<b data-elbaction="click">
is equal to <s data-elbaction="click:click">long</s>


Some triggers require more information during initialization, while others accept optional parameters. A scroll trigger needs to know the percentage a user scrolls down while a wait trigger wants to know the number of milliseconds until the action gets triggered. Use brackets behind the trigger to pass that information.

<!-- specifying trigger parameters -->
<p data-elbaction="wait(10):interested"></p>
<p data-elbaction="pulse(10):interested"></p>

Action filter

At some point, you might want to nest an entity inside another. To prevent an action to trigger both entities, you can restrict the action to a specific entity by adding the name, e.g. data-elbaction="load:view(product)". If the trigger event gets called, the result will only include the property values from the specific entities.

<!-- setting a filter for an entity -->
<div data-elb="foo">
<div data-elb="bar" data-elbaction="load:hello(bar)">
only the bar hello event fires.

Up-bubbling click trigger

By clicking an element, the event bubbles up to the body element. If the walker finds a data-elbaction with the click trigger, it will fire the action. Often, the image or a whole div-block gets clicked, not the parent a-element. Using the bubbling-up flow, the walker still triggers the actions for you.

<button data-elb="product" data-elbaction="click">
<img class="full" src="some.jpg" alt="" />

The click trigger uses the bubbling-up process. It will not work with stopPropagation or preventDefault.

Linking elements

Use the data-elblink tag to extend the scope of an entity by other elements placed somewhere else (like modals). Specific IDs connect linked elements. They are hierarchically and can either be a parent or a child.

<div data-elb="info" data-elblink="details:parent">...</div>
<div data-elblink="details:child" data-elbaction="visible">...</div>
<p data-elblink="another:child">...</p>

The second element is the parent, triggering the visible action for the info visible event. There can be multiple children, but there is only one parent element per ID.


data-elb, data-elbaction, data-elbcontext, data-elbglobals, and data-elblink are reserved attributes, whereas data-elb-* attributes may be arbitrary combinations based on the related entity name. Actions and properties can be set anywhere inside an elb scope.


Spaces in entities, e.g., "shopping cart" or actions, e.g., "add to cart" will be replaced by underscores to "shopping_cart" and "add_to_cart".


Spaces in property values are no problem, e.g. "category: 'summer sale'" works fine. But it is better to set them in quotes when doing so or when using symbols, especially : or ;


Basic attributes

To specify data, use the name of the entity. The data attributes have to be inside of the entity scope or a parent.

<div data-elb-entity="source:parent">
<div data-elb="entity">
<p data-elb-entity="key:value">...</p>
<p data-elb-entity="foo:bar">...</p>
{ data: { source: "parent", key: "value", foo: "bar", } }


There is a hierarchy for the data properties, where the order defines which values to use for similar keys. Based on the triggering action element, the closest ones or parent values will be preferred over the others.

<div id="family" data-elb="e" data-elbaction="click">
<div id="parent" data-elb-e="key:foo" data-elbaction="click">
<p id="child" data-elb-e="key:bar" data-elbaction="click"></p>
<b id="sibling" data-elbaction="click"></b>
<b data-elb-e="key:baz"></b>

Based on which element gets clicked, the event will contain the following data

  • family: { key: 'baz' }, the last found data-property
  • parent: { key: 'foo' }, a direct data-value
  • child: { key: 'bar' }, direct value closer than the parent
  • sibling: { key: 'foo' }, no value specified, so it takes the parent's value

Type casting

Property values will be cast to their type, supporting string, number & boolean.

<div data-elb="types">
<p data-elb-types="string:text">{ string: "text" }</p>
<p data-elb-types="int:42;float:3.14">{ int: 42, float: 3.14 }</p>
<p data-elb-types="bool:true">{ bool: true }</p>

Multiple attributes

Browsers override duplicate attributes. Hence an element can only have one data-elb, data-elb-ENTITY, and/or data-elbaction attribute at a time. Nevertheless, it’s possible to define multiple entities, properties, and/or actions within one attribute using quotes and semicolons. A semicolon splits key-value pairs. Therefore, it’s necessary to escape values that contain a semicolon. Quotes are here to meet your needs. To prevent a mistaken value-split, use single quotes.

<!-- value wrapping with quotes -->
<p data-elb="foo" data-elb-foo="b:a;r">{ "b": "a", "r": true }</p>
<p data-elb="foo" data-elb-foo="b:'a;r'">{ "b": "a;r" }</p>

If a single quote is part of the value, escape it with a backslash:

<!-- escaping values with backslash -->
<p data-elb="foo" data-elb-foo="bar:it\'s escaped">{ "bar": "it's escaped" }</p>

The semicolon can be used as a separator to list multiple values inside of a data-elb or data-elbaction attribute.

<!-- using multiple key-value pairs at once -->
<p data-elb="foo" data-elb-foo="a:1;b:2">{ "a": 1, "b": 2 }</p>

Dynamic field values

You might want to measure dynamic field values, e.g. the quantity of a product or the value of the selected element. Use a # at the beginning, followed by the attribute name to access the value of the element attribute.

<!-- Basic usage: elb-ENTITY="KEY:#VALUE" -->
<input type="text" value="blue" data-elb-product="color:#value"></input>
<div data-elb-product="name:#innerHTML">Everyday Ruck Snack</div>

To capture a selected option from a list, use elb-ENTITY="KEY:#selected" to get size:20L

<select data-elb-product="size:#selected">
<option value="18L">18L</option>
<option value="20L" selected="selected">20L</option>


To use array types, add the [] suffix to a properties name, such as size[]:m. The walker.js will generate de-duplicated data properties.

<div data-elb="product">
<p data-elb-product="size[]:s;size[]:l"></p>
<p data-elb-product="size[]:l"></p>
data: {
size: ["s", "l"],
// ...

Generic properties

Leave the entity name empty (only data-elb-) to add the property to any related entity. Explicitly named properties are preferred over generic ones. It's suggested that explicit properties be preferred over generic ones.

<div data-elb-="p:v">
<div data-elb="generic">
<p data-elb-generic="k:v"></p>
<p data-elb-="g:v"></p>
<p data-elb-generic="o:v"></p>
<p data-elb-="o:x"></p>
data: {
p: 'v', // parent
k: 'v', // explicit
g: 'v', // generic
o: 'v' // overridden by explicit
// ...


There might be properties that don't belong to just one event but to all events on a page. Those properties are called the globals and will be collected once, right before the first event, got fired. The globals are arbitrary, like the data property. What is unique about them is that you can define them anywhere on a page using the data-elbglobals attribute.

<div data-elbglobals="outof:scope"></div>

<div data-elb="entity" data-elb-entity="foo:bar" data-elbaction="load:action" />

This example will lead to the following event:

"event": "entity action",
"data": { "foo": "bar" },
"globals": { "outof": "scope" }
// other properties omitted

For performance reasons, the globals are only collected once per run.


All entities inside a defined context want to know about their context. Those are not as relevant as globals for every event, but helpful information for every framing context of an event it is embedded in. A context could be a position or test, for example.

<div data-elbcontext="test:engagement" data-elbglobals="plan:paid">
<div data-elbcontext="recommendation:smart_ai">
data-elb-promotion="title:click me"
click me

The context properties are tuples with the value and an index, starting at the closest parent ([value, index]). Access them via event.context.key[0].

event: "promotion click",
data: { title: "click me" },
globals: { plan: "paid" },
context: {
test: ["engagement", 1],
recommendation: ["smart_ai", 0],
// other properties omitted

Nested entities

A data-elb entity within another data-elb entity is called a nested entity.

The walker runs through the nested entities and treats them like regular entities by gathering all related information. Nested entities are accessible in the nested array of each event. Each element is a regular entity.

<div data-elb="son" data-elb-son="age:23"></div>
<div data-elb="daughter" data-elb-daughter="age:32">
<div data-elb="baby" data-elb-baby="status:infant"></div>

This example will lead to the following event on load:

"event": "mother view",
"data": { "label": "caring" },
"nested": [
{ "type": "son", "data": { "age": 23 } },
"type": "daughter",
"data": { "age": 32 },
"nested": [{ "type": "baby", "data": { "status": "infant" } }],
{ "type": "baby", "data": { "status": "infant" } },
// other properties omitted

Nested entities that are nested inside another entity will be captured on both levels.


Nested entities are not available for auto-captured page view events.