In Segment, how do device-mode and cloud-mode destinations differ?

## Two delivery paths for the same event When you call `analytics.track('Order Completed', {...})` in the browser, Segment has two ways to get that event to a given destination, chosen per destination in the source's settings. Understanding which path a destination is on explains most of the surprises teams hit later: mismatched numbers, events missing from one tool but present in the warehouse, filters that mysteriously do not apply. ## Cloud-mode In cloud-mode the event goes from the client to Segment's collection endpoint. Segment stores it, applies whatever pipeline logic you have configured, and then calls the destination's **server-side API** with a payload mapped into that vendor's schema. Everything Segment can do for you lives on this path: - **Destination filters and transformations** — dropping, sampling or reshaping events per destination, because Segment holds the event before forwarding it. - **Server-side retries** — a destination API that is down or rate-limiting gets retried from Segment's infrastructure rather than from a browser tab that has already closed. - **Replay** — Segment archives the raw event stream, so a destination added later can be backfilled from history, and a destination that dropped events during an outage can be re-sent. - **Consent and privacy controls applied in the pipeline** — because the pipeline is the chokepoint every cloud-mode event passes through. - **A small client bundle** — no vendor code ships to the user. Cloud-mode also works for events that never touch a browser at all: server libraries and cloud sources feed the same pipeline, so a purchase confirmed by your backend can reach the same marketing tool. ## Device-mode In device-mode, Segment's client library loads the destination vendor's **own SDK** into the page or mobile app, and the call is handed to that SDK, which talks to the vendor directly. Segment still receives its own copy for the warehouse and for other destinations, but the copy that reaches this vendor did not go through Segment's forwarding path. Device-mode exists because some destinations genuinely cannot be served from a server. Session replay and heatmaps need to observe the DOM. In-app messaging and push SDKs need to render UI and register tokens. Experimentation SDKs need to decide a variant before first paint to avoid flicker. Advertising and attribution pixels need browser cookies, device identifiers and the referrer as the browser itself sees them. A server-to-server call cannot reproduce any of that. ## What device-mode costs you - **Bundle weight and a third-party script** on every page load, with the availability and performance of that vendor now on your critical path. - **Ad blockers and tracking protection** frequently block the vendor's script, and sometimes Segment's own, so the client-delivered copy is lost while the server-side copy survives. This is the single most common cause of "the tool shows fewer conversions than the warehouse". - **No server-side retry.** Delivery is best-effort from a page that may unload mid-flight. - **No replay and no destination filters** for that destination — Segment is not in the path, so it cannot re-send or reshape what it never forwarded. - **The vendor's own identity and session logic** applies, which is why session counts and unique-user counts diverge between a device-mode tool and the warehouse even when no events were lost. ## Choosing, and mixing The practical default is cloud-mode for anything that is fundamentally "receive an event and store it", and device-mode only where a client-side capability is the reason you bought the tool. Some destinations support both simultaneously — device-mode for the features that need it and cloud-mode for the rest — and Segment's docs for each destination state which modes it supports. Note that running both can double-count if the same event is delivered twice; the destination's Segment integration usually handles this, but it is worth verifying against a known event volume. You can also override routing per call. The third options argument accepts an `integrations` object keyed by destination name, so a sensitive event can be excluded from one vendor without a redeploy of your routing rules — although a destination filter configured centrally is usually the better place for a durable rule, since it does not require a client release. ## Debugging in practice When a stakeholder says a tool is under-reporting, the first question is which mode that destination runs in. If it is device-mode, compare against the warehouse copy: a gap concentrated on ad-blocking-heavy traffic, or on mobile browsers with strict tracking protection, points at the bundled script rather than at your instrumentation. If it is cloud-mode, the gap is more likely a destination filter, a mapping that drops events missing a required field, or delivery errors visible in Segment's own event delivery view.