Segment sends user data to Twilio Segment (Twilio Inc.). Event data, identifiers, device and network context and an IP address leave the device, land in Segment's pipeline, and are then forwarded to whatever destinations you have connected — so this is a third-party transfer (often to many third parties) that you must disclose in your privacy policy for the GDPR, the App Store and Google Play. Generate a full privacy policy with this clause built in →
Does Segment need a privacy policy disclosure?
Yes, and more than most analytics SDKs. Segment is a customer-data platform: its track, identify and screen calls collect events and traits, attach an anonymous ID (and a user ID once you identify), and automatically add a rich context object — app, device, network, OS, screen, locale, timezone and, server-side, the IP address. Segment then routes that data to the destinations you enable, so a single integration can be a transfer to a dozen downstream processors and, for ad destinations, independent controllers.
Twilio Segment acts as your data processor under its Data Processing Addendum. Whether Segment counts as "tracking" under Apple's Guideline 5.1.2 depends entirely on your destinations: routing events to an advertising or attribution destination, or collecting the IDFA, makes it tracking and requires an App Tracking Transparency prompt.
What data does Segment collect?
| Data type | Purpose | Linked to the user? | Used for tracking? |
|---|---|---|---|
Anonymous ID and User ID (plus any traits you set in identify: name, email, plan, etc.) | Attribute events, route to destinations | Yes | Depends on destinations |
Product-interaction / event data (track and screen events) | Analytics, personalization, marketing | Yes | Depends on destinations |
| Device context (device ID / IDFV, model, manufacturer, type, name; app name, version, build) | Analytics, segmentation | Yes | Depends on destinations |
| Network and environment context (carrier, cellular/wifi, OS name and version, screen size, locale, timezone, user agent) | Analytics | Yes | No |
| IP address (added by Segment's servers; used for geolocation then not stored in full by default) | Geo enrichment, security | Yes | No |
IDFA (context.device.advertisingId) | Advertising / attribution — only if you enable IDFA collection | Yes | Yes, if enabled |
Segment's Analytics-Swift privacy manifest declares Device ID, Advertising Data, Precise Location, App Name and App Version, and the library uses only the userDefaults required-reason API. The exact list depends on your configuration: if you do not collect the IDFA, Segment sets adTrackingEnabled to false and drops advertisingId from the payload; every trait and every destination you add expands what you must disclose. (Uncertain: Segment's manifest labels location as "Precise Location" even though the SDK only derives coarse location from IP — declare conservatively.)
Copy-paste privacy policy clause for Segment
Data pipeline. We use Segment, a customer-data platform provided by
Twilio Inc., to collect and route product data. The Segment SDK collects
an anonymous identifier, a user identifier and account traits where we
set them, the in-app events and screen views we instrument, device,
network and operating-system context, and an IP address that Segment uses
for geolocation and then does not retain in full. Segment forwards this
data to the third-party tools we have connected (for analytics, product,
marketing and, where applicable, advertising purposes), each of which
processes it under its own terms. Twilio Segment acts as our processor
under its Data Processing Addendum. See https://www.twilio.com/en-us/legal/privacy
for details.Adapt this: list your actual connected destinations (or link a subprocessor list), name any advertising destinations that act as independent controllers, remove the IDFA implication if you never collect it, and state your US or EU (Regional Segment) processing region. This is a template, not legal advice; you are responsible for keeping it accurate as you add destinations.
App Store "App Privacy" label answers
For a default Segment integration with no advertising destinations, declare in App Store Connect:
- Identifiers > Device ID — purpose "Analytics" and "App Functionality", Linked to the user, not used to track (unless an ad/attribution destination is connected).
- Identifiers > User ID — if you call
identify. Purpose "Analytics", "App Functionality", Linked to the user. - Usage Data > Product Interaction — purpose "Analytics", Linked to the user.
- Contact Info > Name / Email Address — if you send those as traits. Purpose "App Functionality", Linked to the user.
- Diagnostics > Crash Data / Performance Data — only if you route those events.
If any connected destination is an advertising or attribution tool, or you collect the IDFA, flip Device ID, User ID and Product Interaction to "Used to track you", add Identifiers > Device ID for advertising, use purpose "Third-Party Advertising", and show an ATT prompt.
Google Play Data Safety answers
In the Play Console Data Safety form, a standard Segment setup means:
- Device or other IDs — Collected: Yes. Shared: Yes (Segment forwards to your destinations). Purpose: Analytics, App functionality, plus Advertising/Marketing if applicable.
- App activity > App interactions, Other actions, Page views and taps in app — Collected: Yes. Shared: Yes. Purpose: Analytics.
- Personal info > Name / Email address / User IDs — Collected: Yes if sent as traits. Shared: Yes. Purpose: App functionality, Account management.
- App info and performance > Diagnostics / Crash logs — Collected: Yes if routed. Shared: Yes.
- Location > Approximate location — Collected: Yes (IP geolocation). Shared: Yes. Purpose: Analytics.
Because Segment is a pipeline, "Shared" is almost always Yes — this is the biggest difference from a standalone analytics SDK. Data is not "processed ephemerally". Users can request deletion; Segment provides a user-deletion and suppression API keyed on userId, and it attempts downstream deletion for supported destinations — link your own request route.
Segment-specific gotchas
- "Shared" is the default reality. Every destination you connect is another recipient; your Data Safety "Shared" answer and your privacy-policy recipient list must be kept in sync with the destination list in the Segment workspace.
- Device-mode vs cloud-mode changes who sees raw data. Device-mode destinations run their own SDK inside your app and get data directly; cloud-mode destinations receive it from Segment's servers. Both need disclosing.
- The
contextobject is collected even for anonymous users. Device, network and IP context ship with the very first event, before any consent gate unless you add one. - IDFA handling depends on SDK version and setup. Older analytics-ios auto-collected the IDFA when AdSupport was linked; analytics-swift requires you to add IDFA collection. Verify which your build does.
- Traits persist.
identifytraits are cached on device and replayed on later events; an email or full name there becomes a directly identifying record across all destinations. - Region and consent are opt-in. Data is processed in the US unless your workspace uses the EU region, and blocked consent categories only stop reaching destinations if you wire up Segment's consent-management mapping, not just your CMP.
Related
See the sibling clauses for Google Analytics for Firebase, Mixpanel, Amplitude and PostHog. Assemble the full document with the privacy policy page generator, and if your app also uses Firebase read the Firebase privacy policy generator guide.