
@segment/analytics-next
Analytics Next (aka Analytics 2.0) is the latest version of Segment’s JavaScript SDK - enabling you to send your data to any tool without having to learn, test, or use a new API every time.
About
Analytics Next (aka Analytics 2.0) is the latest version of Segment’s JavaScript SDK - enabling you to send your data to any tool without having to learn, test, or use a new API every time.
What detecting @segment/analytics-next tells you about a site
Segment is a customer-data pipeline rather than an analytics destination, so finding @segment/analytics-next tells you the team routes a single stream of events to many downstream tools at once. Its presence implies a mature data strategy: instrument once, fan out to analytics, marketing, warehouses and advertising platforms through Segment's hub. This is a strong organisational signal, because Segment is typically adopted by companies with several teams consuming the same event data. The analytics-next namespace is the modern rewrite of the older analytics.js, so it also marks a relatively current integration of that pipeline.
Why the exact @segment/analytics-next version matters
analytics-next is the ground-up successor to the classic analytics.js, so spotting it already places the integration in the modern generation. Its own versions refined plugin and middleware APIs, consent and privacy handling, and how it loads downstream destinations, so the exact version affects which integrations load client-side versus server-side and how user consent gates them.
@segment/analytics-next in a real-world stack
When you find @segment/analytics-next in a bundle, it rarely travels alone. Acts as a hub, so its real companions are the downstream destinations it forwards to rather than a fixed sibling library.
Quick facts
npm install @segment/analytics-nextWhat @segment/analytics-next pulls in
@segment/analytics-next declares 11 direct dependencies — each one also rides into any bundle that ships @segment/analytics-next, so they are detection targets too. Reading them is a quick way to understand the package's real footprint .
How Sourcemap Explorer detects @segment/analytics-next
@segment/analytics-next ships as v1.84.3, published 2026-09-11 and carries 11 direct dependencies, 160 versions on the registry. Those exact numbers are the footprint Sourcemap Explorer matches when @segment/analytics-next rides inside a deployed bundle — here is how the detection works.
We catch @segment/analytics-next from two complementary signals: bundled source paths and the embedded package.json. Modern bundlers (webpack, Vite, esbuild, Rollup, Turbopack) preserve the original node_modules/@segment/analytics-next/ paths inside the JavaScript sourcemap's sources[] array — that's the canonical signal. When the matching package.json is also captured in sourcesContent[], we read the exact version field — patch number included. No regex guessing, no version inference.
- 1
Confirm the site exposes sourcemaps
In DevTools Network, check the response headers of any application script for `SourceMap` or `X-SourceMap`. Failing that, fetch the script's last 4 KB and look for a `//# sourceMappingURL=` comment — that map is where the `@segment/analytics-next` paths live.
- 2
Find the package in the bundle
Open DevTools → Network → reload. Click any application script and look at its sourcemap. Inside, search `sources[]` for entries matching `node_modules/@segment/analytics-next/` — every match confirms the package is bundled. The matching `sourcesContent[i]` for `node_modules/@segment/analytics-next/package.json` gives you the exact installed version.
- 3
Read the version directly from package.json
Run `jq -r '. as $m | $m.sources | to_entries[] | select(.value | endswith("node_modules/@segment/analytics-next/package.json")) | $m.sourcesContent[.key] | fromjson | .version' bundle.js.map`. Sourcemap Explorer automates the same query in the popup.
Recent versions
@segment/analytics-next README
Live mirror of the GitHub README, for reference. Updated whenever the repo's default branch changes.
@segment/analytics-next
Analytics Next (aka Analytics 2.0) is the latest version of Segment’s JavaScript SDK - enabling you to send your data to any tool without having to learn, test, or use a new API every time.
Table of Contents
🏎️ Quickstart
The easiest and quickest way to get started with Analytics 2.0 is to use it through Segment. Alternatively, you can install it through NPM and do the instrumentation yourself.
💡 Using with Segment
-
Create a javascript source at Segment - new sources will automatically be using Analytics 2.0! Segment will automatically generate a snippet that you can add to your website. For more information visit our documentation).
-
Start tracking!
💻 Using as an npm package
- Install the package
# npm
npm install @segment/analytics-next
# yarn
yarn add @segment/analytics-next
# pnpm
pnpm add @segment/analytics-next
- Import the package into your project and you're good to go (with working types)!
import { AnalyticsBrowser } from '@segment/analytics-next'
const analytics = AnalyticsBrowser.load({ writeKey: '<YOUR_WRITE_KEY>' })
analytics.identify('hello world')
document.body?.addEventListener('click', () => {
analytics.track('document body clicked!')
})
Lazy / Delayed Loading
You can load a buffered version of analytics that requires .load to be explicitly called before initiating any network activity. This can be useful if you want to wait for a user to consent before fetching any tracking destinations or sending buffered events to segment.
- ⚠️ ️
.loadshould only be called once.
export const analytics = new AnalyticsBrowser()
analytics.identify("hello world")
if (userConsentsToBeingTracked) {
analytics.load({ writeKey: '<YOUR_WRITE_KEY>' }) // destinations loaded, enqueued events are flushed
}
This strategy also comes in handy if you have some settings that are fetched asynchronously.
const analytics = new AnalyticsBrowser()
fetchWriteKey().then(writeKey => analytics.load({ writeKey }))
analytics.identify("hello world")
Error Handling
Handling initialization errors
Initialization errors get logged by default, but if you also want to catch these errors, you can do the following:
export const analytics = new AnalyticsBrowser();
analytics
.load({ writeKey: "MY_WRITE_KEY" })
.catch((err) => ...);
Custom CDN / API Proxy
Self Hosting or Proxying Analytics.js documentation
Examples / Usage in Common Frameworks and SPAs
Next.js
- https://github.com/vercel/next.js/tree/canary/examples/with-segment-analytics
- https://github.com/vercel/next.js/tree/canary/examples/with-segment-analytics-pages-router
Vanilla React
import { AnalyticsBrowser } from '@segment/analytics-next'
// We can export this instance to share with rest of our codebase.
export const analytics = AnalyticsBrowser.load({ writeKey: '<YOUR_WRITE_KEY>' })
const App = () => (
<div>
<button onClick={() => analytics.track('hello world')}>Track</button>
</div>
)
Vue
- Export analytics instance.
import { AnalyticsBrowser } from '@segment/analytics-next'
export const analytics = AnalyticsBrowser.load({
writeKey: '<YOUR_WRITE_KEY>',
})
- in
.vuecomponent
<template>
<button @click="track()">Track</button>
</template>
<script>
import { defineComponent } from 'vue'
import { analytics } from './services/segment'
export default defineComponent({
setup() {
function track() {
analytics.track('Hello world')
}
return {
track,
}
},
})
</script>
Support for Web Workers (Experimental)
While this package does not support web workers out of the box, there are options:
-
Run analytics.js in a web worker via partytown.io. See our partytown example. Supports both cloud and device mode destinations, but not all device mode destinations may work.
-
Try @segment/analytics-node with
flushAt: 1, which should work in any runtime wherefetchis available. Warning: cloud destinations only!
How to add typescript support (snippet users only)
-
Install npm package
@segment/analytics-nextas a dev dependency. -
Create
./typings/analytics.d.ts
// ./typings/analytics.d.ts
import type { AnalyticsSnippet } from "@segment/analytics-next";
declare global {
interface Window {
analytics: AnalyticsSnippet;
}
}
- Configure typescript to read from the custom
./typingsfolder
// tsconfig.json
{
...
"compilerOptions": {
....
"typeRoots": [
"./node_modules/@types",
"./typings"
]
}
....
}
🔌 Architecture & Plugins
- See ARCHITECTURE.md
🐒 Development
First, clone the repo and then startup our local dev environment:
$ git clone git@github.com:segmentio/analytics-next.git
$ cd analytics-next
$ nvm use # installs correct version of node defined in .nvmrc.
$ yarn && yarn build
$ yarn test
$ yarn dev # optional: runs analytics-next playground.
If you get "Cannot find module '@segment/analytics-next' or its corresponding type declarations.ts(2307)" (in VSCode), you may have to "cmd+shift+p -> "TypeScript: Restart TS server"
Then, make your changes and test them out in the test app!

FAQ
What is @segment/analytics-next used for?
Analytics Next (aka Analytics 2.0) is the latest version of Segment’s JavaScript SDK - enabling you to send your data to any tool without having to learn, test, or use a new API every time.
How can I tell if a website is using @segment/analytics-next?
Open the page in Chrome with the Sourcemap Explorer extension installed and read the Stack tab. We catch `@segment/analytics-next` from two complementary signals: `node_modules/@segment/analytics-next/` paths inside the JavaScript sourcemap, and the embedded `package.json` we read for exact-version detection. Without the extension you can do the same lookup manually in DevTools — the steps are listed in the "How Sourcemap Explorer detects" section above.
How do I find out which version of @segment/analytics-next a website is running?
Read it straight from the site's JavaScript sourcemap. When a build ships source maps, the bundled `@segment/analytics-next/package.json` carries the exact `version` string — Sourcemap Explorer extracts it in one click on the Stack tab, and you can do it by hand in DevTools by opening the `.map` file and searching for `node_modules/@segment/analytics-next/package.json`. That is far more reliable than inferring the version from an asset-hash or a `?ver=` query string, which is all surface-level detectors have to go on. The current npm release is 1.84.3, but real deployments frequently run an older pinned version — which is exactly why reading the bundled number matters.
What is the latest version of @segment/analytics-next?
1.84.3, as published on the npm registry. The "Recent versions" table on this page lists the most recent 8 releases with their release dates. Sourcemap Explorer reports the version actually bundled into a site, which can lag the latest release by months on real-world deployments.
Is @segment/analytics-next actively maintained?
Very actively maintained — the last release shipped within the past three months. The last published release was 2026-09-11. Source code: https://github.com/segmentio/analytics-next.
Where can I read more?
Project homepage: https://github.com/segmentio/analytics-next#readme. Source code: https://github.com/segmentio/analytics-next. Published on npm: https://www.npmjs.com/package/@segment/analytics-next. Licensed as MIT.
Detected by Sourcemap Explorer
When a bundle ships sourcemaps, we read the embedded package.json for @segment/analytics-next and report the precise version (the registry's latest is v1.84.3, published 2026-09-11; the bundled copy is often older). Without sourcemaps, an import / require in the page's scripts is enough to flag it.