Revenue Signal Scan
Run the first scan, interpret the results, and use the gaps to finish setup.
The Revenue Signal Scan checks whether a workspace has enough connected data to produce reviewable revenue signals. It is the fastest way to see what Prevenue can already evaluate and what still needs setup.
You can run the scan from Setup or the app home.
The first scan is most useful after at least one of the core setup paths has produced account-scoped activity:
- Stripe is connected or ready to verify billing events.
- The Web SDK has sent a browser event with
prevenue.group(accountId, traits)oraccount_id. - Direct API has accepted one backend event with
account_id.
What the scan checks
The scan reviews:
- Connected sources and recent activity.
- Account identity coverage.
- Confirmed event mappings.
- Signal readiness by requested motion.
- Prediction-readiness gaps.
- Destination coverage when routing is part of the workflow.
- Existing account intelligence and signal evidence.
The scan is meant to guide setup. It is normal for the first scan to return gaps instead of live signals.
When to run it
Run a scan:
- After connecting Stripe.
- After installing the Web SDK and sending a browser event with account identity.
- After creating a Direct API key and sending a backend event with account identity.
- After confirming or updating mappings.
- After another source changes account context.
- After fixing rejected events or identity issues.
- Before enabling a Funnel destination or learned eligibility rule.
- When the app shows stale or missing prediction-readiness information.
Reading the result
| Result | What it means | Next step |
|---|---|---|
| No readiness snapshot | Prevenue has not evaluated the workspace yet. | Run the scan. |
| Blocked | Required identity, events, mappings, or setup are missing. | Fix the highest-impact gap first. |
| Partial | Some evidence exists, but the signal family is not ready yet. | Confirm mappings and send more qualifying events. |
| Waiting | Setup is mostly complete, but Prevenue needs more recent evidence. | Continue sending events and re-run the scan later. |
| Ready to preview | Evidence is strong enough to review sample signals. | Open Signals and inspect detail pages. |
| Active | The workflow has enough setup evidence to operate. | Review routing and destination setup. |
Fixing common scan gaps
If identity is missing, update the source so events include a stable account, workspace, tenant, company, or customer ID.
If mappings are missing, open Events, review suggestions in the Mapping column, and confirm the right semantic types.
If product events are missing, install the Web SDK for browser-visible intent and use Direct API for durable backend events. If PostHog or Segment already contains clean account-scoped product events, forward a small allowlist from that existing pipeline.
If billing context is missing, connect Stripe and confirm customer metadata can attach billing events to accounts. Use Direct API for billing only when the product backend is the billing source of truth.
If a destination is missing, connect Slack or a webhook only after the signal evidence is useful.
How to verify improvement
After fixing a gap:
- Send or wait for new source activity.
- Confirm rows appear in
Events. - Confirm mappings from the Events table or event drawer.
- Run the scan again.
- Open
Signalsand inspect the newest signal detail page.
Do not tune learned Funnel thresholds before the scan shows that the underlying data is usable. Better event quality almost always improves signal quality more than more rule complexity.