Event KPI Signals
Understand Prevenue's account-level Event KPI analytics and how to use them in account investigation, filters, saved lists, and Funnel eligibility.
Event KPI Signals turn sparse account-scoped events into account-level analytics. They are designed for product, lifecycle, support, and revenue teams that want to understand whether usage is healthy, blocked, expanding, or showing negative intent without collecting noisy clickstream data.
What to track
Start with a small allowlist of high-signal events. Useful events usually describe value, friction, activation, expansion intent, checkout, downgrade or cancel intent, support friction, or integration progress.
Prevenue does not need every page view, hover, modal open, or generic button click. A few well-named events with stable account identity are more useful than a large volume of low-context events.
Good first events include:
| Event family | Examples |
|---|---|
| High-value usage | feature_used, workflow_completed, report_exported, api_credits_used, generation_completed, sync_completed |
| Activation | account_activated, first_value_completed, onboarding_completed |
| Limit friction | limit_hit, quota_blocked, overage_prompt_viewed |
| Product friction | sync_failed, setup_failed, support_needed |
| Expansion intent | pricing_viewed, upgrade_clicked, checkout_started |
| Billing lifecycle | subscription_updated, invoice.payment_failed, payment_succeeded, plan_changed |
| Downgrade or cancel intent | downgrade_flow_started, cancel_flow_started |
| Team expansion | team_member_invited, seat_added, role_assigned |
| Integration connected | integration_connected, oauth_connected, destination_configured |
Sentiment fields
Sentiment is optional and separate from the event family. Missing sentiment is stored as unknown, not neutral. Use neutral only when the event explicitly carries neutral sentiment.
Prevenue can also apply a mapped sentiment default for an event name. Explicit payload sentiment always wins. If an event arrives with omitted or unknown sentiment, a confirmed or auto-applied mapping can fill sentiment, score, confidence, and source. If the mapping sentiment is ignored or unknown, the event remains unknown.
| Field | Values |
|---|---|
sentiment | positive, neutral, negative, unknown |
sentiment_score | Number from -1 to 1 |
sentiment_confidence | Number from 0 to 1 |
sentiment_source | explicit, inferred, ai, integration, unknown |
Send bounded sentiment labels, scores, confidence, and source. Do not send free-text feedback, support transcripts, survey comments, chat messages, notes, prompts, or raw customer descriptions as sentiment context.
sentiment_source describes where the sentiment came from:
| Source | Meaning |
|---|---|
explicit | Sent directly on the event payload. Preserved during mapping propagation by default. |
inferred | Deterministic mapping default from event name, kind, semantic type, or bounded properties. |
ai | AI-suggested mapping default accepted through review. |
integration | Supplied by an upstream integration. |
unknown | No known sentiment source. |
{
"account_id": "acct_123",
"event_name": "usage_limit_hit",
"timestamp": "2026-06-20T15:00:00.000Z",
"semantic_type": "limit_friction",
"sentiment": "negative",
"sentiment_score": -0.8,
"sentiment_confidence": 0.9,
"sentiment_source": "explicit",
"properties": {
"limit_name": "monthly_events",
"usage_ratio": 0.93
}
}KPI definitions
| KPI | Field | Meaning |
|---|---|---|
| Sentiment score | event_sentiment_score_avg_7d, event_sentiment_score_avg_14d, event_sentiment_score_avg_30d | Average known sentiment score across account events in the trailing window. Negative values indicate friction or risk; positive values indicate healthy intent. |
| Usage quality | event_sentiment_weighted_usage_score_30d | Sentiment weighted by usage volume or usage pressure. This helps distinguish happy usage from grudging dependency. |
| Friction load | event_friction_load_30d | Friction events divided by value events. Higher values indicate more blockers relative to useful activity. |
| Expansion surface | event_expansion_surface_area_30d | Count of independent expansion paths, such as upgrade intent, top-ups, team expansion, integrations, usage pressure, or positive usage. |
| Revenue sentiment | event_revenue_sentiment_divergence_score_30d | Directional mismatch between revenue behavior and sentiment. Useful for finding accounts that pay or use heavily while sentiment worsens. |
| Momentum quality | event_account_momentum_quality_score_30d | Composite score combining usage, activation, expansion, sentiment, and friction into a directional account momentum signal. |
| Evidence band | event_kpi_evidence_band_30d | Confidence band for the KPI evidence: usable, directional, thin, or unavailable. |
| KPI sample size | event_kpi_sample_size_30d | Number of source events supporting the 30 day KPI context. |
| Known sentiment | event_sentiment_known_count_30d | Count of 30 day events with explicit or inferred known sentiment. |
| Negative sentiment | event_sentiment_negative_count_30d | Count of 30 day events carrying negative sentiment. |
| Unknown sentiment | event_sentiment_unknown_count_30d | Count of 30 day events without known sentiment. |
Treat these KPIs as account-level directional analytics. They help teams decide where to inspect, route, or automate, but they should still be read with sample size and evidence band.
Changing mapped sentiment on the Events page can update matching historical events and then refresh Event KPI evidence. By default, this preserves rows where sentiment_source = explicit; use overwrite only when a human intentionally wants the mapping to replace explicit event sentiment.
Evidence bands
Event KPIs use evidence bands so low-volume accounts are not over-classified.
| Band | Interpretation |
|---|---|
usable | Enough volume and variety to support normal reporting and routing. |
directional | Enough signal to guide review, but not enough to treat as calibrated lift. |
thin | Too little event data for a strong read. Useful mainly as a setup or data coverage hint. |
unavailable | No useful event KPI evidence is available yet. |
As a rule of thumb, one or two isolated events are diagnostic. Three or more relevant account-scoped events in a 14 day window can become directional. Five or more relevant events in 30 days, especially across more than one event family, can support usable KPI confidence.
Where to use Event KPIs
In the Accounts table, Event pulse is the default summary column. It chooses the most useful compact KPI read for each account, such as negative sentiment, high friction, momentum quality, or expansion surface.
Use the column selector in the Accounts table to add raw KPI columns when you want comparison, auditing, or reporting. Raw KPI columns are off by default so the table stays readable.
Use Account filters to build segments such as:
| Segment | Example filter |
|---|---|
| Negative sentiment | Sentiment score 30d less than -0.2 |
| High friction | Friction load 30d greater than or equal to 0.35 |
| Expansion interest | Expansion surface 30d greater than or equal to 2 |
| Usable KPI evidence | Event KPI evidence band 30d equals usable |
| Low sentiment coverage | Unknown sentiment count 30d greater than 5 |
Saved account lists can use the same filters. Funnels can then enroll from current saved-list membership, which keeps eligibility tied to the latest refreshed account segment.
Instrumentation guidance
Prefer backend or integration sources for durable state changes such as billing updates, checkout completion, metered usage, OAuth completion, or persisted setup milestones. Use the Web SDK for browser-visible intent, prompts, and supplemental friction that the backend cannot see.
Keep event properties bounded and structured. Good properties include plan, current_plan, target_plan, feature, quantity, value, usage_ratio, allowance, integration, provider, reason_code, sentiment, sentiment_score, sentiment_confidence, and sentiment_source.
Do not send secrets, tokens, cookies, authorization headers, raw URLs with query strings, free-text feedback, support transcripts, stack traces, logs, prompts, or full request or response bodies.
For implementation details, see Direct API Installation for backend source-of-truth events and Web SDK Installation for browser-safe supplemental events.