Segment Analytics-Next

Analytics-Next (Analytics 2.0) is Segment’s official browser SDK for instrumenting product and marketing analytics from a single API call. Instead of writing a bespoke integration for every downstream tool, teams call track, identify, and page once and let Segment’s plugin architecture fan the event out to hundreds of destinations — from Amplitude to Google Ads.

The SDK is built around a middleware/plugin pipeline that runs before, during, and after delivery, letting teams enrich, filter, or redirect events without touching application code. It ships as a monorepo alongside @segment/analytics-node and shared core packages, and is actively maintained by Segment as one of its most heavily used open-source libraries.

What You Get

• A typed AnalyticsBrowser client with load, track, identify, page, group, and alias methods
• A plugin/middleware system (before, enrichment, destination, after) for intercepting and transforming events
• Built-in buffering so events fire before the destination loads and before user consent is confirmed
• First-party integration with Segment’s cloud-mode and device-mode destinations without hand-writing vendor SDK calls
• A companion @segment/analytics-node package for server-side tracking with the same event API

Common Use Cases

• Sending product usage events (signups, feature clicks, purchases) to multiple analytics tools from one call site
• Gating tracking behind a consent-management plugin (e.g. OneTrust) before any destination loads
• Enriching events with session, page, or campaign context via custom middleware before they reach Segment
• Migrating off direct vendor SDKs (GA, Amplitude, Mixpanel) to a single maintained tracking layer

Under The Hood

Architecture: The SDK centers on an Analytics/AnalyticsBrowser class (packages/browser/src/core/analytics) that dispatches typed calls (track, identify, page) through a Context-wrapped event queue (src/core/queue) into a plugin pipeline. Plugins are typed by phase — before, enrichment, destination, after — registered via src/plugins/* (e.g. ajs-destination, segmentio, routing-middleware), so vendor integrations and consent/enrichment logic are just plugins running at defined points rather than hardcoded branches, and the same event model is reused by the sibling @segment/analytics-node package via @segment/analytics-core.

Tech Stack: Pure TypeScript targeting ES5 for browser compatibility, built with a Yarn/Turborepo monorepo (turbo.json) spanning packages/browser, packages/node, packages/core, packages/consent, and shared config packages. Runtime dependencies are deliberately small — @lukeed/uuid, dset, js-cookie, unfetch/node-fetch — keeping the shipped bundle lean since this code loads on every page view for every Segment customer.

Code Quality: 70+ Jest test files back the browser package alone (src/core/analytics/__tests__/analytics.test.ts covers the public API surface), TypeScript strict mode is enabled project-wide, and ESLint/Prettier run via shared packages/config presets. Public interfaces are explicitly typed (interfaces.ts files alongside implementation), reducing the risk of silent breaking changes across the many destination plugins.

API Design: The public surface is deliberately minimal — AnalyticsBrowser.load({writeKey}) plus track/identify/page/group/alias — so most consumers never touch the plugin system directly, while power users can register custom middleware for consent gating or event enrichment. Buffered/lazy loading (new AnalyticsBrowser() then .load() later) is a well-documented escape hatch for consent-gated tracking, a common real-world requirement this SDK handles natively instead of leaving to userland code.