Service
Measurement and tracking architecture
I design or rebuild data collection across web and apps so events, identities, and documentation follow the same contract.
What is included
- 01
An inventory of events, variables, identities, and consumers.
- 02
A versioned tracking plan and event specifications.
- 03
Web and app data-layer design or review.
- 04
Configuration in Adobe Analytics, GA4, Adobe Launch, GTM, or Tealium iQ as scoped.
- 05
Quality tests, acceptance criteria, and publishing governance.
- 06
Documentation for development, analytics, and marketing teams.
Related experience and reasoning
-
Built 2021–2024
Shared data layer for web, logged-in area and app
Three surfaces with three separate implementations, and therefore three versions of the truth. I rebuilt the data layer on all three against one event contract, coordinating a team of 5, with functional and technical documentation kept in Confluence.
- Data layer
- Web and app
- Event contract
-
Built 2018–2021
Measurement template containers, reused across accounts
Reusable GTM template containers, exported and imported into each client account: one measurement base, one for ecommerce, one per consent platform, and one for app. Standardising retail, fashion, travel, and automotive forces you to separate the data contract from the tool that implements it.
- Adobe Launch
- GTM
- Tealium iQ
- Standardisation
-
Built 2018–2021
Analytics SDKs on iOS and Android, and hybrid integrations
Native SDK implementation and resolution of the hybrid integrations between the native layer and the embedded web view. That is where sessions and identities get lost, and nobody looks until the numbers stop matching.
- iOS
- Android
- SDK
- Hybrid app
-
Built 2018–2021
Dashboards per market, with access governed
A consumer goods brand with subsidiaries across several European markets, and one dashboard for each. Building them was not the hard part. Deciding who sees what was, so every market carried a declared recipient and access level. A report shared too widely leaks and one shared too narrowly goes unused.
- Reporting
- Governance
- Multi-market
Frequently asked questions
Do we have to rebuild all the tracking from scratch?
Almost never. We start from what already works and fix what breaks the contract. Rebuilding everything is only justified when current events cannot be reconciled across surfaces, and you find that out in the first workshop, not at the end.
Can our own team implement it?
Yes, and that is what I prefer. I define the event contract and document it; the implementation can be yours. What does not work is the reverse: defining the contract ticket by ticket while development happens.
Does this work for GA4 or only for Adobe?
The event contract comes before the destination and does not depend on it. I have worked on collection against GA4, Adobe Analytics, Tealium, and Customer Journey Analytics. If the destination changes tomorrow, the contract still holds.
How long before the documentation goes stale?
As long as it takes someone to add an event without going through the contract. That is why the deliverable is not just the document: it covers where it lives, who approves it, and how to check that the implementation still matches it.
Does this fit your problem?
Send me the context and I will tell you whether this scope fits or a different starting point makes more sense.