How to collect first-party data with walkerOS (formerly walker.js)

How can companies customize their products and services in a privacy-first world?

Any marketing effort without data is nothing more than a guess. And no company can afford to leave their growth to chance. That’s why they need reliable information about their customers to make confident, precise decisions.

Modern teams do this by collecting feedback and tracking on-site behavior in a controlled way. This helps them create personalized customer experiences that increase satisfaction, loyalty, and ultimately revenue.

The more high-quality first-party data you have, the better you can personalize campaigns — and the more likely you are to improve customer satisfaction, loyalty, and sales.

However, there’s a catch. Companies must obtain clear consent to collect and use data. If they don’t, they risk legal and financial consequences.

What is first-party data?

First-party data is information you collect directly from your own touchpoints — your website, app, CRM, or offline funnels. It can include:

• Email addresses and profile data from your own forms
• Purchase history and lifetime value
• Website interactions such as page views, clicks, scroll depth, and form submissions

Because this data is collected on your own properties with your own tracking logic, it’s usually more accurate and reliable than third-party data. You control how it’s stored, processed, and shared.

Advantages of using first-party data

GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act) compliant data collection

If you manage the collection process yourself, you can obtain explicit permissions and document how you use audience data for marketing purposes. Using first-party data segments for targeting is considered a safer approach because you know exactly how the data was collected and from which sources.

Data use allowed in all major browsers

Safari and Firefox have already blocked most third-party cookies, and Chrome is tightening controls and shifting towards more user-centric privacy tools instead of relying only on third-party cookies. This means publishers can’t depend on external trackers in the same way as before; they need their own first-party data strategies.

Update: Google originally intended to end third-party cookies by early 2025, but later announced they would keep cookies while giving users more control over their browsing data and privacy settings.

Creating custom segments

First-party data lets you build powerful, business-specific segments, such as:

• Visitors who checked pricing pages more than three times in 7 days
• Users who added to cart but didn’t complete the checkout
• Customers who purchased over a certain amount in the last 90 days

These segments are far more actionable than generic “interest” audiences you get from third-party providers.

What is third-party data?

Third-party data is collected by companies that don’t have a direct relationship with your users. It often includes demographic data, interests, and browsing behavior aggregated across many sites and sources.

Some companies still buy third-party data to enrich their targeting or remarketing. However, this data is often less reliable because it comes from multiple sources and may be outdated or inaccurate. It’s also increasingly limited by regulation and browser policies.

Why is third-party data going off?

Users are more aware of how their personal data is shared and resold. They’re demanding transparency, choice, and control. Data privacy regulations like GDPR and CCPA have forced companies to rethink how they track and share information.

As a result:

• Some companies now use third-party cookies only with explicit user permission.
• Others are turning off third-party data vendors completely and building first-party data stacks instead.

One of the modern ways to do this is to use tools like walkerOS (and its pre-built app walker.js) to implement a first-party tracking layer under your own control.

Read more to learn about The Schrems II Decision.

What is the GDPR?

The GDPR is an EU regulation that protects the data privacy and security of European Union citizens. It defines how companies must collect, store, process, and share personal data.

Companies must:

• Get valid consent (where required) before collecting and using personal data
• Explain clearly what they collect and why
• Let users access, correct, and delete their data

Third-party data providers are affected even more, since they don’t have a direct relationship with end users and must prove their collection methods are lawful and transparent.

From walker.js to walkerOS: what changed?

When this article was first written, walker.js was the main library used to implement first-party tracking with a dataLayer and browser source. Today, the project has evolved into walkerOS, a complete event data collection solution designed for first-party tracking.

According to the official documentation, walkerOS is an “event data collection as code” solution. It captures, structures, and routes events with built-in consent management and vendor-agnostic routing, all directly in your code. The project started as the web tracking library walker.js and has evolved into a complete first-party tracking system for modern teams and the modern web.

walkerOS architecture in a nutshell

walkerOS is split into modular building blocks:

• Sources – entry points that capture events, such as the Browser Source for DOM interactions and the DataLayer Source for existing GA4/GTM events.
• Collector – a unified @walkeros/collector package that receives standardized events and handles consent, enrichment, and routing to destinations.
• Destinations – specific connectors (web/server) that send data to analytics, CDPs, warehouses, or marketing tools (e.g. GA4, Meta, BigQuery).

This replaces the older, more monolithic @elbwalker/walker.js package with a more flexible source → collector → destination architecture.

Where does walker.js fit now?

walker.js still exists, but as a pre-built walkerOS application rather than the core library. In the official docs, it’s described exactly like this:

“Walker.js is a pre-built walkerOS application that combines both the browser and dataLayer sources with the collector and a default dataLayer destination into a pre-built package. It’s designed for users who want instant web tracking without complex setup or configuration.”

In other words:

• If you want a quick drop-in script with minimal configuration, you can still use walker.js as the “all-in-one” application.
• If you want a scalable, fully controlled first-party tracking setup, you use walkerOS directly with its modular packages.

Key migration highlights: walker.js → walkerOS

If you previously implemented walker.js, here are the most important changes when moving to walkerOS:

• New core packages: @elbwalker/walker.js is replaced by @walkeros/collector and @walkeros/web-source-browser. Types and utilities are merged into @walkeros/core.
• Unified collector: instead of calling legacy functions, you now use startFlow() to wire up sources, collector, and destinations.
• Modular sources: DOM tracking is handled by @walkeros/web-source-browser, while dataLayer integration is handled by a dedicated DataLayer Source.
• Data attributes behavior change: the data-elbaction attribute now applies to the nearest entity only; the old “apply to all entities in the hierarchy” behavior is moved to data-elbactions. This matters if you rely heavily on nested entities.
• Triggers & actions: walkerOS refines triggers like visible vs impression, helping you differentiate one-time impressions from repeated visibility events.
• Built-in consent: consent handling is integrated into the collector from the beginning, supporting privacy-first setups and regulation compliance.

Best tools for collecting first-party data (2025)

Most companies combine their first-party data stack using a mix of analytics, consent tools, and data infrastructure. Here are the most commonly used components:

• Google Analytics 4 (GA4) – first-party analytics built on event-based tracking.
• Google Tag Manager (GTM) Server-Side – moves tracking to a first-party subdomain.
• walkerOS – open-source event framework for privacy-first tracking.
• Customer Data Platforms (CDPs) such as Segment, RudderStack, or mParticle.
• Consent Management Platforms (CMPs) like Cookiebot or OneTrust.

Most modern teams combine these tools to build a future-proof first-party data strategy that satisfies both marketing and privacy requirements.

How to collect first-party data with walkerOS / walker.js

With third-party data becoming less reliable and more restricted, companies are moving toward first-party setups that they fully control. walkerOS is built exactly for that use case.

At a high level, a walkerOS-based setup works like this:

1. Tag your frontend using DOM data attributes (e.g. data-elb="product", data-elbaction="click:select") so events are defined close to the UI.
2. Use the Browser Source to capture interactions from the DOM and translate them into structured events.
3. Optionally add the DataLayer Source if you already have GA4/GTM events that you want to reuse or migrate gradually.
4. Configure the Collector (consent defaults, user IDs, enrichment, routing logic).
5. Connect Destinations such as GA4, ad platforms, or your data warehouse via walkerOS destination packages.

Because walkerOS is vendor-agnostic and code-based, you own the full tracking logic instead of re-creating it in a visual UI. That’s a big win for long-term maintainability and first-party data quality.

Advantages of using walkerOS / walker.js instead of closed tools

• Lower risk of accidentally capturing sensitive data: explicit tagging and structured events make it easier to control what you send where.
• Better control over data quality: events are versioned, tested, and reviewed like code.
• More flexible destinations: you can send the same first-party events to multiple tools without tying your tracking to a single vendor.
• Privacy-first by design: consent and purpose-based routing are baked into the architecture.

Cookie-free and session-based tracking with walkerOS

walkerOS enables cookie-free tracking strategies by focusing on anonymous identifiers, sessions, and campaign parameters rather than personal data. For example, you can track:

• Anonymized session IDs and interaction histories
• Campaign-based associations (e.g. UTM parameters, referrers)
• Aggregated event-level metrics (page views, conversions, scroll depth)

This lets you measure campaign performance without storing personally identifiable information (PII), which simplifies GDPR explanations and reduces risk.

Tagging with data-elb attributes

In the browser, walkerOS uses data-elb-* attributes to declare entities, actions, and properties in the DOM.

• data-elb="product" – defines an entity (e.g. product, article, form)
• data-elbaction="click:select" – defines when and which action should fire
• data-elb-product="id:123;name:Example" – adds properties to an entity

When the browser source runs, it scans the DOM, attaches listeners, and automatically sends events in the format entity action (for example: product select).

First-party data tracking with Google Tag Manager & walkerOS

You can combine walkerOS / walker.js with Google Tag Manager (GTM) to build a powerful first-party tracking setup.

Option 1 – Quick start with walker.js (pre-built app)

If you want to start quickly on a standard website without a build pipeline:

1. Include the walker.js script via CDN or NPM.
2. Use the configuration options exposed by walker.js (browser + dataLayer + collector) to define your setup.
3. Forward events to a GTM Server container or GA4 via a destination configuration.

This is ideal if your goal is to replace scattered third-party scripts with one structured, privacy-friendly tracking layer, while still using GTM / GA4 for reporting.

Option 2 – Full walkerOS setup with GTM

For larger or more complex stacks, you can integrate walkerOS directly:

1. Add @walkeros/web-source-browser to your frontend and configure it with startFlow().
2. Use the DataLayer Source to pick up existing GTM dataLayer events, so you can gradually migrate logic from GTM to walkerOS without a “big bang” rewrite.
3. Send events to your GTM Server container, GA4, or any other destination via walkerOS destination packages.

Using walkerOS with GTM gives you a flexible, vendor-independent event layer that still leverages familiar tools like GA4 dashboards or Looker Studio reports.

Pricing & costs

walkerOS and walker.js themselves are open source, so you don’t pay license fees for the tracking library. However, when you use GTM Server-Side on Google Cloud, a Cloud Run project is created automatically.

In a typical Cloud Run configuration, each always-on server (for example, a 1 vCPU / 0.5 GB instance) will generate a monthly cost based on usage and Google Cloud pricing. You should monitor:

• Number of requests
• Cold starts and autoscaling behavior
• Traffic patterns (spikes from campaigns, bots, etc.)

If you’re just starting, expect some baseline monthly costs per GTM server container and plan your first-party tracking budget accordingly.

Trouble setting up your own first-party tracking stack?

Don’t have a developer in your marketing team and struggling to get walkerOS / walkerJS and GTM working correctly? We can handle the implementation for you, from designing the event model to setting up the collector, sources, and destinations.

If you’re interested, feel free to contact us. We’re here to help you build a future-proof first-party data solution.