Understand activation and revenue together
A signup increase is encouraging, but it does not tell you whether more people reach your product's useful moment or become paying customers. This workflow puts product and payment observations beside each other so you can choose a specific follow-up with the evidence and its limits visible.
Before you start
- Create a project with its website, audience, and primary outcome. Use the getting-started guide to review that context.
- Have a PostHog project with a defined activation event and a scoped personal API key with the read permissions shown in the connector setup panel.
- Have a restricted Stripe read key for the intended account. A webhook signing secret is optional for live inbound events.
- Agree on the reporting period, timezone, event definition, and eligible population. Record whether the two sources can be joined reliably.
Check connection availability and permissions in your deployment. Read access is sufficient for this readout. Keep the project's configured privacy settings: Stripe evidence can use coarse value tiers when collecting exact revenue is unsuitable.
Connect evidence and prepare the readout
- In Configure → Data Sources, add PostHog and select the intended project or environment. Synchronize and inspect historical coverage and freshness.
- Add Stripe, confirm the account and data settings, then synchronize it. Investigate partial failures before comparing either source.
- Use workspace search (⌘K or Ctrl+K) to open Reports. Select Weekly digest, then Create to prepare a readout from the connected signals.
- Ask Scout to compare activation movement with checkout, payment, and subscription observations for the same completed periods. Request source references, denominators, timezone, freshness, missing observations, and one proposed follow-up. Separate facts from hypotheses.
- Review the output and any staged action. Give an experiment a primary metric, audience, guardrails, and observation window before execution.
Worked example: more signups, fewer activations
The following numbers are synthetic teaching data, not a customer result or a forecast. Suppose the same PostHog activation definition and seven-day window were applied to two fully observed signup cohorts:
| Observation | Earlier cohort | Later cohort |
|---|---|---|
| Eligible signups | 200 | 240 |
| Users reaching the activation event | 80 | 72 |
| Activation rate | 40% | 30% |
Separately, Stripe records 18 and 17 new subscriptions in the corresponding calendar reporting periods. That count is useful context, but it is not a signup-to-paid conversion rate: a subscription may belong to a user who signed up earlier. Without a validated identity and cohort join, do not divide those Stripe counts by the PostHog signup counts or claim causation.
The defensible observation is that a larger signup cohort produced fewer activated users under the stated definition. A useful next question is where those users stopped. A reviewable follow-up could inspect the setup step and prepare a clearer first-run instruction for the affected audience. The evidence does not yet show that changing that instruction will increase revenue.
What a useful first result contains
Keep a report that explains what moved, the source behind each observation, which evidence is incomplete, and why one follow-up deserves attention. Include the proposed change and its measurement plan so another person can review the reasoning. Avoid summing mixed currencies or putting customer identities into the report.
For the example, measure the same activation event over equally mature cohorts. Record acquisition mix and concurrent product changes, and use an appropriate experiment design if you want a causal conclusion. Revenue can remain a secondary observation until the cohort join and observation period support it.
Continue with the right next step
View the read-only analytics demo to explore real, privacy-preserving aggregate traffic from TractionScout.com. The synthetic product walkthroughs show the broader growth workspace. When you have source access, the setup action below carries this weekly-readout question into onboarding. You can review it before starting an agent run. For repeated preparation from a coding agent or script, follow the Agent CLI workflow.