POSTHOG SETUP & INSTRUMENTATION — FIXED SCOPE · FIXED PRICE

Jake McMahon
Jake McMahon — ProductQuant
8+ years B2B SaaS · Behavioural Psychology + Big Data (Masters)

A PostHog setup your team actually uses. Event taxonomy, dashboards, and a HogQL library, built in 2 weeks.

If your PostHog instance has events nobody queries, dashboards nobody opens, and naming conventions nobody agreed on, this sprint turns it into an analytics system your team actually uses. Every product question gets a data answer in minutes, not a Slack thread that dies in #analytics.

Fixed scope, fixed price. Full refund if you don’t have a working analytics system at the end.

WHAT GETS BUILT

Event taxonomy Every user action mapped, named, and documented
Dashboards 5–8 covering activation, retention, and revenue
HogQL library 20+ pre-built queries for the metrics that matter
Instrumentation spec Engineer-ready tracking plan your team can maintain

$3,997 · 2 weeks · full refund
Audit from $997 · Full from $7,997

We build a PostHog system your team actually uses.

You get clear dashboards, consistent event tracking, and simple answers. Your team stops guessing and starts making decisions with data.

PRODUCT MANAGER

"How many users tried our new feature this week?"

You open a dashboard that shows exactly that, updated in real-time. No need to ask an engineer to write a query. You get the answer in seconds and can share it in your next meeting.

ENGINEERING TEAM

"What should we name this new button click?"

You follow a simple, agreed-upon naming rule. The event is tracked consistently from day one. This means all future data is clean and comparable, saving hours of cleanup later.

MARKETING LEAD

"Where are our sign-ups dropping off in the funnel?"

You click into a pre-built funnel report. It visually shows the exact step where people leave. You immediately know what to fix, without digging through confusing charts.

CUSTOMER SUPPORT

"A user says the checkout is broken. Is it just them?"

You check a dashboard that monitors error rates and user sessions. You see if there's a wider issue or just a single case. You can give a confident, accurate response to the customer.

One engagement, anonymized · healthcare SaaS

The four numbers below all come from a single recent PostHog build for one anonymized healthcare SaaS client. Full case note further down the page.

EVENTS AUDITED
281

Events audited and rationalised, cutting a sprawling taxonomy down to what the team actually queries.

DASHBOARDS
13

Production dashboards, organised around business questions rather than tool features.

CHARTS
118+

Charts across activation, retention, and revenue, each tied to a decision the team makes every week.

REVENUE VISIBILITY
90%→15%

Revenue-reporting gap closed from roughly 90% blind to 15%, via a warehouse integration tying billing to product usage.

PATTERNS WE SEE ON ALMOST EVERY POSTHOG AUDIT

Events fire but nobody trusts the data

A few hundred events accumulate over time. Half were named ad hoc, a quarter are duplicates, and nobody remembers what button_click_new_v2 refers to. Basic questions need someone to read the source code first.

Dashboards get built and abandoned

Five dashboards get built during onboarding. Two break, one uses the wrong event, and the last two go unchecked because they do not answer anything the team argues about in planning.

Every question takes an analyst to answer

A PM wants the activation rate for users who hit Feature X in their first week. The data is there, but an analyst has to hand-write the query every time someone asks, so most questions never get asked.

Engineering and product speak different languages

Product calls it onboarding completion. Engineering fires user_setup_done. Analytics queries signup_finished. Three events might be the same thing, and no one is sure which to trust.

WHAT THIS TYPICALLY UNCOVERS

Your most-queried events are rarely the ones that predict retention or expansion.

The events your team queries are rarely the ones that matter most.

In our experience, the most-queried events tend to be the ones that were easiest to fire, not the ones that answer the questions your team debates in planning. The taxonomy audit typically reveals that the highest-value user actions are either untracked or misnamed.

Dashboard abandonment usually points to a naming problem, not a design problem.

When dashboards go unused, teams assume the visualisations are wrong. More often, the underlying events are inconsistent or mislabelled, so the charts show data nobody trusts. Fix the taxonomy and the dashboards become useful without rebuilding them.

A HogQL library typically cuts ad-hoc query time from hours to minutes.

Most teams re-write the same queries from scratch every time someone asks a question. A pre-built library with annotated parameters means your team answers follow-up questions quickly, without starting from zero.

Your instrumentation spec determines whether PostHog stays clean or drifts back.

Without a documented spec, every new feature ships with ad-hoc event naming. Within a quarter, the taxonomy is inconsistent again. The spec gives your engineering team a reference that keeps the taxonomy coherent as the product evolves.

WHY THIS IS DIFFERENT

Many PostHog setups end with events that measure past activity instead of the moments that actually predict business outcomes such as activation, retention, expansion, and monetization. This sprint aligns your events with those moments.

The standard approach is to document what you have, recommend what you should add, and hand it to engineering. Six weeks later, nothing has been implemented. The dashboards were built around the existing broken events because nobody had time to wait for new ones.

This sprint is designed differently. The taxonomy comes first, designed around the decisions your team actually needs to make, not the events that were easiest to fire. The dashboards are built to answer specific questions, not to check a box. The HogQL library means your team can answer follow-up questions in two minutes, not two days. And the training session means the taxonomy, dashboards, and queries actually get used — not stored in a doc nobody reopens.

The goal is not a clean PostHog instance. The goal is dashboards your team opens in stand-up and queries they act on in planning. Those are different things, and many setup engagements only deliver the first one.

TIMELINE

Your team opens PostHog in Monday standup and gets the answer.

WEEK 1

Audit + Taxonomy Design

Read-only review of your PostHog instance. Every existing event assessed for what it captures, whether naming is consistent, and whether it answers questions your team actually asks. Missing events identified. Taxonomy designed around your product and decision framework.

WEEK 2

Dashboards + HogQL + Spec

5–8 dashboards built inside your PostHog instance. 20+ HogQL queries written, tested, and annotated. Instrumentation spec drafted and reviewed with your team before sign-off.

DAY 14

Handover + Team Training

1-hour live session with your full team. Every dashboard walked through, every query demonstrated, every naming convention explained. Session recorded for future onboarding.

Your team opens PostHog in standup and makes the call, without waiting for anyone.

WHAT YOU GET

Your team answers their own data questions from day 14 — no analyst bottleneck.

Week 1 · Taxonomy
Event Taxonomy Design

Every meaningful user action in your product mapped, named, and documented. A clean taxonomy your engineering team can implement and your analysts can query without reading the source code to figure out what an event means.

  • Every meaningful user action identified and defined
  • Event properties specified for each action
  • No more Slack debates about what an event means
  • Existing events audited: keep, deprecate, or rename
Week 2 · Dashboards
5–8 Core Dashboards

PostHog dashboards covering the metrics your team needs to make decisions. Built around the specific questions your team argues about in planning, not generic metrics that fail to inform your decisions.

  • Activation funnel: where users get stuck and how many
  • Retention cohorts: who comes back and at what intervals
  • Feature adoption: which features correlate with retention
  • Revenue signals: expansion, contraction, and early churn indicators
Week 2 · Query Library
HogQL Query Library (20+ queries)

20+ pre-built HogQL queries covering the metrics that matter most. Each one annotated with what it answers and when to use it. Your team can answer follow-up questions quickly without needing an analyst to write a query from scratch every time.

  • 20+ queries covering activation, retention, engagement, and revenue
  • Any team member answers their own data question without waiting for engineering
  • Parameters documented so your team can adapt them
  • Organised by question type so the right query is findable
Week 2 · Engineering
Instrumentation Spec for Engineers

A living document your engineering team can implement from. Covers every event, every property, the reasoning behind naming decisions, and the acceptance criteria for each implementation. Engineers know exactly what they are building and why.

  • Every event with full implementation specs
  • Acceptance criteria for each event so QA is straightforward
  • Naming rationale documented for each decision
  • Update process so the spec stays current as the product changes
Day 14 · Training
1-Hour Team Training Session

A live walkthrough with your team covering every dashboard, every query in the library, and how to use the taxonomy going forward. Recorded for future onboarding. Your team operates PostHog independently from this session.

  • Live 1-hour session with your team
  • Every dashboard walked through: what it answers and when to check it
  • HogQL library demonstrated with live examples
  • Recorded for future team member onboarding

On the cost of re-work: every month your team operates with inconsistent naming is a month of queries built on unreliable data. The dashboards built on broken events do not get better with time. They get abandoned. This sprint fixes the foundation so every analysis after it can be trusted.

SPECIALIZED SETUPS

Your stack has a specific shape. The setup should too.

HIPAA, eCommerce, B2B account-level tracking, mobile, migrations, and feature flags each change how the taxonomy and dashboards get built. These guides walk through what changes, and every one of them is part of the sprint.

Choosing between tools first? Read PostHog vs GA4 for product teams, or see the full deliverables breakdown.

CASE NOTE — ANONYMIZED HEALTHCARE SAAS

The situation: events fired across the product, but nothing predicted retention or revenue, and billing data lived entirely outside the analytics.

What we delivered: a 281-event audit and taxonomy rebuild, 13 production dashboards with 118+ charts organised around business questions, identity and cost analysis, sensitive-data capture boundaries, and a warehouse integration tying billing to product usage.

The outcome: revenue-reporting visibility went from roughly 90% blind to 15%, and the team answers activation, retention, and revenue questions from dashboards they trust.

FIT CHECK

Your events fire but they do not predict what happens next.

GOOD FIT
PostHog is installed but the data is not usable
Events firing · Nobody trusts the data

You have PostHog in place. Events are firing. But the taxonomy was designed by whoever set it up first, naming is inconsistent, and every time someone asks a question in planning the answer is “we need to check with engineering.” The data exists but it is not usable without interpretation.

  • Taxonomy rebuilt around decisions, not convenience
  • Dashboards that answer the questions your team argues about
  • HogQL library that turns lengthy analyses into quick queries

Stand-up goes from “we should check that” to “here is what the data shows.”

GOOD FIT
Moving from Mixpanel or Amplitude and want a clean start
Migration in progress · New PostHog account

Migrations are a chance to fix the instrumentation you inherited. The bad habits from your previous tool, like inconsistent naming and events fired for convenience rather than insight, dashboards built around what was easy to measure — do not have to carry over. This sprint designs the new taxonomy from scratch, so PostHog starts better than your previous tool ever was.

  • Clean taxonomy designed before any events are fired in PostHog
  • Previous tool’s data informs the design without carrying its problems forward
  • Migration plan that tells engineering what to fire, named correctly, from day one

PostHog starts with better data than any previous tool had.

GOOD FIT
Investor-ready analytics before your next round
Series A or B · Data room preparation

Investors look at your analytics in the data room. If your dashboards cannot clearly show activation rate, retention by cohort, and revenue expansion metrics, or if those numbers are built on events your team is not confident in — that is a conversation you do not want to have mid-round. This sprint gets your PostHog instance investor-ready quickly.

  • Clean dashboards showing the metrics investors ask for
  • Data you can stand behind when questioned on methodology
  • Taxonomy documented so investors can verify the underlying logic

The data room conversation becomes an asset, not a risk.

NOT A FIT
No PostHog, no analytics, or you need ongoing support
Wrong stage or wrong engagement

If you do not have PostHog installed yet, there is nothing to audit or build on. If you want ongoing analytics support such as monthly dashboard reviews, query maintenance, or new feature instrumentation, that is a different engagement. And if you need someone to implement the tracking plan in your codebase, that is your engineering team’s work, so this sprint gives them the spec.

What this sprint doesn’t cover

The PostHog Setup Sprint delivers the taxonomy, dashboards, query library, instrumentation spec, and team training. Your engineering team does the code changes. If you need the full picture, including implementation and ongoing support — that’s a different engagement.

  • Implementing the tracking plan in your codebase — your engineering team ships the code changes
  • Ongoing analytics support — monthly reviews, new dashboards, query maintenance
  • PostHog installation from scratch — the sprint builds on an existing instance
For ongoing analytics support → Growth LAB
Jake McMahon

Jake McMahon — ProductQuant

Jake McMahon
8+ years building retention, activation, and growth programs inside B2B SaaS · Behavioural Psychology + Big Data (Masters)

I do this work myself. The audit, the taxonomy design, the dashboards, the HogQL library. It is not a team of analysts you coordinate with via Slack. You get the senior-level thinking on what your data structure should look like and why, from the first day of the sprint.

The thing most PostHog setups miss is that the taxonomy has to be built backwards from the questions, not forwards from the events. If you design events around what is easy to fire, you end up with data that is technically accurate but analytically useless. This sprint designs the taxonomy around the decisions your team needs to make. The events follow from that.

What I will not do:
  • Build dashboards that replicate what your team already ignores
  • Design a taxonomy without reviewing the decisions your team actually needs to make
  • Deliver a tracking plan without walking your team through how to use it
  • Implement the tracking plan in your codebase — that is your engineering team’s responsibility
What access do you need?
Read and write access to your PostHog project. I build dashboards and queries directly inside your instance. No code changes to your product are required for the taxonomy design and dashboards. The instrumentation spec tells your engineering team what to implement — they do the coding work.

Teams Jake has worked with

Gainify
Guardio
monday.com
Payoneer
thirdweb
Canary Mail

DIY, CONSULTANT, OR AGENCY

Should you set up PostHog yourself, hire a consultant, or use an agency?

All three can work. The right choice depends on whether you have PostHog depth in-house, how fast you need it, and whether this is a one-off build or ongoing work.

Do it yourself

Your PM and engineers

The lowest cash cost, but your team's time is the real bill. Taxonomy decisions stall in Slack, naming drifts, and the sprawl this page describes is usually the result a year later.

Right if you have a data hire with real PostHog depth and the time to own it.

A full-service agency

Multi-person retainer

Higher cost and a longer timeline, often with senior sales and junior delivery, billed monthly. Built for ongoing multi-channel programs rather than a focused instrumentation build.

Right if you need continuous analytics and marketing work, not a scoped setup.

PRICING

Every product question answered from your own data.

Taxonomy Audit

$997

credited toward a Sprint or Full engagement

  • Full audit of your current PostHog events, properties, and dashboards
  • Data-quality register: duplicates, dead events, naming gaps
  • Prioritised fix list your team can action immediately
  • A recommendation on scope if you go further
Start with an audit →

Fee credited if you continue

Full Engagement

$7,997

fixed price · 2 weeks

  • Everything in the Setup Sprint
  • A/B experiment framework and first experiment wired up
  • Churn-risk scoring model in HogQL
  • Session-replay triage on your highest-drop-off flows
  • Extended training and a 90-day priority roadmap
Book the Full Engagement →

For teams past instrumentation basics

Not sure which tier? Start with the Audit if you are still scoping, the Setup Sprint if you already know the instrumentation is broken, or the Full Engagement if you are past the basics and want experiments and churn scoring.

Not ready to commit? Start with the free PostHog Health Check.

Working means your team opens the dashboards in planning, your analysts use the HogQL library to answer follow-up questions, and your engineers implement from the taxonomy. If your team is not opening the dashboards weekly within 30 days of handover, we rebuild them free. And if the system is not working at handover, you pay nothing. The refund is unconditional.

Questions.

Or book a call →
How much does a PostHog setup service cost? +
The setup runs on a fixed-price ladder. A $997 taxonomy audit (credited toward a full engagement), a $3,997 two-week Setup Sprint covering taxonomy, 5–8 dashboards, a 20+ query HogQL library, an instrumentation spec, and training, or a $7,997 Full engagement that adds experiments, churn scoring, and session-replay triage. Every tier is fixed-scope with a full-refund guarantee.
How long does a PostHog implementation take? +
The Setup Sprint takes 2 weeks from kickoff, and most teams start within 5 business days of booking. The taxonomy audit is faster. Implementing the tracking spec in your codebase is done by your engineering team after handover, unless added as a separate scope.
Do we need PostHog already installed? +
Yes. This sprint builds the right instrumentation on top of an existing PostHog instance. You need PostHog installed with at least basic tracking in place. If you have not installed PostHog yet, book a call and I can advise on the right starting point before the sprint begins.
Does this include implementing the tracking plan in our codebase? +
No. The sprint delivers an instrumentation spec that tells your engineering team exactly what to implement, with full specifications for every event and property. The actual code changes to your product are your engineering team’s responsibility. If you need implementation support, we can discuss adding that as a separate scope after the sprint.
What if we’re migrating from Mixpanel or Amplitude? +
Migrations are the best time to do this. Rather than copying a broken taxonomy into PostHog, the sprint designs a clean one from scratch. Your previous tool’s event structure informs the decisions, but you will not carry its naming inconsistencies or architectural problems forward. PostHog starts better than any previous tool you have used.
What access do you need? +
Read and write access to your PostHog project. I build dashboards and write queries directly in your instance. A 30-minute kickoff call to understand your product and the decisions your team needs to make. No access to your codebase or production environment is required.
How quickly can we start? +
Typically within 5 business days of booking. The sprint runs 2 weeks from kickoff. Book a call and I will confirm availability and a start date that works for your team.
What happens after the sprint if we want ongoing analytics support? +
The PostHog Setup Sprint gives your team a system they can run independently. If you want ongoing analytics support such as monthly dashboard reviews, query maintenance, or new feature instrumentation, that is covered by the Growth LAB. Most teams run the setup sprint first and either operate independently from there, or move into the Growth LAB once they have seen how the system works.
What is included in a PostHog setup? +
A full PostHog setup includes an event taxonomy designed around the decisions your team makes, 5–8 dashboards covering activation, retention, feature adoption, and revenue, a HogQL query library of 20+ annotated queries, an engineer-ready instrumentation spec, and a recorded training session. The Full Engagement adds an A/B experiment framework, a churn-risk scoring model, and session-replay triage. Everything stays in your own PostHog instance.
Should my team set up PostHog themselves or hire a consultant? +
Set it up yourself if you have a data hire with real PostHog depth and the time to own the taxonomy, dashboards, and HogQL work. Hire a specialist consultant if you want it built correctly once, on a fixed price and timeline, without adding headcount or waiting on an agency retainer. A full-service agency makes sense only when you need continuous multi-channel analytics and marketing work rather than a focused instrumentation build.

Every sprint starts with data your team trusts — not a debate about whether the numbers are right.

A short call is enough to confirm this sprint fits your situation and agree a start date.