How to Automate Product Usage Reports with PostHog
Somewhere in most product teams, there's a person who pulls the same PostHog report every Monday. Active users, which features got used, who churned, what converted. It takes an hour, sometimes more, and by Wednesday half the team has already forgotten it exists.
That report doesn't need a person. It needs a schedule and a destination. PostHog already tracks every event that feeds a usage report. The missing piece is a workflow that pulls it, formats it, and delivers it somewhere people will actually see it, without anyone opening a dashboard first.
This guide covers what a recurring usage report should actually include, and a step-by-step process for automating it.
Why Manual Usage Reporting Doesn't Scale
A usage report built by hand has three problems, and they all get worse as a product grows.
It depends on someone remembering to run it, which means it's the first thing to slip during a busy sprint.
It's usually a snapshot, not a trend, so nobody notices a slow decline in feature adoption until it's already a pattern.
It gets built for one audience (usually the person who made it) and rarely reaches the people who'd act on it, like a sales team that could use adoption data during renewal conversations.
PostHog's event model already solves the data problem. Every action, a signup, a feature click, a plan upgrade, is captured as a structured event with properties attached, which is exactly what a trend-based report needs instead of a one-time export. The gap is entirely in distribution: getting that data out of PostHog and into a recurring, shareable format without someone doing it by hand every week.
What a Usage Report Should Actually Track
Not every metric belongs in a recurring report. A useful one narrows down to a handful of numbers that actually change behavior when they move.
Metric | What it measures | Why it belongs in a recurring report |
|---|---|---|
Active users (DAU/WAU/MAU) | How many distinct users triggered an event in a given window | Shows overall engagement direction, not just signups |
Feature adoption | Share of active users who used a specific feature | Flags features nobody found, before a roadmap decision is made on guesswork |
Retention | Percentage of users still active N days after first use | Reveals whether growth is real or just replacing churned users |
Conversion | Users who completed a defined event, like a paid upgrade | Connects usage patterns directly to revenue outcomes |
Reporting on all four together, on a recurring basis, is what turns raw event volume into something a product or growth team can actually plan around.
What You Can Automate Around PostHog Reporting
Once a report is treated as a scheduled output instead of a manual task, the pieces fall into a fairly small set of triggers and actions:
A scheduled trigger (daily, weekly, or monthly) instead of a single event trigger, since a usage report runs on a cadence rather than reacting to one action
Get events for person or list cohort members to pull the underlying activity data
Get person profile to enrich a report with who these users actually are, not just anonymous IDs
An action on the receiving end, like adding a row to a spreadsheet, posting a formatted summary to Slack, or updating a dashboard tool
The report itself doesn't have to live inside PostHog. It just needs to start there.
A Generic Step-by-Step Guide to Automating a Usage Report
The process below applies whether the report ends up in Slack, a spreadsheet, or an internal dashboard tool.
Step 1: Open a new flow
Log in to your automation platform and open your workspace. Click Create New Flow to start with a blank canvas where the schedule and the reporting action will sit side by side.
Step 2: Set your trigger
For a recurring report, the trigger is usually time-based rather than event-based. Set it to run on the cadence that matches how often the report actually needs reviewing, weekly is common for most product teams.
Click Add Trigger
Choose a scheduled trigger, or a PostHog trigger such as "new event created" if you want the report to also react to specific milestones
Set the frequency (daily, weekly, monthly)
Save the trigger
Step 3: Set your action to pull the data
Next, pull the usage data from PostHog itself.
Click Add Step
Search for PostHog and select an action like "get events for person" or "list cohort members," depending on which metric the report covers
Connect your PostHog account
Choose the project, cohort, or event type relevant to the metric
Step 4: Send the data to its destination
Add a second action step to push the pulled data somewhere people will see it.
Search for the destination app, such as Slack, Google Sheets, or Notion
Select the relevant action, like "post message" or "add row"
Map the PostHog fields, active user count, adoption percentage, retention window, into the destination's fields
Step 5: Test the flow
Run a test before publishing. Confirm the numbers in the destination match what you'd expect from PostHog directly, and that the formatting is readable at a glance, not just technically correct.
Step 6: Publish the flow
Once the test looks right, click Go Live. From here, the report generates and delivers itself on schedule, with no manual pull required.
Step 7: Monitor and adjust the cadence
Check the flow's run history occasionally to confirm it's still firing correctly. As the product grows, the metrics worth reporting on tend to shift too, so revisit which numbers are actually driving decisions every quarter or so.
Getting the Report to the Right People, Not Just a Dashboard
A report that lives only inside PostHog reaches whoever thinks to log in. A report piped into Slack or a shared sheet reaches the whole team by default, which is usually the entire point of building it in the first place.
This is also where recurring reports earn more trust than one-off exports. Consistent delivery on the same day, in the same format, makes a metric something people expect and check, rather than something they're surprised to see.
If you want to skip building the PostHog connection from scratch, viaSocket's PostHog integration has ready-made automations for pulling PostHog data into tools like Google Sheets, Slack, and HubSpot. For a look at what's technically possible on the PostHog side, like which fields each action returns, viaSocket's help documentation walks through the setup in more detail. And if reporting is just one piece of a larger workflow you're planning, viaSocket's feature overview covers what else can plug into the same flow.
FAQ
How often should a product usage report run?
Weekly works for most teams tracking active users and feature adoption. Retention and conversion trends often make more sense on a monthly cadence, since daily or weekly swings in those metrics are usually just noise.
Can I automate a report that combines PostHog data with data from another tool?
Yes. A single flow can pull from PostHog and a second source, like a billing tool for revenue data, then combine both into one report before sending it to its destination.
Do I need a data analyst to set this up?
No. Setting the schedule, choosing the PostHog action, and mapping fields to the destination tool doesn't require specialized data skills. Deciding which metrics actually matter for your product is the harder part, and that's a product judgment call, not a technical one.
What happens if the automation fails partway through?
Most automation platforms keep a run history showing exactly which step succeeded and which failed, so you can fix the mapping or reconnect an account without rebuilding the whole flow. Checking PostHog's own documentation on event properties is a good first stop if the data itself looks off rather than the automation.
