// product instrumentation
This page is instrumenting you.
Obviously. Knowing what happens inside a product is the entire job — a PM who can't answer that is guessing. What's worth your time here isn't that I measure, it's what I chose to measure and why. So the whole thing is on the table: what fires, what the server already knows, and what I left out.
That count was already above zero before you read this sentence.
Your session, as it happens
Real events, in the taxonomy I designed for this site — declared before they were fired, each carrying only the properties it was designed to carry. Hover any event to see the decision it exists to inform. If a claim further down this page isn't true of this panel, the page is wrong.
Derived from the request you just made. Nothing here required a permission prompt, and every product you use knows the same things.
resolving…
Your city comes from resolving your IP at the edge — the same derivation every analytics platform performs, and the one this site uses to tell a referral surge in one market from organic growth. The raw address isn't shown here or stored by me; the resolved location is the part that answers a question.
No permission prompt, no tracking pixel, nothing exotic. That is the ordinary content of a web request — and it's what every product you used today knew about you before you touched anything.
Open your inspector and you'll find it. That's the real instrument — clicks, pageviews, the funnel milestones above, your city resolved from your IP. I run it because I want to know whether any of this works, which is the same reason I'd instrument anything I owned.
The judgment isn't in collecting less.
It's in knowing which questions the data has to answer, and refusing the collection that answers none of them.
This site has one question: does letting someone test the work make them likelier to read the résumé? Location tells me whether a spike came from one market or everywhere at once — the difference between doubling down and doing nothing.
The one-way door
Most instrumentation mistakes are expensive. One is unrecoverable. If you arrived here through a tracked résumé link, the panel above already showed you this: anonymous events snapping onto a known visitor the moment an identifier appeared.
The history survives. You can ask what someone did before they converted, which is the only version of the question worth asking.
No amount of later engineering recovers this. The events exist, and they belong to nobody. This is the decision people mean when they say instrumentation can't be retrofitted.
You can fix a badly named event. You cannot fix a person you never knew was the same person.
Nobody fails at this by picking the wrong vendor
They fail because events accumulate one feature at a time, named by whoever was shipping that week.
Every name above is defensible on its own. Together they make a one-line question into a research project — and none of the three fires at the same moment, so even reconciling them produces a number that is quietly wrong.
The second failure is subtler and worse: data collected wrong looks exactly like data collected right. No error message, no failed build, no alert. You find out when someone makes a decision on a number that has quietly been wrong for a year — and by then the fix isn't a code change, it's a migration and an apology.
Which is why I treat a taxonomy as a design artifact with the review discipline of a schema. Written down, argued about, and checked against rules before it ships — because the cost of getting it wrong is paid much later, by people who weren't in the room.
What I design against
Taxonomy before instrumentation
Naming is a design activity that happens before a line of tracking ships. Events added feature-by-feature, by whoever shipped that week, are how a taxonomy becomes unqueryable in eighteen months.
Every event names a decision
If you can't say what decision it informs, it isn't instrumentation, it's collection. Small taxonomies stay correct because people can hold them in their heads; large ones rot invisibly.
Identity is the schema
When identity resolves, and what persists as a trait rather than a property, determines which questions are answerable later. It's the one part that cannot be fixed after the fact.
Personal data stays out of the stream
An event stream is built to fan out to third parties. Anything in a property goes everywhere the stream goes, at once — so an email in a payload is a compliance problem in a dozen systems rather than one.
Funnels are questions, not reports
“Does connecting a second source predict retention?” produces different instrumentation than “show me the signup funnel.” Only one of them changes what the team does on Monday.
Close the loop or it's a dashboard
Measurement that ends in a report ends. It closes when behavior drives action automatically, and the response to that action returns as evidence for the next product decision.
Where this comes from
At ServicePower I architected the product analytics program. I defined the event taxonomy and the identity-capture model and mapped the funnels for the growth areas that mattered — specifying what would be measured, and why, before anything was instrumented. That sequencing was the point: naming and identity are the decisions you cannot revisit cheaply.
Deliberately not the whole product. Instrumenting everything is how taxonomies rot — you get hundreds of events nobody can hold in their head, most of them attached to no decision, and the ones that matter drown. Starting where the growth questions were meant the taxonomy stayed small enough to stay correct, and earned the right to expand.
Once the development team implemented the events and identity capture, I stood up Segment as the customer data platform and built the segmentation layer on it — behavioral audiences derived from live usage rather than from assumptions. Those audiences routed into HubSpot for lifecycle and sales outreach, and events forwarded into Intercom to create cohorts and custom fields that drove in-product surveys, targeted programs, and research recruiting.
That's the loop I care about: instrumentation feeds segmentation, segmentation drives engagement, and the response comes back as evidence for the next product decision. It's also the substrate under how I prioritize — reach and impact estimated from observed behavior, and a return on investment I can defend, rather than a stack of opinions with a roadmap stapled to it.
The method here is deliberately general and everything on this page was built from scratch. Nothing reproduces my employer's taxonomy, data, or customer information.
Now do it for your product
Describe a flow and this designs a taxonomy for it — events with triggers and typed properties, an identity model, funnels written as questions, and an explicit list of what it chose not to track.
Watch the review above the output. A model produces a plausible taxonomy every time, and plausible is the failure mode — you can't tell a good spec from a convincing one by reading it quickly. So a deterministic linter checks it: naming and tense, personal data, unbounded-cardinality fields, enums with no values, funnel steps referencing events nobody declared. No model runs in that step. Same spec in, same findings out.
It flags its own generator regularly. The same linter runs against this site's taxonomy in the test suite, and the build fails if it stops passing — which is the part that costs something.