Founder & Engineer / Tracking Infrastructure
I approach tracking as infrastructure: define what an event means, control how it moves, verify what each destination receives, and keep the full path possible to debug.
Tracking is a specialized part of a broader engineering practice, connecting product behavior, application data, delivery systems, and downstream tools.
Defined
Events have explicit meaning and ownership.
Controlled
Collection and delivery follow known rules.
Observable
Failures and transformations can be traced.
Useful
Destination data answers a defined question.
Data flow / 01
Reliability depends on understanding every handoff. Each layer should have a defined input, transformation, output, and way to inspect failure.
Web, application, service, or transaction behavior.
Named event, trigger, typed properties, identity, and consent state.
Data layer intake, client checks, tags, and controlled transport.
Validation, normalization, enrichment, routing, and delivery control.
GA4, attribution endpoints, and operational integrations.
Consent and identity rules travel with the event path; they are not repaired after delivery.
Event design / 02
An event model is a contract between product behavior and every system that consumes its data. Clear semantics prevent each destination from developing a different version of the truth.
01
Events describe a completed product or system behavior. Names should remain meaningful even when the interface or implementation changes.
02
The specification identifies exactly when an event is emitted, how duplicates are prevented, and which source owns the truth.
03
Required and optional parameters, formats, allowed values, and identifiers are explicit rather than inferred downstream.
04
Identity, session, campaign, consent, and environment context are included only where their meaning and handling are understood.
Delivery / 03
Client and server containers have different responsibilities. Keeping those responsibilities explicit makes transformations easier to reason about and failures easier to locate.
Client boundary
GTM connects the application data layer to collection logic. Variables, triggers, and tags should implement an existing event contract, not become the place where meaning is invented.
Server boundary
Server-side GTM provides a controlled delivery boundary where requests can be verified, normalized, enriched from trusted context, and routed to defined destinations.
Destinations / 04
Destinations need different schemas and identifiers. Those mappings should be deliberate without allowing tool-specific requirements to redefine source behavior.
01
Map the event model into GA4 with deliberate parameters, identity handling, and configuration so reports reflect the intended product behavior.
Events / Parameters / Identity / Configuration
02
Preserve the identifiers and source context required to connect an observed outcome to its acquisition path without treating attribution as perfect certainty.
Source context / Identifiers / Conversion delivery
03
Translate one governed event into destination-specific payloads while keeping transport concerns separate from the event's core meaning.
Mapping / APIs / Routing / Failure handling
Data quality / 05
When data differs from expectation, the useful question is where meaning, payload, or delivery changed. Debugging follows the same boundaries as the architecture.
Start from a known user or system action and record the expected event.
Check the data layer, browser request, and consent state at the source.
Follow the request through client and server containers, transformations, and routing.
Confirm destination acceptance and explain differences without hiding them.
Collaboration / 06
For event architecture, GTM and server-side GTM, GA4, attribution integrations, or data quality investigation.