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 2021–2024
Walmeric and Glassbox wired into the measurement layer
Phone lead capture in the logged-in area ran through Walmeric. I integrated the form and its submission, and carried the Walmeric visitor identifier into the data layer, which is what ties a call back to the session behind it. On Glassbox, I improved its integration with Adobe Analytics.
- Walmeric
- Glassbox
- Adobe Analytics
- Leads
-
Built 2021–2024
Replacing a bank tag manager without switching measurement off
I inherited it from another supplier and it could not be trusted, so nearly all of it was rebuilt: the data layer, the load rules, the extensions and the tags. All of it with the site in production and no downtime window, which forces you to move in pieces and prove the new one says what the old one said.
- Tealium iQ
- Data layer
- Migration
- Production
-
Built 2021–2024
Two Tealium profiles inside one brand
One brand, two different worlds. The commercial site and the transactional one share no tags, no consent rules and no risk profile. I kept a profile for each, with Adobe Analytics and Target in both, and most advertising tags only in the commercial one.
- Tealium iQ
- Adobe Analytics
- Paid media
- Governance
-
Built 2021–2024
Custom campaign channel taxonomy in Adobe Analytics
Campaign parameters in the URL are parsed with a per-channel grammar and mapped into Adobe Analytics variables, each with a declared meaning. It replaced an earlier position-based parser that broke as soon as an agency changed its tagging format.
- Adobe Analytics
- Attribution
- Taxonomy
- Paid media
-
Built 2021–2024
Server-side tracking and paid media attribution
Paid media pixels deployed client-side and server-side, with routing on Tealium EventStream and server-side GTM. Identifiers left the browser hashed, validated before hashing and only where consent allowed. The platform processed tens of millions of events a month.
- EventStream
- Server-side GTM
- Paid media
- Attribution
-
Built 2021–2024
Measurement held until the user decides in the banner
The first page view happens before anyone has accepted anything. While the banner is open the page sits behind a cover, and that view is stored rather than lost or sent regardless: it is replayed afterward, following the accepted categories. Without consent nothing leaves, and with it the entry to the session survives.
- Consent
- Tealium
- Data layer
-
Built 2021–2024
Promotional component measured inside the logged-in area
A promotional component inside the authenticated area, with its placement and its click measured as their own variables rather than as one more navigation. Each position carries its own slot, which is what allows placements to be compared and then kept or pulled on evidence.
- Adobe Analytics
- Logged-in area
- Personalization
-
Built 2021–2024
What session replay is allowed to record
A session replay tool sees the user screen, and inside a bank logged-in area that screen is their money. Rather than trusting default masking, what it may capture is declared in a list: outside it, nothing is recorded. Installing the tool is easy. Deciding what it has a right to see is the work.
- Glassbox
- Privacy
- Logged-in area
- Governance
-
Built 2021–2024
One collection layer, on the Adobe Web SDK
Moving from legacy per-surface libraries to a single collection layer on the Web SDK. This is the piece that makes everything after it possible: without one collection layer, server-side, the unified profile, and the move to CJA all inherit the divergences they were meant to fix.
- Adobe Web SDK
- alloy.js
- CJA
- Migration
-
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. Standardizing retail, fashion, travel, and automotive forces you to separate the data contract from the tool that implements it.
- Adobe Launch
- GTM
- Tealium iQ
- Standardization
-
Built 2018–2021
Early migration from Universal Analytics to GA4
For a fashion account, with the platform just released and none of the guidance that exists today. Both properties ran side by side in the same container through the transition, which is what lets you compare numbers and explain the differences before switching the old one off.
- GA4
- Universal Analytics
- Migration
-
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
Daily SFTP ingestion into Drive, with three update modes
A Cloud Function starts a virtual machine at the scheduled time; the machine reaches the SFTP, loads the CSV files into Drive and Sheets, and shuts itself down when finished. The machine exists because of one specific constraint: the server only accepted a fixed IP, and Cloud Functions had none.
- Google Cloud
- Python
- Drive API
- SFTP
-
Built 2018–2021
Notebooks that configure analytics in bulk and close the ticket
Python notebooks against the Google Analytics management API to create and update goals, filters, custom dimensions, and permissions in bulk across accounts, properties, and views. Every change was diffed against the live configuration first, and the Jira ticket was transitioned on completion.
- Python
- Management API
- Jira
- Governance
-
Built 2018–2021
Server-side tagging with custom clients, when sGTM had just shipped
A server-side container with custom clients, not just the stock ones. One for the legacy collection, one for the new one, one for an ad platform, plus outbound requests to an in-house API. The container was exported in March 2021, with the tool barely out.
- Server-side GTM
- Custom clients
- Collection
-
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.