The Night the Titanic's Data System Failed

On the night of April 14, 1912, the RMS Titanic was receiving iceberg warnings — multiple of them. At least five separate warnings arrived via wireless telegraph from nearby ships throughout the day. The technology worked perfectly. The messages got through.

But the warnings never reached the bridge in a consistent, actionable format. Wireless operators like Jack Phillips were swamped with passenger messages. No standard protocol existed for classifying incoming data by urgency. One critical warning from the SS Mesabi was received and set aside without being passed to the captain.

The technology was sound. The data was available. The system for routing it was broken.

More than 1,500 people died. And the maritime world was forced to completely redesign how ships handled incoming communications — standardising distress signals, mandating 24-hour wireless operation, and creating the first International Convention for the Safety of Life at Sea (SOLAS) in 1914.

This isn't just a history lesson. It's a near-perfect analogy for what happens inside most SaaS marketing stacks today.

You have the technology. The data is flowing. But if your event schema — the system that classifies, names, and structures every user action before it hits Customer.io — is a mess, your best automations will never fire at the right time, for the right person, with the right message.

This article is about fixing that. Let's get into it.

---

What Is an Event Schema, and Why Should Marketers Care?

An event schema is the blueprint that defines what user actions you track, what you name them, and what data you attach to each one.

Every time a user does something in your product — signs up, upgrades a plan, invites a team member, hits a feature for the first time — that action can be captured as an event. Your event schema determines whether those actions arrive in Customer.io as clean, actionable signals or as an unreadable pile of noise.

Here's the thing most marketing teams don't realise: Customer.io is only as powerful as the events feeding it. The platform can't trigger a campaign on an event that doesn't exist. It can't personalise a message with a property that was never captured. It can't segment users by behaviour if that behaviour was never logged.

According to Gartner research, poor data quality costs organisations an average of $12.9 million per year. McKinsey found it leads to a 20% decrease in productivity. And while those figures cover the full enterprise data landscape, the pattern shows up at every scale — including in the marketing automation setups we audit every day at NerveCentral.

Event schema design is foundational work. Most teams skip it, or do it badly once and never revisit it. That's the gap we're going to close right now.

---

What Does a Poorly Designed Event Schema Actually Look Like?

Before we get to the good stuff, you need to recognise what broken looks like — because it rarely announces itself.

Here are the tell-tale signs:

Inconsistent naming across teams and tools

Your product team fires user_signed_up. Your growth engineer adds UserSignup. Someone else tags it new-user-registration. Three events. One action. Zero consistency.

In Customer.io, these are three completely different events. You can't build a reliable trigger off any of them without auditing every single campaign to check which name it's listening for.

Missing or unstandardised properties

Your subscription_started event fires, but half the time it includes plan_name and half the time it doesn't. Or the value format changes — sometimes "pro", sometimes "Pro Plan", sometimes "PRO_MONTHLY".

Now try building a segment of Pro plan users. Good luck.

Events that describe implementation, not behaviour

Names like button_click_v2, modal_close_event, or form_submitted_checkout_step_3_final describe what the UI does. They don't describe what the user did. This matters because marketing campaigns are about user intent, not interface mechanics.

No clear ownership

When nobody owns the event taxonomy, every developer instruments events however feels right to them in that moment. Six months in, you have 200 events in your workspace and no-one knows what half of them mean.

This is the data equivalent of the Titanic's wireless operators processing passenger messages and iceberg warnings on the same channel, with no priority system. Everything comes through. Nothing is actionable.

---

What Does a Well-Structured Event Schema Look Like?

A clean event schema has three qualities: it's predictable, it's consistent, and it's automation-ready.

Here's what that means in practice.

A clear naming convention everyone follows

The most widely adopted convention for SaaS event naming is Object-Action in snake_case:

object_actioned

Examples:

• subscription_started
• trial_converted
• feature_activated
• invoice_paid
• team_member_invited

Past tense. Lowercase. Underscores as separators. Object first, action second.

Why past tense? Because events describe things that already happened. subscription_started happened. start_subscription sounds like a command.

Why Object-Action and not Action-Object? Because it groups related events together naturally. subscription_started, subscription_paused, subscription_cancelled all live in the same mental neighbourhood. When you're scanning 50 events in Customer.io, this grouping saves real time.

As the Customer.io docs note, event names should avoid spaces and special characters — use snake_case or camelCase consistently. Pick one and enforce it. At NerveCentral, we always recommend snake_case for readability.

Rich, consistent event properties

The event name tells you what happened. The properties tell you how, where, and with what context.

Take subscription_started. A minimal version fires with just the event name. A well-designed version looks like this:

Property	Type	Example Value
plan_id	string	"pro_monthly"
plan_name	string	"Pro Monthly"
plan_price_usd	number	49.00
trial_converted	boolean	true
billing_cycle	string	"monthly"
currency	string	"USD"

Every subscription_started event should carry exactly this structure, every time. Consistent keys. Consistent data types. Consistent value formats.

Why does this matter? Because in Customer.io, you use event properties to:

• Personalise email content with Liquid ({{ event.plan_name }})
• Build segments (plan_id equals pro_monthly)
• Pass data to webhook operations
• Trigger different campaign branches based on trial_converted

If plan_name is sometimes null, sometimes "Pro", sometimes "pro" — every single one of those use cases breaks in subtle ways. Your personalisation shows blank values. Your segments miss people. Your triggers misfire.

A documented event registry

Every event should be documented: its name, when it fires, who owns it, and every property it carries. This doesn't need to be elaborate — a shared spreadsheet or Notion doc works fine. What matters is that it exists and is kept current.

This document becomes the contract between your engineering team (who fire the events) and your marketing team (who build campaigns on top of them).

---

Track Events vs Page Events: What's the Difference?

Customer.io distinguishes between two types of events at the JavaScript SDK level: track events and page events. Most marketing teams treat them interchangeably. They shouldn't.

Track events

A track call captures a specific action a user performed. It answers the question: what did this person do?

cioanalytics.track('subscription_started', {
  plan_id: 'pro_monthly',
  plan_price_usd: 49.00,
  trial_converted: true
});

Use track for anything that represents a meaningful user behaviour: purchasing, activating a feature, inviting a colleague, completing onboarding, cancelling. These are the events that power your most valuable automations.

Page events

A page call captures a pageview. It answers the question: where did this person go?

cioanalytics.page('Pricing Page', {
  url: '/pricing',
  referrer: '/blog/how-to-use-feature-x'
});

By default, Customer.io's JavaScript snippet fires page events automatically on every page load. You can use page events to trigger campaigns (e.g., someone visited /pricing three times in a week) or build URL-based segments.

Why the distinction matters in Customer.io

According to Customer.io's documentation, the key difference shows up in segmentation:

• In segments, use page conditions to filter people based on URLs they visited
• In segments, use track conditions to filter people based on named events they performed

Mixing them up causes real problems. If you instrument a track event called pricing_page_viewed instead of using a proper page call, you lose the URL-based segmentation benefits. If you rely only on page events to track meaningful product actions, you lose the rich property data that makes track events so powerful.

The simple rule: use page for where, use track for what.

---

How Upstream Data Quality Directly Impacts Downstream Campaign Performance

This is the core insight that most marketing teams don't fully grasp until it's too late.

Every Customer.io campaign is a downstream consumer of upstream event data. Your triggered welcome series, your trial-expiry campaign, your feature-adoption flow, your churn-prevention sequence — every single one of them depends on events arriving clean, complete, and on time.

When upstream data is messy, here's what breaks downstream:

Triggers misfire or never fire

If your trial_started event fires inconsistently — sometimes when a user actually starts a trial, sometimes when they just view the pricing page — your trial onboarding journey will either spam the wrong people or miss the right ones.

Personalisation shows blank or wrong values

If {{ event.plan_name }} is sometimes null, your email subject line reads "Your [blank] plan is ready" to a percentage of your audience. Nothing undermines trust like sloppy personalisation.

Segments become unreliable

If the same action is tracked under three different event names depending on which developer wrote the code that week, your behavioural segments will always be incomplete. You'll never be confident you're capturing everyone who performed that action.

Attribution breaks

If you're tracking conversion events inconsistently, you can't measure whether your campaigns actually drove the outcome. You're flying blind on ROI.

The Lifecycle Mechanics team found that fixing event schema led to a 15% increase in conversion rates within two months — purely from having accurate triggers and reliable segmentation. And Braze's benchmark data consistently shows that lifecycle emails triggered by behavioural events massively outperform broadcast campaigns across every metric.

Better upstream data → more accurate triggers → better campaign performance. Every time.

---

Real-World Example: How a SaaS Company Redesigned Their Event Schema

Let's make this concrete. Here's a composite case study drawn from the kind of audit and rebuild work NerveCentral does with clients.

The situation: A B2B SaaS company — let's call them Fieldstack — had been using Customer.io for two years. They had 47 active campaigns, dozens of segments, and a growing library of Journeys. Their marketing team was experienced and motivated.

But their open rates on triggered campaigns had plateaued. Their trial-to-paid conversion journey was underperforming compared to industry benchmarks. And their churn prevention sequences seemed to be firing for some at-risk users but not others.

When NerveCentral audited their Customer.io workspace, here's what we found:

The problems:

• 23 different event names that all referred to some version of "user completed onboarding" — with no consistency across mobile, web, and server-side implementations
• trial_started fired on 60% of new signups; the other 40% fired trial_begin (a legacy name from an old integration)
• Key events like feature_activated carried feature_name as a property on desktop but not on mobile
• Three separate events for subscription upgrades: plan_upgraded, subscription_changed, and upgrade_complete
• plan_price was stored as a string ("$49") in some events and a number (49.00) in others — making it impossible to use in numeric comparisons

The downstream impact:

• Their trial onboarding Journey was only triggering for 60% of new trials — the half that fired trial_started. The other 40% who fired trial_begin got nothing.
• Their feature-adoption campaigns couldn't fire on mobile users because the required property was missing
• Upsell campaigns couldn't reliably segment by current plan price

The rebuild:

NerveCentral worked with their engineering team over six weeks to:

1. Audit every event in the workspace and map it against intended user actions
2. Define a new event taxonomy using Object-Action naming, documented in a shared event registry
3. Standardise all properties with consistent keys, types, and value formats
4. Implement event versioning to handle the transition gracefully
5. Update every Customer.io Journey, segment, and campaign to reference the new event names

The results (90 days post-launch):

• Trial onboarding Journey reach jumped from 60% to 99% of new signups
• Feature activation campaign open rate improved by 31% (driven by correct property-based personalisation)
• Churn prevention sequence began catching an additional 18% of at-risk users who had previously slipped through
• Upsell campaign revenue attributable to Customer.io increased by 24%

None of this required new campaign creative. No new channel strategy. No A/B testing framework. Just clean data feeding the automations that already existed.

---

The Naming Convention Cheat Sheet

Here's a practical reference you can share with your engineering team today.

Format

object_actioned

Rules

• Lowercase only
• Underscores as separators (no hyphens, no spaces, no camelCase)
• Past tense for actions
• Specific enough to be unambiguous, short enough to be readable
• No abbreviations unless universally understood (mrr, arr are fine; upg_comp is not)

Examples by category

Acquisition

• user_signed_up
• trial_started
• demo_requested

Onboarding

• onboarding_completed
• profile_created
• team_member_invited
• integration_connected

Feature Engagement

• feature_activated (with feature_name property)
• report_generated
• export_completed

Monetisation

• subscription_started
• plan_upgraded
• plan_downgraded
• subscription_cancelled
• invoice_paid
• payment_failed

Retention Risk

• session_started (track frequency drops)
• feature_unused (can be computed, not fired)
• cancellation_survey_submitted

---

What Properties Should Every Event Carry?

Beyond event-specific properties, certain contextual properties should travel with every event you fire. These are sometimes called "super properties" or "global properties."

Property	Why it matters
user_id	Links the event to a specific person
account_id	Links the event to the parent company (for B2B)
plan_id	Current subscription plan at time of event
timestamp	When the event occurred (ISO 8601 format)
platform	"web", "ios", or "android"
environment	"production" vs "staging" (filter out test data)

These properties let you build cross-cutting segments and filters in Customer.io. Want to trigger a campaign only for Pro plan users on mobile? You need plan_id and platform on every relevant event. Want to make sure your testing doesn't pollute your live segments? You need environment.

---

How to Audit Your Existing Event Schema

If you're reading this and recognising your current setup, here's where to start.

Step 1: Pull your full event list

In Customer.io, go to Data & Integrations > Activity. You'll see every event that's been fired in the last 30 days. Export this list. Don't be alarmed by what you find.

Step 2: Group events by intended action

For each distinct user action (sign up, upgrade, invite a colleague, etc.), identify every event name that represents it. You'll often find 2-5 variants. This is your duplication map.

Step 3: Audit properties per event

For the 10 most important events in your funnel, check whether properties are:

• Present on every firing of that event
• Consistently named (same key every time)
• Consistent data types (always a string, always a number, never mixed)

Step 4: Map events to campaigns

For every active Customer.io Journey or campaign, identify which event triggers it and what properties it uses. This is your dependency map — it tells you what breaks if you rename or restructure an event.

Step 5: Design the new schema before touching anything

Never rename events in production before you have the new schema fully designed, documented, and agreed on. And never delete old event names until every campaign referencing them has been migrated.

This is the sequence NerveCentral follows on every client engagement. It takes discipline but prevents the kind of "I accidentally broke our trial journey" moments that are absolutely no fun at 11pm.

---

Why This Is the Work Most Teams Skip

Event schema design sits in an awkward gap. It's too technical for most marketing teams to own. It's not "shipping features" so engineering deprioritises it. It doesn't show up as a line item in campaign performance reports. And its impact is indirect — a clean schema doesn't itself send emails, it just makes every email you send smarter.

This is why it gets skipped. And it's exactly why skipping it is so costly.

The Litmus State of Email in Lifecycle Marketing Report (2024) found that marketers' top priority this year is creating more automated and triggered emails — yet over a quarter cited inadequate data as the primary barrier holding them back from better personalisation.

You can't automate your way around bad data. You have to fix the data first.

This is what distinguishes companies that use Customer.io as a broadcast tool ("we send everyone the same email on day 3") from companies that use it as a genuine revenue engine — firing the right message to the right person based on exactly what they did in the product five minutes ago.

The gap between those two outcomes isn't the platform. It's the event schema underneath it.

---

Why NerveCentral Starts With Event Architecture

As a Customer.io Certified Partner, NerveCentral has audited enough Customer.io workspaces to know that event schema problems are the single most common root cause of underperforming marketing automation.

When we onboard a new client, we don't start with campaign creative. We don't start with Journey design. We start by understanding what events are firing, whether they're firing reliably, and whether the properties attached to them are fit for purpose.

This is the foundational work. It's less visible than a beautifully designed email. It doesn't get shared on LinkedIn. But it's what makes every campaign you build on top of it actually work.

If you've read this far and you're wondering whether your event schema is costing you performance — it probably is. The good news is that it's fixable, and the improvements compound across every campaign you run from that point forward.

For teams that want to build behaviour-triggered journeys that actually convert, this work on lifecycle email strategy and smarter automation design starts making sense only once your events are clean.

We help clients integrate their data sources cleanly with Customer.io and build the event foundation that makes advanced segmentation and behaviour-triggered campaigns work the way they're supposed to.

Get in touch with NerveCentral. We'll help you get it right from day one.

---

Frequently Asked Questions

What is an event schema in Customer.io?

An event schema is the structured blueprint that defines every user action you track in Customer.io — what you name each event, what properties you attach to it, and how consistently you apply those decisions across all platforms and integrations. It's the underlying data architecture that determines how accurately Customer.io can segment users, trigger automations, and personalise messages.

What's the difference between a track event and a page event in Customer.io?

A track event captures a specific action a user performed (e.g., subscription_started, feature_activated). A page event captures a pageview — where a user went. In Customer.io's JavaScript SDK, page events are automatically fired on each page load by default. The key difference in practice: use page conditions in segments when you want to filter by URLs visited, and track conditions when you want to filter by named actions performed.

Why do naming conventions matter for Customer.io campaigns?

Customer.io triggers, segments, and Journeys reference event names exactly as they're stored. If the same user action has been tracked under three slightly different names by three different developers, your campaign will only catch users whose event matches the name it's listening for. Inconsistent naming directly reduces campaign reach and produces misleading performance data.

How do event properties affect email personalisation in Customer.io?

Event properties are the variables you reference in Liquid personalisation tags. If your subscription_started event includes plan_name, you can write Your {{ event.plan_name }} plan is now active. If that property is sometimes missing, null, or formatted inconsistently, your personalised content will render blank or incorrectly for a subset of recipients — one of the most noticeable and trust-damaging email mistakes.

What's the best naming convention for Customer.io events?

The most robust convention is Object-Action in snake_case, past tense: subscription_started, feature_activated, team_member_invited. This is consistent with industry standards across major analytics platforms, groups related events logically, and produces clean, readable event names in Customer.io's interface. Customer.io's own docs recommend avoiding spaces and special characters in event names.

How many events should a SaaS company track in Customer.io?

Focus on events that map to meaningful moments in the user journey: acquisition, onboarding, core feature engagement, monetisation, and retention risk. For most SaaS companies, 20-40 well-defined events is sufficient to power a sophisticated automation strategy. Tracking 100+ events usually signals poor planning, not better coverage — it creates noise that makes your workspace harder to maintain and your campaigns harder to audit.

What's a super property and should I use them?

A super property (sometimes called a global property) is a piece of context that travels with every event you fire — things like user_id, account_id, plan_id, and platform. These properties let you build cross-cutting segments and filters in Customer.io without needing to check each individual event for the relevant data. Yes, you should include them on every event. They're particularly important for B2B SaaS companies who need to segment by account as well as by individual user.

How does a bad event schema affect campaign attribution?

If conversion events (like subscription_started or invoice_paid) fire inconsistently or under multiple names, you can't reliably attribute conversions to the Customer.io campaigns that preceded them. Your performance reporting will undercount campaign-influenced revenue, making it impossible to justify investment in lifecycle marketing or make data-driven decisions about which campaigns to optimise.

How do I audit my existing Customer.io event schema?

Start by pulling your full event list from Data & Integrations > Activity. Group events by intended user action to identify duplicate or inconsistent names. For your 10 most critical events, check property consistency — same keys, same data types, same value formats every time. Map events to active campaigns to understand what breaks if you change names. Then design the new schema before changing anything in production. NerveCentral offers event schema audits as part of our Customer.io onboarding service.

What's the difference between the Customer.io Track API and the Pipelines API for events?

Customer.io's Track API uses a name parameter for event names and a data object for properties. The newer Pipelines API uses an event parameter and a properties object, following the Segment/CDP standard. The key practical difference: Track API uses Unix timestamps, Pipelines API uses ISO 8601. For most new integrations, Customer.io recommends the Pipelines API as it supports more recent platform features. If you're migrating from an older integration, understanding which API your events are coming from helps diagnose property format inconsistencies.

How long does it take to redesign an event schema?

A full event schema audit and redesign for a mid-size SaaS typically takes 4-8 weeks end-to-end — covering audit, design, engineering implementation, data validation, and migration of existing campaigns. The engineering implementation phase (actually firing events correctly from the product) is usually the longest. Planning and documentation work that precedes implementation typically takes 1-2 weeks. NerveCentral typically completes this work in 6 weeks for a standard Customer.io workspace.

Can I redesign my event schema without breaking live campaigns?

Yes, with careful planning. The key is to run old and new event names in parallel during the transition — fire both the legacy event and the new event simultaneously until every campaign referencing the old name has been migrated. Never delete a legacy event name until you've confirmed no active campaign, segment, or Journey depends on it. Build a dependency map before you start and work through it systematically.

How does a clean event schema improve customer segmentation?

Segmentation in Customer.io is built on event data. Behavioural segments ("users who activated Feature X in the last 7 days") require that the relevant event fires reliably with the correct properties every time. If feature_activated is missing 20% of the time or carries the wrong feature_name value, your segment will be incomplete by definition. Clean events mean segments you can trust — and segments you can trust mean campaigns that reach the right people.

Why should event schema design happen before building Customer.io campaigns?

Because every campaign you build on top of broken events will inherit those broken events' limitations. If you build 40 campaigns before auditing your schema, you have 40 campaigns to fix when you eventually do the audit. Starting with clean events means every campaign you build from that point forward works correctly from day one, and you're not spending weeks debugging "why isn't this Journey firing?" questions that trace back to an inconsistent event name.

What's the ROI of investing in event schema design?

The returns are compounding and indirect — which is why they're easy to undervalue. In NerveCentral's client work, properly structured event schemas have contributed to: significantly higher triggered campaign reach (from 60% to 99% of intended recipients in one case), substantial improvements in personalisation accuracy, more reliable behavioural segmentation, and measurable increases in campaign-attributed revenue. Klaviyo's 2024 benchmark data shows that automated flows generate up to 30x more revenue per recipient than broadcast campaigns — but those flows only perform at that level when the events feeding them are accurate.

---

Sources

1. Gartner — Poor data quality costs organisations $12.9M annually: ESRI ArcNews, Summer 2024

2. McKinsey Global Institute — Poor data quality leads to 20% productivity decrease, 30% cost increase: ESRI ArcNews, Summer 2024

3. Customer.io Official Documentation — Track and page events: docs.customer.io/integrations/data-in/connections/javascript/legacy-js/events/

4. Customer.io Official Documentation — Track API vs Pipelines API: docs.customer.io/integrations/api/track-vs-cdp-api/

5. Litmus — State of Email in Lifecycle Marketing Report 2024: litmus.com

6. Klaviyo — 2024 Email Marketing Benchmarks (automated flows generate up to 30x more revenue per recipient): klaviyo.com/marketing-resources/email-benchmarks-by-industry-2024

7. Lifecycle Mechanics / Arsalan Raza — Event schema fixes increased conversion rates by 15% in two months (2025): lifecyclemechanics.com

8. IEEE Electromagnetic Compatibility Magazine / Daniel D. Hoolihan — Titanic wireless telegraphy and the U.S. Radio Act of 1912: encyclopedia-titanica.org

9. Science Museum London — Titanic, Marconi and the wireless telegraph: sciencemuseum.org.uk

10. Statsig — Event schema best practices for experimentation (2024): statsig.com/perspectives/event-schema-example-structuring-data