walkerOS for data leads
The event schema that outlives whoever wrote it
Your event definitions go into a contract in flow.json, the same file that configures the pipeline. A validate step you add to the pipeline checks events against it before they reach GA4 or another destination, and with the file in git, every change has an author and a date.
Sounds familiar
The tracking you answer for but didn't build
flow.json, so a cleanup becomes a diff that can be reviewed before it ships. The deploy guide recommends keeping that file in git so deploys stay reviewable and reversible.flow.json. A validate step in the pipeline checks the events that pass through it against that contract.flow.json lives in a repository you own, an agency works through pull requests. Ending the engagement means removing their access, and the setup stays with you, running on infrastructure you control.Contract
Write the event definitions once and let teams add to them
A contract is a named block of JSON Schema at the top of flow.json, next to the flows that use it. It lists the fields each event must carry and the values they may take. A team with extra requirements, such as a logged-in area that also needs a user ID, extends the shared contract instead of copying it.
"contract": {
"default": {
"tagging": 1,
"schema": {
"properties": {
"globals": { "required": ["country"] }
}
}
},
"web": {
"extend": "default",
"events": {
"product": {
"add": { "properties": { "data": { "required": ["id", "quantity"] } } }
}
}
},
"web_loggedin": {
"extend": "web",
"schema": {
"properties": {
"user": {
"required": ["id"],
"properties": { "id": { "type": "string" } }
}
}
}
}
}web inherits the required country from default, and web_loggedin adds a required user.id on top of both.
Validation
Check events against the contract inside the pipeline
The validate transformer is a step you place in the flow and point at a contract. In pass mode it marks each event as valid or invalid and lets it through. In strict mode an event that fails stops there and never reaches the next step. The list of errors is stored apart from the event, so it is still there after a strict drop.
"validate": {
"package": "@walkeros/transformer-validate",
"config": { "settings": { "contract": ["$contract.web"], "mode": "strict" } },
"next": "ga4"
}In strict mode, an event that fails $contract.web is dropped here and never reaches ga4.
Consent
Each destination states the consent it needs
Consent is a field on every event, and each destination declares in its config which consent it requires. A destination receives events once one of its listed consents is granted, and until then they wait in a queue. When the consent state is updated, the queued events are processed in their original order. CMP sources for CookieFirst, OneTrust and Usercentrics send that update for you.
"destinations": {
"api": {
"package": "@walkeros/web-destination-api",
"config": {
"settings": { "url": "https://your-api.com/events" },
"consent": { "functional": true }
}
},
"ga4": {
"package": "@walkeros/web-destination-gtag",
"config": {
"settings": { "ga4": { "measurementId": "G-XXXXXXXXXX" } },
"consent": { "analytics": true }
}
}
}The API destination needs functional consent and GA4 needs analytics. Events for each wait in a queue until the visitor grants that consent.
Where it fits
It runs next to the setup you have today
What stays
- GA4 and the other tools you report from stay, each as a destination with its own mapping.
- Your CMP still makes the consent decision. walkerOS picks up its state through a CMP source or the
walker consentcommand. - Existing
dataLayer.pushcalls keep working, and the dataLayer source passes them into the pipeline as well. - The definitions your teams already agreed on are the input for the first contract.
What changes
- Required fields and allowed values move from a shared document into a contract that a validate step checks.
- A cleanup or a handover shows up as a diff in git, and each change carries the name of the person who made it.
- An agency or contractor works in your repository, and removing their access leaves the setup in place.
- Consent requirements per destination are written in the config, so a change to them goes through review like any other change.
Pick one high-traffic event, write its contract, and have a developer add a validate step in pass mode. Review which events get marked invalid before anything is switched to strict.
What walkerOS does not do for you
- walkerOS will not settle what "purchase" means across your teams. Someone has to agree on that before it goes into a contract.
- There is no approval screen for non-technical stakeholders. Changes to a contract are reviewed as pull requests.
- Validation only covers events that reach a validate step and match a rule in the contract, and an event with no matching rule passes. A component that stops sending an event altogether leaves nothing to check, so missing events need their own monitoring.
- walkerOS collects and routes events. It has no profile store, audience builder or reverse ETL, so anything you build on top of the data is still your own work.
- Consent handling still needs your own legal review. The walkerOS docs do not give legal advice.
Questions
Questions before you start
GTM is free. What does running walkerOS cost us, servers included, and who looks after them?
In the browser neither costs anything: GTM is free, and walkerOS is open source under the MIT license. Server-side collection costs money with either tool, because a GTM server container also runs on infrastructure you pay for, and someone has to deploy and maintain it. The difference is what you pay for: GTM is a closed product you configure within its limits, while walkerOS is code your developers can extend and run where they choose. The deploy guide covers Docker, Node and managed hosting, so you can price each path against what you run now.
We already have a tracking plan and a review round before anything ships. What does a contract add?
In the setups we see, the plan has usually drifted from what the site sends, because nothing that runs reads it. A contract sits in flow.json, and a validate step checks events against it as they pass through the pipeline, so a mismatch shows up when it happens. Your review round stays, and it gets a file a machine can check after approval. To watch one fail, follow Break it on purpose: give a step example an event without a required field and run walkeros validate flow.json --strict.
Six months from now someone asks why a tracking setting changed, and the person who changed it has left. What can they find out?
If flow.json lives in your git repository, every committed change to a contract, a mapping or a consent rule has an author, a date and a message. Git cannot recover a reason nobody wrote down, so ask for one in the commit or the pull request. To see what that history looks like, run git log -p flow.json in the repository.
Every vendor migration turns into re-tagging the whole site. Does that change?
Events are defined in your own contract, and each tool gets its own mapping from those events. Once the site sends walkerOS events, switching or adding a tool means configuring that destination and its mapping, and the tagging and the other destinations stay as they are. If your tracking still runs through GTM, the dataLayer source can read the existing dataLayer.push calls, but replacing the vendor tags in the container with destinations is a one-time job. Check the destinations list for the tool you expect to switch to next.
Next steps