When would you route product events through Segment rather than instrument each vendor SDK directly?

## The problem a CDP claims to solve Without one, every analytics, marketing, support and advertising tool arrives with its own SDK, its own event model and its own identity rules. Each new tool is a client release on web, iOS and Android, followed by weeks of reconciling why its numbers disagree with the last tool's. The instrumentation is duplicated N times and rots at N different rates. A customer-data platform inverts this: you instrument once against a neutral spec, and routing to vendors becomes configuration. ## What routing through Segment actually buys **Decoupling from the vendor set.** Adding a cloud-mode destination is a settings change. For an organisation that trials tools, or whose marketing stack turns over every eighteen months, this is the dominant benefit — it removes the mobile release cycle from the critical path of a vendor decision. **Replay.** Because the raw stream is archived, a tool adopted today can be backfilled with history, and a destination that was broken during an outage can be re-sent. A tool that starts with two years of behaviour is useful on day one instead of in six months. **One warehouse copy of the same stream.** The events that feed the vendors also land in your warehouse, so product behaviour joins to production data and finance data. That single fact converts arguments about which tool is right into a query. **Governance.** A tracking plan gives multiple teams and platforms one declared schema, with violations visible centrally, instead of a naming convention in a wiki page nobody reads. **Central privacy and consent controls.** One chokepoint where events can be suppressed, fields redacted or destinations gated is far more tractable than the same policy re-implemented in every SDK. ## What it costs **A price shape that tracks your success.** CDP pricing is typically per monthly tracked user or per event volume. The bill therefore grows with user growth and with chatty instrumentation, and the economics push teams to filter low-value events at the source, sample, or route high-volume machine-generated events straight to the warehouse rather than through the CDP. Model the cost against your growth curve, not today's volume. **Another vendor in the path.** Collection outages, delivery lag and a third-party script on your pages all become yours to explain. The blast radius is the whole downstream stack rather than one tool. **Lowest-common-denominator mapping.** A neutral spec fanned out to many vendors cannot express every vendor's advanced features. Teams routinely end up sending some vendor-specific calls anyway, at which point the "instrument once" story is partial. **Device-mode leaks the abstraction.** Any tool whose value is client-side — session replay, in-app messaging, experimentation, ad pixels — still ships its own SDK in your app, with its own bundle weight and its own identity logic, so it still diverges from the warehouse. **Lock-in moves rather than disappears.** Your instrumentation is now written against one vendor's spec. That spec is widely imitated, which softens the risk, but a migration is still a real project. ## The credible alternatives Direct SDK instrumentation is fine when there are two or three destinations that are not going to change. A **warehouse-first** architecture is increasingly the competitor: collect events into your own pipeline or straight into the warehouse, model them there, and push the results outward with a reverse-ETL tool. That inverts the flow — the warehouse becomes the source of truth and the operational tools become its consumers — and it suits organisations whose activation logic is already SQL. There are also open-source and self-hosted collectors that implement a Segment-compatible spec, which trade the licence cost for infrastructure you now run, and are worth evaluating when volume is the dominant cost driver. Note that warehouse-first and CDP are not exclusive: a common shape is a CDP for client-side collection and real-time destinations, plus reverse-ETL for anything that needs modelled, joined data. ## How to actually decide Count the destinations in real use and how often that list changed in the last two years — that number, more than anything else, predicts whether decoupling pays. Ask who owns instrumentation: if marketing needs to add tools without an engineering queue, the CDP is buying organisational speed, not just technical convenience. Ask whether you need real-time activation or whether daily warehouse-driven syncs suffice, because the latter points at reverse-ETL. Model the price shape against projected growth and volume, including the events you would be tempted to stop sending because of the bill. And weigh the privacy and consent story: a single enforcement point is a genuine risk reduction that is hard to reproduce across a dozen SDKs. A reasonable summary answer in an interview: a CDP is bought for change and governance, not for collection. If the vendor set churns, several teams share the schema, and history matters when adopting a tool, it earns its cost. If the stack is stable, the warehouse is already the source of truth, and volume is large, the case weakens fast.