This article is Part 1 of a 3-part series highlighting key Segment implementation principles, complementing the official success story which outlines the commercial and business impact.

When we started working with Nexo, it wasn’t that they lacked data – they had too much, and none of it was consistent.

Different teams had built their own data pipelines over time: marketing scripts here, mobile SDKs there, backend logs elsewhere. Each used different methods, different naming conventions, and in many cases, sparse or undocumented schemas.

This fragmented approach created some big problems – marketing couldn’t reliably track conversions across channels or attribute performance – custom solutions where often used. Product teams struggled to compare usage across platforms. Engineering was overwhelmed & stuck maintaining brittle tracking logic.

The data was siloed. The schemas were inconsistent. And everyone relied on expensive resources (engineering) to manually bridge the gaps.

The core problems we set out to resolve were the following:

Our first job wasn’t to touch code – it was to design the system that would bring consistency, governance, and scalability to their event tracking.

1. Start with an Event Matrix

We began by building a Tracking plan (often referred to as Event matrix) – a structured document mapping every key user interaction across web, app, and backend. Segment have a few great examples for these type of specs – here’s an example.

Each event entry included:

Event name (e.g. User Signed Up, Transaction Completed)

Source (web, mobile, server)

Properties (expected keys, types, values)

Trigger logic (when and how the event is fired)

Destinations (e.g., GA4, Mixpanel, Google Ads)

💡 Pro tip: We kept this in a collaborative spreadsheet with version control, which can later be used as the foundation for Protocols to enforce schemas. More on that in the next parts of this series.

This became our Tracking Plan – a shared contract between devs, analysts & marketers.

2. Define Identity Strategy Early

Identity stitching is a cornerstone of Segment’s power. But only if you get it right early.

We set clear rules for how to use:

identify(userId, traits) – once the user logs in or signs up

track(event, properties) – for all behavioral events

Segment’s documentation has all available methods documented here: Segment Specs

All sources (web, app, server) followed the same pattern.

3. Track for the Consumer, Not the Collector

Just because you can track an event doesn’t mean you should.

We designed our event model by first asking: who’s going to use this data, and for what? That meant prioritizing meaningful, high-value actions over vanity metrics or noise.

For the marketing team, this meant capturing:

Conversion points like Signed Up, KYC Completed, Deposited

Attribution signals: UTM parameters, landing page, referral source

Funnel drop-offs and cross-device linking

These were critical for optimizing paid media, retargeting, and lifecycle flows.

For the product team, we tracked behavioral patterns:

Feature usage: Application Opened, Tutorial Completed, CTA Clicked

Session-level interactions and page flows

Engagement depth across web and app

This allowed them to identify friction points, validate releases, and run data-informed experiments with full visibility.

💡 Pro tip: Every unnecessary event adds complexity, cost, and risk. Track with purpose.

4. Set Naming Conventions and Property Standards

Standardizing naming and formatting across all sources and teams is also key. For example:

Event Names → Pascal Case (e.g. Signed Up, Transaction Completed)

Properties → snake_case (e.g. user_id, plan_type)

Timestamps → ISO 8601 format

Always include user_id and/or anonymous_id

This consistency simplifies debugging, querying, and mapping across destinations.

5. Make the Tracking Plan enforcable with Segment Protocols

Once the Tracking Plan was ready, we operationalized it via Segment Protocols, which was synced with dev, staging, and production sources. Protocols enable real-time validation of every event and property as they hit Segment servers, adding controls to what happens with the data if it does not meet pre-defined rules.

Segment Protocols overview.

Protocols helped us enforce:

Property existence and data types

Event naming conventions

Detection of unexpected or deprecated events

Conclusion

A tracking plan isn’t just documentation – it’s infrastructure.

It’s what aligns teams, removes ambiguity, and builds trust in your data. And without it, even the best tools – like Segment – can only take you so far.

With this foundation in place, we were ready to move to the next stage: implementation across platforms.

👉 Coming up in Part 2: I’ll walk through how we instrumented Segment on web, mobile, and backend systems – while enforcing consent and streamlining developer workload.

Resources mentioned in this blog:

Segment Specs
Segment Protocols
Segment B2B SaaS Spec sheet example
Segment Tracking Plan