Tagging
You can implement all sorts of front-end user events with walker.js. From product and UX events like promotion views, filter and search usage 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...
<!-- Generic usage -->
<div
data-elb="ENTITY"
data-elb-ENTITY="KEY:VALUE"
data-elbaction="TRIGGER:ACTION"
data-elbcontext="KEY:VALUE"
data-elbglobals="KEY:VALUE"
/>
<!-- 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
</h1>
<p data-elb-promotion="category:analytics">Analytics</p>
</div>
</div>
</div>
... to get a structured event 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: [], // List of nested entities
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
source: 'X.X.X', // Semantic version of the used source
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: 'https://github.com/elbwalker/walkerOS', // Source of the event's origin
previous_id: 'https://www.elbwalker.com/' // Previous source (like referrer)
}
}
You are entirely free to define naming conventions.
To get started you need to know entity, action & trigger attributes.
Learn more about the event model in our blog.
Entity & action
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.
An action can be added by setting the data-elbaction
attribute on the
same level or child elements in combination with a matching trigger,
e.g., data-elbaction="visible:view"
to fire a promotion view event when an
element has been in the viewport for at least 50% for one second.
To define the entities' properties, set the composited attribute
data-elb-ENTITY
with the key and value, e.g.
data-elb-promotion="name:tagging is fun;position:overlay"
.
Trigger
Walker.js comes with a bunch of pre-built triggers. You don't have to deal with event listener or mutation observer initialization.
Trigger | Definition |
---|---|
load | after loading a page when DOM is ready |
click | when an element or a child is clicked |
visible | after an element has been in the viewport for at least 50% for one second |
hover | each time the mouse enters the corresponding element |
submit | on 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 |
Trigger names are predefined and to be selected from the list, while the
action
can be an arbitrarily defined name.
Abbreviation
If the trigger and action values are equal, e.g. for click events, you can shorten the implementation:
<b data-elbaction="click">
Use the short version, instead of
<s data-elbaction="click:click">long</s>
</b>
Parameters
Some triggers require more information during initialization, while others accept optional parameters. The scroll trigger needs to know the percentage a user scrolls down, a wait trigger 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 one 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.
</div>
</div>
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="" />
</button>
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 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 ;
Data
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>
</div>
</div>
{ data: { source: "parent", key: "value", foo: "bar", } }
Hierarchy
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>
</div>
<b data-elb-e="key:baz"></b>
</div>
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>
</div>
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>
</select>
Arrays
To use array types, add the []
suffix to a property's 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>
</div>
{
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.
<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>
</div>
</div>
Explicit properties are preferred over generic ones.
{
data: {
p: 'v', // parent
k: 'v', // explicit
g: 'v', // generic
o: 'v' // overridden by explicit
},
// ...
}
Globals
There might be properties that don't belong to just one event but to all
events on a page. Those properties are called globals and will be
collected once, right before the first event, got fired. 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.
Context
Context doesn't work like globals for every event, but is helpful information for every framing context an event is embedded in. A context could be a position, a test, or specific components for example.
<div data-elbcontext="test:engagement" data-elbglobals="plan:paid">
<div data-elbcontext="recommendation:smart_ai">
<div
data-elb="promotion"
data-elbaction="click"
data-elb-promotion="title:click me"
>
click me
</div>
</div>
</div>
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
}
At elbwalker we often use context for predefined journeys and stages to measure events along a specific user journey in structured way.
Nested entities
A data-elb
entity within another data-elb
entity is called a nested
entity.
The walker runs through 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="mother"
data-elb-mother="label:caring"
data-elbaction="load:view"
>
<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>
</div>
</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.
Learn more about the walkerOS event model.
If you need professional support with your walkerOS implementation, check out our services.