How to Audit Your Event Data in One Afternoon (Free Checklist)

Most lifecycle teams know their event data has problems. Few have run a structured audit to find out which ones. The audit is shorter than people expect — one focused afternoon, the right access, and a willingness to run a few queries against the warehouse and the CDP. The output is a prioritized fix list that tells you what to fix first, what to fix later, and what is already working. The audit pays for itself the first week after you act on it.

TL;DR

• The full audit takes 3-4 hours if you have warehouse, CDP, and Customer.io access.
• The output is a fix list with three buckets: configuration fixes (this week), schema additions (this month), architecture changes (this quarter).
• Run the audit once a quarter. Drift accumulates faster than teams notice.
• The five-step process below is the one we run on every engagement before recommending any other work.

Before you start: access checklist

You need:

• Read access to the data warehouse (Snowflake, BigQuery, Redshift)
• Admin access to the CDP (Segment, Rudderstack, or Customer.io Data Pipelines)
• Admin access to Customer.io
• The current tracking plan, if one exists
• The list of campaigns that the lifecycle team considers important

If any of these are missing, get them before starting. The audit's value drops sharply if you have to estimate instead of query.

Step 1: Pull the top 20 events by volume (45 minutes)

In your warehouse, query the events table for the last 30 days. Group by event name. Order by count descending. The top 20 are the events the lifecycle program is mostly running on, whether anyone planned it that way or not.

For each event, note three things: total volume, unique users, and whether the volume is stable over the period. Sudden drops mean broken instrumentation. Gradual drops can be either real usage decline or schema drift.

Step 2: For each top event, check property completeness (45 minutes)

For each of the 20, run a query that checks how often each property is present. The most important properties to check are the 12 base properties plus whatever event-specific properties matter for triggering.

Any property that is present on less than 95% of events is broken. Customer.io cannot reliably trigger on a property that is missing 10% of the time. Note every gap.

Step 3: Trace events through the pipeline (45 minutes)

For three or four representative events, trace them end to end. Pick events that are critical to important campaigns.

The trace: find a recent event in the warehouse for a known user; find the same event in the CDP debugger; find the same user's profile in Customer.io; verify the event triggered the campaign that should have triggered.

This step finds three classes of problems. Volume drops between source and CDP mean the SDK is dropping events. Volume drops between CDP and Customer.io mean a destination filter is excluding them. Properties present in CDP but missing in Customer.io mean the destination is configured to drop them.

Step 4: Check for missing events (30 minutes)

Walk through the customer journey with the lifecycle team. For each major moment — onboarding step completion, activation milestone, expansion signal, churn risk — check whether an event captures it.

Common missing events in PLG SaaS:

• Specific feature activation moments (most teams track signup but not the moment the user actually activates)
• Account-level events (workspace created, second user invited, first integration connected)
• Engagement decay signals (last meaningful action, days since last login)
• Billing-adjacent events (plan downgrade, payment failure, seat reduction)

Each missing event becomes a "should exist but doesn't" entry in the fix list.

Step 5: Cross-reference with Customer.io campaigns (30 minutes)

In Customer.io, list the top 20 active campaigns. For each, identify which event triggers it. Cross-reference against your top-20 events list and your missing-events list.

Three patterns to look for:

• High-volume events with no campaign attached. These are unused signal. Either build campaigns for them or accept the volume is wasted.
• Campaigns triggered by events with property gaps from Step 2. These are campaigns running on partial data. They will underperform; the cause is upstream.
• Campaigns the lifecycle team wants to build but cannot because the event does not exist. These are the highest-priority entries in the missing-events list.

If you are using AI Decisioning, also check: which attributes are feeding the model, and are any of them stale or missing more than 5% of the time? Stale attributes degrade decisions silently.

The output: a three-bucket fix list

After running the five steps, organize what you found into three buckets:

Bucket 1: Configuration fixes (this week). Destination filters dropping events; reverse ETL syncs that are broken or slow; identify calls firing on the wrong ID.

Bucket 2: Schema additions (this month). Missing properties on existing events; missing events for important moments; tracking plan documentation.

Bucket 3: Architecture changes (this quarter). Identity resolution model; warehouse-first migration if currently CDP-first; schema redesign for analytics-first events.

The buckets are sequenced by reversibility. Bucket 1 is fastest and lowest risk. Bucket 3 takes a quarter and requires cross-team alignment.

What to do next

Run the audit. The five steps take 3-4 hours total. The output is the most honest assessment of your data layer that anyone on the team has had access to.

Key takeaways

• The audit is five steps and takes one afternoon.
• The fix list breaks into configuration, schema, and architecture buckets.
• Run quarterly. Drift accumulates.
• The audit pays for itself the first week of acting on it.

‍