Event Log and Payload Review

Inspect event rows, payload JSON, diagnostics, mappings, account context, and source health in Events.

The Event Log lives in Events. Use it to confirm that Prevenue is receiving useful account-scoped customer events, not only setup tests or provider diagnostics. It is also the first place to look when a source appears connected but signals, mappings, or account intelligence are missing.

The table combines two kinds of rows:

Normalized customer events from normalized_events.
Raw intake rows from raw_ingest_events when the event is rejected, duplicated, pending, or diagnostic.

Customer rows can support mappings, signal readiness, Event KPIs, account facts, and signal evidence. Diagnostic rows help debug setup and source health, but they do not improve readiness by themselves.

What the Event Log shows

The default table keeps the most important fields visible. Use the column selector when you need source, value, or diagnostic details.

Column group	Fields
Core	Time, state, event name, mapping, sentiment, account, user, status, and summary.
Source	Source, source event ID, event kind, intake, log type, and URL or source context.
Value	Value, amount, currency, and billing signal type.
Diagnostics	Rejection reason, properties summary, and payload summary.

Click a row to open the event detail drawer. The drawer shows mapping controls, matched record fields, account facts when available, evidence usage when the row has already supported a signal, and the compact Payload JSON review object.

Row states

State	Meaning
Customer	A normalized customer event that can support mappings, readiness, Event KPIs, account facts, and signals.
Rejected	A raw customer event that failed validation, safety checks, or revenue relevance checks.
Duplicate	A raw intake row with the same logical event ID or idempotency key as a previously accepted event.
Ignored	A known provider/system/setup row, such as a PostHog `$pageview`, that is useful for setup debugging but not customer evidence.
Diagnostic	A raw row that is pending, setup-only, or otherwise useful for debugging source health.

Customer events are the rows that matter most for signal quality.

Payload examples

The payload you send to Prevenue and the Payload JSON you review in the drawer are related but not identical. Prevenue normalizes, redacts, and summarizes the source payload before it is shown in the app.

A Direct API event might be sent like this:

{
  "event_id": "evt_direct_001",
  "event_name": "usage_limit_hit",
  "account_id": "acct_123",
  "user_id": "user_456",
  "timestamp": "2026-06-20T15:00:00.000Z",
  "semantic_type": "limit_friction",
  "event_kind": "friction_event",
  "sentiment": "negative",
  "sentiment_score": -0.8,
  "sentiment_confidence": 0.9,
  "sentiment_source": "explicit",
  "value": 1,
  "properties": {
    "plan": "starter",
    "limit_name": "monthly_events",
    "usage_ratio": 0.93
  }
}

After normalization, the event drawer shows a compact review object like this:

{
  "account": "acct_123",
  "category": "limit_friction",
  "event": "usage_limit_hit",
  "eventKind": "friction_event",
  "id": "normalized-event-id",
  "occurredAt": "2026-06-20T15:00:00.000Z",
  "properties": {
    "plan": "starter",
    "limit_name": "monthly_events",
    "usage_ratio": 0.93
  },
  "sentiment": "negative",
  "sentimentConfidence": 0.9,
  "sentimentScore": -0.8,
  "sentimentSource": "explicit",
  "source": "direct",
  "sourceEventId": "evt_direct_001",
  "user": "user_456",
  "value": 1
}

A rejected or diagnostic raw row keeps more of the redacted source wrapper so you can find the sender problem:

{
  "event": "pricing_page_viewed",
  "eventKind": "rejected",
  "id": "raw:raw-ingest-id",
  "occurredAt": "2026-06-20T15:00:00.000Z",
  "payload": {
    "event": {
      "event": "pricing_page_viewed",
      "properties": {
        "distinct_id": "user_456",
        "$current_url": {
          "host": "app.example.com",
          "path": "/pricing"
        }
      }
    }
  },
  "properties": {
    "distinct_id": "user_456"
  },
  "source": "posthog",
  "sourceEventId": "ph_evt_001",
  "user": "user_456"
}

For rejected rows, check the State, Rejection reason, Log type, and Payload summary columns alongside the drawer JSON. The rejection reason explains what to fix at the sender.

How fields normalize

Review field	Common source fields
Event name	`event_name`, `event`, `name`, or provider-specific event type.
Account	`account_id`, `groupId`, `properties.account_id`, `properties.group_id`, `properties.company_id`, or provider group/workspace identity.
User	`user_id`, `userId`, `anonymousId`, `distinct_id`, or provider identity fields.
Timestamp	`timestamp`, `sentAt`, `occurred_at`, or provider-created timestamp.
Source event ID	`event_id`, `id`, `messageId`, `uuid`, or provider event ID.
Category	Explicit `semantic_type` or inferred/mapped semantic family.
Sentiment	Explicit sentiment fields or a confirmed mapping default when explicit sentiment is omitted or `unknown`.
Value	`value`, `properties.value`, `properties.amount`, `properties.quantity`, or Stripe amount fields.
Source context	Sanitized URL path/referrer or bounded `source_context` property.
Properties	Redacted, bounded structured context after unsafe raw navigation fields are removed or sanitized.

Workspace trust is resolved from credentials or source connections. Do not treat workspace_id in a client payload as the security boundary.

Payload review checklist

When inspecting a row, confirm:

event_name is stable and meaningful.
source matches the provider you expect.
account_id, groupId, group_id, customer_id, workspace/account identity, or equivalent account identity is present.
user_id, anonymousId, or provider identity is present only when useful.
sourceEventId is stable for retries, dedupe, and source debugging.
timestamp is the actual event time.
Category and sentiment are correct for the customer meaning of the event.
Numeric value, amount, currency, and billing semantics are clear when present.
Properties are structured and bounded.
The payload does not include secrets, raw text, cookies, auth headers, full URLs with query strings, logs, or transcripts.

For account intelligence, also check whether Account facts are available in the drawer. Missing signup date, login cadence, plan/status, trial state, active users, user count, or seat count can reduce signal quality even when the event itself is accepted.

Filtering the log

Use search, filters, saved lists, and the column selector to narrow investigations. Useful filters include category, mapping status, sentiment, state, source, event name, account, user, date, value, property text, and saved list.

Save repeated investigations as an event saved list. For example, create a list for rejected PostHog events, unmapped Stripe events, or checkout events missing account identity.

What to do after review

If the row is valid and meaningful, use the Mapping control in the Events table or event drawer to confirm the category and sentiment.

If the row is rejected, fix the sender payload before tuning signals.

If the row is diagnostic-only, either filter it at the source or leave it ignored so it cannot improve readiness by accident.

If the row contains unsafe data, remove that field at the source and rotate any exposed credential if a secret was sent.

Event Log and Payload Review

On this page