Analytics & MarTech

Analytics is where I learned to build software

At Vouchercloud, I managed paid search across fifteen countries. Following a customer from an advert to a retailer and back through an affiliate network required reporting that did not exist, so I started building it. That experience still shapes my approach: a report is only as useful as the events, identities, integrations and commercial records underneath it.

MarTech is the operational side of the same work. It includes the systems that use what we know about a customer: advertising audiences, consent, CRM, messaging, experiments and lifecycle journeys. Most of my work has been around the join between measurement and action.

Why it matters

When the measurement is sound, marketing, product, engineering and commercial teams can work from the same account of what is happening. When it is not, money goes back into the wrong campaigns, product changes are judged against unreliable events and reported revenue cannot be reconciled with the systems where the transactions actually happened.

I do not expect every system to produce exactly the same total. They often use different identities, attribution windows and definitions. I do expect somebody to understand the difference. A plausible number can be more dangerous than an obvious failure because an empty report gets investigated, while a dashboard that quietly counts the same action twice can shape decisions for months.

Why I like the work

I enjoy the investigative part. If two totals disagree, there is a reason. An event began somewhere, passed through a set of rules and ended up in a table or report. Following that path through browser requests, application code, APIs and databases until the difference makes sense is satisfying work.

I also like that analytics sits between several kinds of people. A stakeholder can describe the decision they are struggling with, an analyst can describe the data they need and an engineer can describe the product that has to produce it. I am comfortable translating between all three and then doing the implementation work myself.

PostHog is now a large part of how I work with product analytics. I use it in my own products, and I wrote and run Measure, Keep, and Grow, Hogsend's course on product-led growth and product analytics using PostHog.

The course contains fifteen chapters and 146 lessons. It starts with why a product should measure anything at all, then works through PostHog setup, events and identity, a shared tracking plan, funnels, retention, session replay, dashboards, feature flags, experiments, lifecycle messaging, paid acquisition, holdouts, incrementality and reporting.

Writing it forced me to explain the judgements behind an implementation, not only which buttons to press. That includes why payment events should come from the server, how to QA instrumentation like code, when PostHog is the wrong tool, how a holdout separates activity from incremental effect and how to report only what the data can support.