elbwalker docs
Search…
What is walker.js?
Walker.js is a library to capture events on a website/web app and send them to your favorite analytics tools. It was created to simplify and standardize tracking instrumentation.

Introducing walker.js

Walker.js is an open, vendor-agnostic library for robust event tracking instrumentation on websites and web apps. Think of it as an implementation layer that creates reliable event data with context.
Walker.js is different from Tag Managers like Google Tag Manager in that your tracking implementation is configured as code based on attributes.
It doesn't have a UI and it's not made to work completely without code.
On the flip side, it adds maximum flexibility and reliability to your tracking implementation. It lets you trigger certain events directly through your markup, and add destinations flexibly.
If you're looking for a solution that works completely without touching any code, or that works straight out of the box like a simple plugin, walker.js might not be the right solution for you. But if you
  • regularly ship new features and A/B tests and constantly need to make sure you added the tracking correctly,
  • or have a complex UI and want to measure in-depth behavioral data like the visibility of certain elements, or hovering over them,
  • or if you're simply a developer who's not too familiar with the MarTech world,
walker.js might be just what you're looking for.

Attribute-based

Writing manual code, that pushes tracking information into the dataLayer can be drowning especially if you're not familiar with the topic, but rather a core product developer.
The communication between marketing, product, and engineering teams can be exhausting. So the goal for all the parties is to keep the tracking implementation process as lean and as less prone to misunderstandings as possible.
That is why we're building upon data attributes instead of writing manual code. Yes, this means that in general, you can only measure what your users really see, click, and do on your website or within your web app. What's not in your markup can't be measured with the walker.js.
But this is also a huge advantage, because again what your users don't see or aren't able to click is not being measured. Most of the cases where tracking code breaks are when the UI is being changed or further developed and nobody thought about the tracking because it's too far away from the core product development. It's much less likely to kick out HTML attributes that are added to the whole site. Somebody will at least ask what they are and do.
Also, I bet there is not a single developer out there that is not able to set HTML attributes. It's just very easy.

Based on an Entity Action Event Model

One of the great things about elbwalker is the full flexibility of event definitions. You can build your tracking based on your business logic instead of trying to press your business logic into analytics specs.
We believe that tracking shouldn't sound like some abstract technical concept. It should feel natural and everyone involved should immediately understand it. Only when everyone understands what is being measured, there will be fewer misunderstandings, higher data quality, and more actionable data in the organization at the end of the day.
An elbwalker event consists of three components: a trigger (e.g. load), an entity (e.g. page), and an action (e.g. view).

Vendor-agnostic

Instrumenting tracking based on individual requirements and rules of analytics vendors means you can't abstract the measurement at the core when most of the tools need kind of the same event data.
Instead, you can do the concept and tagging once through an independent open-source service to achieve a reliable foundation with the walker.js.
In our pre-built destinations, the right mapping is already done for you.