How to Set Up Segment Protocols for Schema Validation

If you're on Segment and you've started worrying about tracking plan drift, Protocols is the first thing most people reach for — and rightly so. It's Segment's built-in tracking plan enforcement feature: it validates events at ingestion against a defined schema, and blocks or flags non-conforming data before it reaches your warehouse and downstream destinations.

I've helped a few teams set this up. It's a solid starting point with some real edges. This is a walk-through of how to get Protocols running, the limitations I'd want you to know about before you lean on it as your only line of defence, and how to extend enforcement with external tooling when Protocols runs out of road.

What Protocols does

Segment Protocols lets you:

• Define event schemas with property-level type validation.
• Validate events at ingestion, before they're routed to destinations.
• Block non-conforming events, or allow them through with a violation flag.
• Track violations so you can see which events fail validation and why.
• Set event labels for categorisation and filtering.

When a track call arrives at Segment, Protocols checks it against your tracking plan. If the event name isn't in the plan, or its properties don't match the expected types, Protocols can block it or let it through with a violation marker.

Setting up Protocols

1. Enable Protocols on your workspace

Protocols is available on Segment Business plans. Go to Protocols in your workspace sidebar. If it's not there, you probably need a plan upgrade — speak to Segment.

2. Create a tracking plan

Under Protocols > Tracking Plans, create a new plan. In Segment, a tracking plan is the schema definition your events are validated against.

You can create events manually or import them:

• Manually — add events one by one with property definitions.
• CSV import — upload a spreadsheet with event names and properties.
• API — use the Segment Config API to programmatically manage your tracking plan.

3. Define event schemas

For each event, specify:

• Event name — the exact track call name (e.g. Order Completed).
• Properties — each with a name, type (string, number, boolean, object, array), and required/optional flag.
• Description — human-readable context for each event and property.

Example schema for Order Completed:

{
  "name": "Order Completed",
  "rules": {
    "properties": {
      "order_id": { "type": "string", "required": true },
      "revenue": { "type": "number", "required": true },
      "currency": { "type": "string", "required": true },
      "products": { "type": "array", "required": true }
    }
  }
}

4. Connect the tracking plan to a source

A tracking plan does nothing until it's connected to a source. Go to Connections > Sources, select your source, and under Settings > Protocols, assign the tracking plan.

5. Configure enforcement

Segment offers three enforcement modes:

• Allow unplanned events — events not in the plan pass through (default).
• Block unplanned events — events not in the plan are dropped.
• Block unplanned properties — properties not in the schema are stripped from events.

I'd start with "Allow" so you can see violations without blocking live data. Once you're confident in the plan, switch to "Block" for full enforcement.

6. Monitor violations

Go to Protocols > Violations to see which events fail validation. The common ones:

• Unplanned event — an event name that isn't in the tracking plan.
• Unplanned property — a property that isn't defined in the schema.
• Type mismatch — a property value that doesn't match the expected type.
• Missing required property — a required property is absent.

Where Protocols runs out of road

Protocols is a solid enforcement mechanism, but it has constraints worth understanding before you rely on it as your only line of defence.

It's Segment-only. Protocols validates events flowing through Segment. If you also use RudderStack, Snowplow, or send events directly to your warehouse, those events aren't validated. You need a separate enforcement mechanism for each pipeline.

There's no AI or automation. Schema authoring in Protocols is entirely manual — you define each event and property by hand. No AI-assisted generation, no auto-discovery from your warehouse, no code generation for your tracking implementation.

The workflow is limited. Protocols has no approval flow. Any workspace admin can modify the tracking plan directly. No changeset concept, no diff view, and no audit trail of who changed what and when.

There's no warehouse validation. Protocols validates at ingestion. Once events pass through Segment and land in your warehouse, there's no ongoing validation. Volume anomalies, property drift, and SLA breaches downstream aren't detected.

There's no implementation help. Protocols tells you what the schema should be. It doesn't help developers implement it — no auto-generated PRs, no MCP server for IDEs, no SDK codegen from the schema.

Extending Protocols with external tooling

If you need more than ingestion-time validation, external tools can complement Protocols:

• Schema authoring — use a dedicated event governance tool to define contracts (with AI assistance), then push the resulting schema to Protocols for enforcement.
• Cross-CDP enforcement — if you use multiple CDPs, manage your event schema in a centralised tool and publish to Segment Protocols, RudderStack Tracking Plans and Snowplow Iglu from a single source of truth.
• Warehouse validation — connect to your Snowflake warehouse for ongoing monitoring of volume anomalies, property type drift, and freshness SLAs that Protocols can't detect.
• Implementation automation — generate GitHub PRs with tracking code from your event schema, or use an MCP server to give developers real-time schema context in their IDEs.
• Approval workflows — require review and approval for schema changes before they reach Protocols, with a full audit trail of who proposed, reviewed, and approved each change.

A few practices worth keeping

1. Start with your highest-value funnel. Don't try to define every event at once. Start with checkout, activation, or subscription lifecycle events.
2. Strict mode for critical events. Block unplanned properties on revenue-critical events like Order Completed. Use permissive mode for events still in development.
3. Review violations weekly. The violations dashboard is only useful if someone looks at it. Set a weekly cadence to catch drift early.
4. Version your tracking plan. Segment doesn't natively version tracking plans. Export regularly (via API) and store the export in git for history.
5. Coordinate with your data team. Schema changes affect downstream models. Communicate before you change anything.

Segment Protocols is the right starting point for event schema enforcement if you're a Segment-first shop. If you need AI-assisted schema authoring, cross-CDP enforcement, warehouse-native validation or approval workflows, it works best as the enforcement layer inside a broader event governance system.

That broader system is what I'm building at suky. If any of the limitations above hit home, come take a look.

— Kevin