Data Quality Checks
Find and fix product-event issues before they turn into noisy signals.
Data quality checks help you identify event, identity, mapping, and source problems that reduce signal quality.
Use Events to inspect recent rows, rejection reasons, payload JSON, mapping status, sentiment, account facts, and diagnostic state. Use Setup, Revenue Signal Scan, and Insights/Prediction Readiness to see whether source fixes improved readiness.
Common issue types
| Issue | Why it matters | Fix |
|---|---|---|
| Missing account identity | Events cannot attach to account intelligence or signals. | Add stable account/workspace/customer identity at the source. |
| Too many diagnostic events | Setup tests or system events crowd out customer behavior. | Filter provider system events before they reach Prevenue or ignore them in mappings. |
| Unconfirmed mappings | Readiness cannot trust the event's revenue meaning. | Confirm or correct mappings. |
| Rejected events | Payload shape or safety checks failed. | Inspect the rejection reason and fix the sender. |
| Duplicates | Repeated events can inflate evidence. | Send stable event IDs or idempotency keys. |
| Sparse evidence | There are too few events for reliable account context. | Add a small high-signal event allowlist. |
| Missing account facts | Signup date, login activity, trial state, or active-user counts are not present. | Send standard SaaS account traits from product sources and connect Stripe for billing/trial truth. |
| Unsafe properties | Payloads include sensitive or unbounded data. | Remove unsafe fields before sending events. |
Product-event quality rules
Good events are:
- Account-scoped.
- Stable in name and meaning.
- Sparse and meaningful.
- Structured with bounded properties.
- Safe to store and review.
- Connected to a revenue motion.
Weak events are:
- Generic clicks with no meaning.
- Page views without account identity.
- Diagnostic provider tests.
- Repeated events without idempotency.
- Free-text or raw logs.
- Events that mix several actions into one name.
Fix order
- Fix missing account identity.
- Stop unsafe fields at the source.
- Reduce diagnostic noise.
- Confirm mappings for high-signal events.
- Fill standard account facts: customer signup date, login events, plan/status, trial state, active-user counts, user counts, and seat counts.
- Add missing event families from the Setup event plan.
- Re-run the Revenue Signal Scan.
- Review signal evidence before enabling routing.
This order prevents rule tuning from masking source data problems.
Data quality and prediction readiness
Prediction readiness uses data quality signals to explain reliability gaps. For example, low mapping coverage, missing Stripe match, thin event volume, or sparse outcome history can reduce prediction usefulness.
Use data quality checks to fix the source issue, then use Intelligence Learning Evidence to verify the impact.