Who Segment is
Segment is a customer data platform founded in 2011. Twilio acquired it in November 2020, and it now lives on Twilio's website as Twilio Segment. Its core product, Connections, collects events from websites, mobile apps and servers through one API, then translates them for each of the tools a company uses, from hundreds in its catalogue, and loads them into data warehouses.
Around that pipeline sit Protocols, which checks events against a tracking plan, Consent Management, which sends an event only to the tools a customer agreed to, privacy tools for deletion and suppression, and Unify and Engage for customer profiles and audiences. Segment offers EU workspaces whose data is collected, processed and stored in the EU, its trust centre lists a SOC 2 report and ISO/IEC 27001, 27017 and 27018 certifications, and it has its own library for Flutter, which our mobile apps are built with. That is why it is the customer data platform connector of our analytics and monitoring module.
What it does in your platform
Analytics & monitoring
Receives each event once, from the apps and the platform's server, checks it against your tracking plan and passes it on only to the tools the customer agreed to, such as your product analytics and engagement tools. Every customer appears under the same random platform ID, and a tool that takes its events from Segment's servers is added or swapped in Segment rather than in your apps.
How the connection works
Our Flutter apps use Analytics-Flutter, Segment's own Flutter library (the segment_analytics package), which Segment currently offers as a public beta, and the web apps use Segment's Analytics.js. Money events go from the platform's server through Segment's HTTP Tracking API. Segment passes events on from its own servers, which it calls cloud mode, so the tracking plan and consent are applied before any tool receives them.
The customer agrees
Nothing about the customer reaches Segment until they agree to at least one purpose, such as analytics or engagement. The choice is kept in the platform, and the app and the server add it to every event as Segment's consent object, a yes or a no for each consent category.
They sign in
The app identifies the customer to Segment by their random platform ID, never a name, email or phone number. The server uses the same ID, so events from the app, the web and the server reach every tool as one customer.
They start a transfer
Tap events on the tracking plan, such as the customer starting a transfer, are queued on the phone and sent in batches to Segment's EU endpoint in Dublin.
The money moves on the server
When the transfer settles, the platform sends the event from its server through the HTTP Tracking API, with a message ID it sets itself, the field Segment's deduplication uses to drop a resent copy. The figures match the ledger.
Segment checks and routes
Protocols compares the event with your tracking plan: tracked events that are not on the plan are blocked, and properties that are not on it are removed, before any tool sees them. Segment then sends the event only to tools in the categories the customer agreed to: if they said yes to analytics but no to engagement, it reaches Mixpanel or Amplitude, never Customer.io or Braze.
They ask to be forgotten
The platform stops sending and asks Segment's Public API to suppress and delete the customer's platform ID. Segment refuses any new data for that ID, deletes what it holds within 30 days and forwards the request to the tools that accept deletions from it, such as Amplitude, Braze and Customer.io. The platform also asks each tool directly through its own deletion API, where it has one.
Next to other providers
Segment is the module's customer data platform: it sits in front of the other connectors rather than in place of one. Mixpanel and Amplitude for product analytics, and Customer.io and Braze for engagement, can all take their events from Segment's servers, sent to each tool's EU endpoint. Features that need a tool's own code on the phone, such as in-app messages or Adjust's install attribution, keep that tool's SDK in the app, and crash, error and performance monitoring stays with Sentry, Firebase Crashlytics and the module's other monitoring tools, which catch crashes with their own SDKs.
The consent choices and platform IDs are kept in your platform, and the tracking plan can be downloaded from Protocols at any time. A tool that takes its events from Segment's servers is added or replaced in Segment rather than in your apps, and Segment can replay its archive of past events into the new tool, keeping each event's consent choices. Moving away from Segment later changes a connector, not your apps' screens.
When Segment fits best
A strong fit when
- You use several analytics, engagement or attribution tools and want your apps to send each event only once.
- You want the tracking plan and each customer's consent enforced in one place, before any tool receives an event.
- You expect to add or change tools, and want a new one filled with past events rather than starting empty.
Also worth a look
- Mixpanel, Amplitude or Google Analytics for Firebase connected directly, when one product analytics tool is all you need.
- A customer data platform your team already uses: its account becomes a connector too.
How we get you live
The contract
We help you get your Segment account and contract in place, with an EU workspace and the features this design relies on: Protocols for the tracking plan and Consent Management for routing by consent. We set up workspace roles with you, since only workspace owners can change consent categories.
The data
We create the workspace in Segment's EU region, which cannot be changed later, and agree the tracking plan with your team. Every tool is mapped to a consent category, because Segment treats a tool with no category as needing no consent. In every event from the apps and web apps we set the IP field to 0.0.0.0, the way Segment documents to stop it recording customers' IP addresses, and Analytics-Flutter's device ID and lifecycle tracking stay off, as they are by default.
The keys
The apps, the web apps and the server each send through their own Segment source and write key. A write key can send data but cannot read it or change settings, so it is all the apps carry. The server's source can also require OAuth 2.0 tokens, obtained with a private key kept in your platform's secrets, where the Public API token for deletions stays too.
A full test run
Everything runs first through separate test sources with their own write keys, as Segment recommends, sending to test projects in each tool. We clear every tracking plan violation before blocking is switched on, check that declined categories hold events back, and run a test deletion, all before your first real customer.