PostHog and CodeWords: acting on product analytics

PostHog knows a great deal that nobody acts on. It knows which accounts stopped using the feature they signed up for, which users hit an error three times in a row, and which trials never reached the moment that predicts retention. All of it is visible in a dashboard somebody opens on Thursdays.

The gap is not analysis. It is that the person who could act — an account manager, a support lead, whoever owns onboarding — does not work in PostHog and will not go looking.

What we'll cover

• Why dashboards are the wrong delivery mechanism
• What the PostHog API reaches
• Connecting it to CodeWords
• Eight automations worth building
• Alerting on behaviour without crying wolf
• Building it so it survives
• Limits worth knowing about
• Frequently asked questions

Why dashboards are the wrong delivery mechanism

They require someone to look. A dashboard is a standing invitation, and the signals that matter arrive on days nobody accepted it.

They answer questions you already had. By definition, a dashboard shows what someone thought to put on it. The interesting behaviour is the thing nobody anticipated.

They are in the wrong place. The account manager works in the CRM, support works in the inbox, and the product team works in the tracker. A signal that stays in PostHog reaches none of them.

They show aggregates. "Activation is down four points" is a fact nobody can act on. "These eleven accounts signed up this week and never reached setup" is a list somebody can work through this afternoon.

That last distinction is the whole argument. The useful output of product analytics is usually a short list of specific accounts, delivered where the person who owns them already is.

What the PostHog API reaches

Query endpoints let you run analytical queries, including HogQL, which is the flexible route to arbitrary questions rather than predefined insights.

Events can be captured and read, so an automation can both write events into PostHog and read what happened.

Persons and groups can be listed, read, and updated with properties. Groups matter for anything account-based rather than user-based.

Cohorts can be listed and their members retrieved, which lets an automation act on a definition your team already agreed rather than reimplementing it.

Feature flags can be read and updated, including which users or groups are enrolled, which is the loop back into the product.

Annotations can be created, which is how you mark a deployment or a campaign on the timeline so later analysis has context.

Webhooks and actions can fire on events matching conditions, which is what allows reaction rather than polling.

The pattern worth noticing: read cohorts your team defined, act on them elsewhere, and write the result back as events or properties so the effect is measurable in the same place.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which behaviour matters, who should hear about it, and where.
3. Authorize the connection. PostHog uses project and personal API keys with different capabilities, so use a project-scoped key with the narrowest access that works.
4. Describe the exceptions: an empty cohort, a person with no matching CRM record, a query that returns more than expected.
5. Run it against a past period where you know what it should have found.

You describe the outcome; Cody builds it, connects it, and deploys it. When the question changes you describe the change. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Eight automations worth building

Activation gaps as a worklist. Accounts that signed up and have not reached the action that predicts retention, delivered as a named list to whoever owns onboarding. This is the highest-value automation here, because it converts a metric into a task.

Silent churn signals. Accounts whose usage has fallen materially against their own recent baseline, raised before the renewal conversation rather than during it. Compare each account against itself rather than against an average, since a busy account halving matters more than a quiet one going quiet.

Error clustering with user impact. Group errors by type and report them ordered by how many distinct users hit them, not by how often they occurred. One user retrying forty times is a different problem from forty users hitting it once.

Feature adoption reporting. After a release, who is using the new thing, from which segments, and who tried it once and did not return. The last group is the interesting one and the one nobody reports on.

Enrich the CRM with product usage. Write usage level, last active date, and feature adoption onto account records so the people in sales conversations know what the customer actually does.

Deployment annotations. Mark every release on the PostHog timeline automatically, so that when a metric moves, the question of what changed has an answer.

Feature flag automation. Enrol or remove accounts from flags based on behaviour or plan, so rollouts follow rules rather than someone maintaining a list.

Funnel drop alerting. When conversion between two steps falls outside its normal range, say so, with the affected segment identified rather than just the number.

Alerting on behaviour without crying wolf

Behavioural alerting fails in a specific way: it fires often enough that people stop reading, and then the one that mattered is also ignored.

Compare against the right baseline. Same hour, same weekday, over recent weeks. Product usage has a weekly rhythm, and a flat threshold generates false alarms every Monday and misses real problems every Sunday.

Use robust measures. A median and interquartile range are far less distorted by a previous incident than a mean and standard deviation, and your history certainly contains incidents.

Require persistence. A single interval outside the range is noise. Two or three consecutive intervals is a signal. This one change removes most false positives at the cost of a short delay.

Alert on absence too. Events stopping entirely usually means instrumentation broke, not that behaviour changed. A metric that has gone flat rather than moved deserves more suspicion than one that dropped.

Name the affected segment. An alert saying conversion fell is a question. An alert saying conversion fell for mobile users on the new signup flow is an investigation that has already started.

Review monthly and delete what nobody acted on. Any alert that has fired repeatedly with no action is training people to ignore the channel.

Building it so it survives

Sanity check the result before sending. A query returning zero accounts might mean nothing is wrong or might mean the query broke. Those are opposite situations and look identical to an automation checking only for problems.

Report success, not only exceptions. A brief daily confirmation that checks ran makes silence meaningful.

Keep identity consistent. PostHog's distinct ID, your CRM's account ID, and your database's user ID are three different things. Decide the mapping explicitly, because an automation that guesses will enrich the wrong records.

Log the query. When somebody disputes a number, you want the exact query that produced it.

Write results back as events. Recording that an automation acted, as an event in PostHog, means you can later measure whether acting helped, which is the only way to know if any of this was worth building.

Limits worth knowing about

Query cost and rate limits apply, particularly on self-hosted instances where a heavy analytical query competes with ingestion. Schedule expensive queries outside peak.

Event data has a retention window that varies by plan and configuration. An automation asking about behaviour from a year ago may be asking about data that no longer exists.

Person profiles and events are billed differently on cloud plans, and an automation that creates many person records has a cost implication worth knowing before it runs at volume.

Cohort membership is calculated periodically rather than continuously for some cohort types, so an automation reading a cohort immediately after an event may not see the change yet.

Self-hosted and cloud differ in available endpoints and performance characteristics, so check against the deployment you actually run.

Frequently asked questions

Why not just use PostHog's own alerts and subscriptions?

Use them where they fit — scheduled insight subscriptions and simple threshold alerts are native and require nothing extra. Reach outside when the alert needs to become an action in another system, when the logic needs data PostHog does not hold, or when you want a named list of accounts rather than a chart.

How do I turn a metric into something someone can act on?

Deliver the list, not the number. "Activation is down" is a fact; "these eleven accounts signed up this week and have not completed setup" is a morning's work for somebody. The translation from aggregate to list is most of the value in automating analytics at all.

Can an automation change feature flags?

Yes, and it is one of the better uses here, because it closes the loop between what you observe and what the product does. Enrolling accounts by behaviour or plan removes a manual list somebody was maintaining. Be conservative about automated removal, since pulling a feature from someone mid-use is a poor experience.

How do I connect PostHog identities to our CRM?

Decide the mapping deliberately rather than inferring it. Email is common and unreliable; an account or organization identifier written into PostHog's group properties at signup is far better. Doing this early costs nothing and retrofitting it is genuinely painful.

What is the best first automation?

The activation worklist. It is a single query, the output is immediately actionable, the person receiving it can tell you within a week whether it is useful, and you will learn quickly whether your identity mapping is right.

How do I know whether acting on these signals worked?

Write the action back as an event, then measure the difference between accounts that were acted on and comparable accounts that were not. Without that, you have a process that generates activity and no evidence it changes outcomes, which is a comfortable place to stay for a long time.

Will this work with a self-hosted instance?

Yes, with the caveat that query load competes with ingestion on your own infrastructure. Schedule heavy analytical work outside peak hours and watch the effect, which is a consideration cloud users do not have.

How do I avoid alerting on something that is just seasonal?

Compare against the same hour of the same weekday over recent weeks rather than against a flat average, and require the deviation to persist across two or three intervals before firing. Most false alarms in product analytics come from comparing a Monday to a Sunday.

What identity should the automation use?

Whatever your CRM and your database agree on, written into PostHog as a group property at signup rather than inferred later. Email is the tempting choice and the unreliable one, since people change addresses and share them, and retrofitting a proper identifier across historical data is genuinely painful.

Can I use this to decide what to build?

It informs the decision rather than making it. Feature adoption, the accounts that tried something once and never returned, and the questions people ask support are all inputs. The judgement about what that means is exactly the part worth keeping with a person.

What to build first

Start with the activation worklist. It converts a metric into a list somebody can work through, the person receiving it will tell you within a week whether it is useful, and it exposes immediately whether your identity mapping is right.

Two things make the difference between a first automation that sticks and one that gets abandoned. Run it alongside whatever happens now for a cycle or two and compare the outputs, since the differences are nearly always genuine discoveries rather than bugs. And have it report that it ran even when it found nothing, because an automation whose only output is silence is one nobody can distinguish from a broken one.

Related reading

• BigQuery and CodeWords
• CodeWords integrations and templates