# 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](/docs/getting-started.html) 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](/docs/integrations.html) 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

1. In **Configure → Data Sources**, add PostHog and select the intended project
   or environment. Synchronize and inspect historical coverage and freshness.
2. Add Stripe, confirm the account and data settings, then synchronize it.
   Investigate partial failures before comparing either source.
3. Use workspace search (⌘K or Ctrl+K) to open **Reports**. Select **Weekly
   digest**, then **Create** to prepare a readout from the connected signals.
4. 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.
5. 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](/tractionscout/demo) to explore real,
privacy-preserving aggregate traffic from TractionScout.com. The
[synthetic product walkthroughs](/#product) 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](/workflows/agent-cli-automation.html).


## Setup guides

- [Set up your project](https://tractionscout.com/docs/getting-started.html)
- [Connect PostHog and Stripe](https://tractionscout.com/docs/integrations.html)

## Start with this question

Which growth bottleneck deserves attention this week?

[Prepare my weekly readout](https://tractionscout.com/signup/tractionscout?workflow=posthog-stripe-readout)

Your workflow is carried into setup. Review the project, sources, and request before starting a run.

## Related workflows

- [Turn search demand into a content experiment](https://tractionscout.com/workflows/search-console-content-experiment.md): Use Search Console queries and landing pages to prepare a content hypothesis, a reviewable change, and a measurement plan.
- [Prepare growth work from an external agent](https://tractionscout.com/workflows/agent-cli-automation.md): Use the Agent CLI or MCP to inspect project capabilities and stage evidence-backed work inside the project's approval policy.