Frequently Asked Questions

Common questions asked about analytics

Do I need to use a plugin?

No, analytics will work out of the box without any plugins attached. However the data from page, track, and identify calls won't send information anywhere.

You can attach your own data collection method via an inline plugin

  name: 'custom-analytics-plugin',
  page: ({ payload }) => {
    const customAnalyticsEndpoint = ''
    const { meta, properties, anonymousId, userId } = payload
    // Send data to custom collection endpoint
    fetch(customAnalyticsEndpoint, {
      method: 'POST',
      body: JSON.stringify({
        date: meta.ts
        title: properties.title
        anonymousId: anonymousId,
        userId: userId,

How much bundle size will this add?

The analytics package is ~13.2kb minified + gzipped

If you are not persisting data in localStorage or cookies, you can use @analytics/core. This brings the pkg down to ~12.6kb minified + gzipped.

How is this different than Segment?

Segment's analytics.js is a great open-source project & a big inspiration behind the analytics package. The analytics package can work with segment's existing library.

This library focuses solely on the javascript ecosystem, while Segment offers a wide array of server-side analytic tools & SDK in other languages.

This library can send analytics & telemetry anywhere, it's easy to send data to & to any other analytics provider or your own backend. So, if you are using, this library works with it via the segment plugin.

Let me repeat that, this library is compatible with Segment's analytics.js via the segment plugin. 🎉

Below are some other considerations that lead to the creation of this open source analytics package:

1. Cost

Segment can get prohibitively expensive for marketing sites, blogs, and higher traffic applications. This makes it harder to use out of the box.

This lead the creation of the segment plugin & the disableAnonymousTraffic setting to lower Segment MTU bills.

It is possible to self host analytics.js but this leads to some of the other points below.

2. Library size

Segment's analytics.js is a much larger codebase. This analytics package was designed to be more modular, lightweight and tree shakable.

For a quick comparison of sizes:

3. Functional Codebase

analytics is designed as a functional code base with minimal dependancies.

4. Extensibility

In many cases, Segment's analytics.js wasn't as flexible as we'd hope for some business use cases.

Some Examples:

  • Manipulating data specific ways for specific providers,
  • Changing how data is persisted
  • Reacting to more events
  • etc.

This analytics library was built to account for a wide variety of use cases making nearly everything customizable via it's middleware design.

Event's can be hooked into, payloads can be altered, called can be cancelled if certain criteria isn't met, and even other plugins can be hooked into.

5. Debuggability & developers experience

The Segment live debugger is great but I wanted a way to visualize + time travel debug analytics as I flow through my applications. This lead to the creation of debug mode with analytics

Does this work in browsers & on the server?

Yes, analytics was designed to work in browsers AND server-side for JavaScript runtimes.

Other questions

Tweet Questions @DavidWells or leave them in an issue