Attribution engineering
Joining sessions, leads, deals, and closed revenue, then repairing the fields that break the join. I run source repair every fifteen minutes because the alternative is a number that has been quietly wrong since March.
Growth infrastructure · Attribution · Applied ML
I build the platform the growth squads run on.
Data pipelines, tracking standards, attribution plumbing, and models wrapped well enough that someone can act on them. I write production Rust and Python, and I spent eight years in marketing first, so I know which measurement problems are worth solving.
15 minbetween attribution repair runs
8data sources in one automated pipeline
0real buyers blocked by a shipped classifier
Meta CAPIbuilt, with pixel deduplication
The shape of the work
Capture, govern, join, activate
What I do
Server-side tracking
Meta Conversions API with event-ID deduplication against the browser pixel, and offline conversions pushed from the CRM back to the ad platforms so bidding optimises on deals rather than form fills.
Tracking standards
Naming conventions, a shared schema, and one place the definitions live. Every team that skips this ends up with four events that mean the same thing and no way to merge them.
Lead scoring and enrichment
Pipelines that score fit, enrich from public signals, and keep CRM data clean enough to act on. Built for two different companies, one B2B and one selling into a US services market.
Models that survive contact
Backtest before shipping, a fallback for every call, a log of every decision, and a visible health signal. A model without those is a demo somebody put in front of real money.
Distributed systems, honestly
Everything I build assumes a source is down.
This is the theme running through all of my work, and it is the thing I would bring on day one. Marketing systems fail differently from application code. They do not crash. They keep producing a number that is quietly wrong, and nobody notices for a quarter.
- Independent degradation. In the weekly reporting pipeline every source fails on its own. A dead API prints a note in its section and the other seven still build. If any single source could stop the run, the report would have stopped being weekly, and then it would have stopped existing.
- Staleness is a failure too. If a cached source is older than the reporting window, the section says so and contributes nothing to the headline numbers. A stale figure reaching a scorecard is worse than a missing one, because it gets quoted.
- Idempotent writes. Anything that publishes or sends checks for an existing ID first. A scheduled job that can double-post is a job you will eventually turn off.
- Visible health. Every scheduled job writes a log, and the ones that matter show a status light on a dashboard someone opens weekly.
- Rate limits and lag are design inputs. Search Console data lags about three days. Treating an incomplete window as a drop makes every Monday look like a crash.
Codifying knowledge
The repo explains itself to the next person.
Every project I run carries instruction files checked into version control: what each script does, which credentials it needs, what breaks, and which API gotcha cost a day last time. They are written for an AI agent and they work just as well for a colleague, which is the point.
That habit is why I can hand a system over. It is also why the same agent tooling I use for coding can pick up a project and be useful immediately, rather than needing me to explain it every session.
Evidence
Shipped and running
Server-side conversion tracking
Meta Conversions API with pixel deduplication on my own funnel, and closed deals pushed from HubSpot back to Google Ads.
Read the case studyAttribution repair
Source fields overwritten by tracking data every fifteen minutes, then revenue joined back to first touch with its limits printed on the output.
Read the case studyLead qualification gate
A classifier backtested against six months of labelled history, with zero false positives on real buyers.
Read the case studyOutbound signal engine
A Rust service for a client that reads buying signals from job boards and communities, ported off a no-code platform with parity tests.
Read the case studyWeekly reporting system
Eight sources, independent failure, staleness detection, and a trend history that survives across machines.
Read the case studySEO kaizen loop
A scheduled pipeline that freezes a baseline, then re-measures the same pages at four and eight weeks.
Read the case studyRefreshAgent
My own product. The GA4 and Search Console data layer that my other pipelines call instead of talking to Google directly.
Read the case studyStraight answers
Where I am strong, and where I would be learning.
| Area | Where I am |
|---|---|
| Production code | Strong. Two Rust services shipped, one ported off a no-code platform with parity tests written against the original behaviour. Python for the data work. |
| APIs, webhooks, failure modes | Strong. Every system above runs on APIs rather than exports, and each one is built assuming a source is down. |
| Attribution and CRM data | Strong. Source repair, the deal-to-contact-to-first-touch join, and an honest unattributable bucket. |
| Applied ML in production | Solid on the wrapping: backtests, fallbacks, decision logs, health signals. I have shipped classifiers, not trained deep models. |
| Server-side tracking | Strong on web. Built Meta's Conversions API on my own funnel, with an event ID on each server event matched to the browser pixel so the pair deduplicates. Also push offline conversions from the CRM back out to the ad platforms. |
| Mobile attribution | None. No AppsFlyer, no SKAN. My server-side work is web, and in-app attribution is a different problem. |
| Tracking governance | Learning. I have implemented tracking, not owned a schema-versioned event taxonomy or a consent framework across several squads. |
| Causal inference | Learning. My experiment discipline is one-variable-at-a-time testing and backtesting against known outcomes, not synthetic control or uplift modelling. |
Confidentiality
What I withhold.
The case studies describe methods and structures. Employer and client figures are rounded or given as change rather than absolute values. Account identifiers, campaign names, keywords, and anything about a named contact or deal are left out, and so are screenshots of anyone else's systems.
I will walk through any of it in detail in a conversation, at the level of method.