Writing: essays and notes on product engineering

Long-form writing by Sangeet Banerjee on realtime systems, infrastructure UX, growth engineering, and software craft.

Back to Sangeet Banerjee homepage

What PostHog was actually for

By Sangeet Banerjee. Published 2025-11-03. 2 min read.

Instrumenting Huddle Meet and friends without turning every button into a marketing experiment.

Tags: analytics, product, growth

All writing

What PostHog was actually for: article facts

Title
What PostHog was actually for
Author
Sangeet Banerjee
Published
November 3, 2025
Updated
November 3, 2025
Reading time
2 min read
Summary
Instrumenting Huddle Meet and friends without turning every button into a marketing experiment.
URL
https://sangeet.xyz/blogs/what-posthog-was-actually-for
Tags
analytics, product, growth
Excerpt
I wired PostHog into meeting and product surfaces mainly to answer boring questions: which controls people use, where they stall, whether a redesign moved the needle. Not to A/B test button colors for sport. What we needed - Did people find mic / cam / share - Which permission / settings screens got opened - Funnel scraps: join intent → actually in a call with media - Feature flags for gradual rollouts without a full release train That is product analytics for engineers on call for UX, not a growth team dashboard with vanity charts. What “good enough” instrumentation looks like Past-tense event names. Properties without people’s names. One owner so mictoggled does not become five spellings. Track: - Successful actions (muted, shared screen) - Failures that matter (permission denied, device missing) - Rare but costly paths (host leave while alone as sole host, if you can detect it) Skip: - Every hover - Full recording of customer content - Events that only exist to make a weekly report look busy Flags vs forever experiments I like flags for redesign slices and risky controls. I dislike flags that stay in the codebase for a year with no expiry. If nobody looks at an event for a quart…
All posts
2 min read

What PostHog was actually for

instrumenting Huddle Meet and friends without turning every button into a marketing experiment.

analyticsproductgrowth

I wired PostHog into meeting and product surfaces mainly to answer boring questions: which controls people use, where they stall, whether a redesign moved the needle. Not to A/B test button colors for sport.

What we needed

  • Did people find mic / cam / share
  • Which permission / settings screens got opened
  • Funnel scraps: join intent → actually in a call with media
  • Feature flags for gradual rollouts without a full release train

That is product analytics for engineers on call for UX, not a growth team dashboard with vanity charts.

What “good enough” instrumentation looks like

Past-tense event names. Properties without people’s names. One owner so mic_toggled does not become five spellings.

Track:

  • Successful actions (muted, shared screen)
  • Failures that matter (permission denied, device missing)
  • Rare but costly paths (host leave while alone as sole host, if you can detect it)

Skip:

  • Every hover
  • Full recording of customer content
  • Events that only exist to make a weekly report look busy

Flags vs forever experiments

I like flags for redesign slices and risky controls. I dislike flags that stay in the codebase for a year with no expiry.

If nobody looks at an event for a quarter, delete it or stop sending it. Dead events cost attention.

Where this sits next to “growth”

You can still care about activation. On a meeting product, activation is closer to “joined and could hear someone” than “signed up.”

PostHog helped us see if redesigned chrome buried mute. It also showed that “small” host tools (quality readouts, network graph, fine controls) were not ignored. People opened them and used them. Without events we would have kept calling those extras forever.

What I would set up in week one

  1. Tiny event registry in the repo
  2. Join / media / leave events with versions
  3. Events on the “little” host tools you are tempted to skip
  4. One dashboard: funnel + top errors, not fifty charts
  5. Flag hygiene: name, owner, kill date

Analytics that delay first frame are a bug. Measure after the call is usable.