Mixpanel Js Versions Save

This release adds several new capabilities for finer control over (super)properties, event data, and batch sending.

A new persistent option to mixpanel.register() and mixpanel.register_once() allows control over whether to persist the given superproperties beyond the current pageload or not:

// include this prop only with events on the current page, i.e.
// don't put it in the superproperties cookie/localStorage entry
mixpanel.register({'Name': 'Pat'}, {persistent: false});

// default is still true; superproperties will be stored across pageloads
mixpanel.register_once({'Referrer to signup page': 'example.com'});

A new hooks capability supports transforming event data and profile updates just before they are sent over the network:

mixpanel.init('my token', {
  hooks: {
    before_send_events: eventData => {
      eventData.event = eventData.event.toUpperCase(); // normalize event name
      delete eventData.properties['bad prop']; // remove a (super)prop
      return eventData; // always return the new event data, even if you modified it in place like here
    },
  },
});

A new batch_autostart config option and start_batch_senders() method allow finer control over when to start sending batches over the network in request-batching mode. If the SDK is initialized with {batch_autostart: false}, tracked events will queue up without going over the network until mixpanel.start_batch_senders() is called explicitly. This is mainly useful for advanced use cases where you need to enrich events retroactively with data not yet available when mixpanel.track() was called (using a before-send hook).

Request-batching mode has been fixed for configurations that set sendBeacon as the default API transport instead of XHR. Note that since sendBeacon includes no facility for determining whether the request succeeded, there is no retry mechanism for failed requests in this configuration; as long as the browser says it enqueued the beacon call, the batch will be considered successfully sent.

Default-on request-batching has been expanded to 60% of projects.

• Bodies of POST requests are now escaped to ensure that valid Base64 always gets sent to the APIs. This allows custom proxy servers to expect valid Base64 in every case (the mixpanel.com API servers already accepted and handled the technically invalid Base64 chars).
• batch_requests will not default to true if a non-mixpanel.com api_host is specified, to avoid silently regressing existing setups with proxies that don't support batches. Batching can always be forced on by explicitly setting batch_requests: true.
• Default-on request-batching has been expanded to 30% of projects.

This update ensures that, even if a page does not track any events, the standard set of superproperties for UTM parameters and initial referrer are still persisted for use with later events. This behavior used to occur automatically due to tracking the mp_page_view event upon initialization, which was turned off by default in v2.37.0.

With this change, the deprecated track_pageview configuration option has no effect anymore and has been removed entirely.

Automatic tracking of the mp_page_view event is now off by default. This event has been deprecated for years and is dropped by the Mixpanel API servers.

The batch_requests config option now defaults to true for a subset of projects, turning on batch/queue/retry support. To force this mode on or off explicitly, use the {batch_requests: true} option in mixpanel.init(). The default-on configuration will be gradually rolled out to all projects.

This release adds opt-in support for sending events and people/group updates in batched network requests, with backup mechanisms for retrying in case of network failures and other errors. In this mode of operation, calls to mixpanel.track() will not immediately result in a network request; instead the data is placed in a queue, and at regular intervals the available queued data is sent over the network. In cases of network failures, dirty page closures, etc., the queued data remains stored in the browser's localStorage and will be sent in retry requests.

This mode results in fewer network requests and reduces potential data loss in cases where the browser cannot communicate successfully with the Mixpanel API (e.g., when a user loses network connectivity temporarily). It requires that the user's browser supports the localStorage API; if localStorage is not present or functional, the SDK will fall back to the old immediate-request mode.

To enable this mode, initialize the SDK with the configuration flag batch_requests set to true:

mixpanel.init('my token', {batch_requests: true});

Other configuration options are available to control the timing and size of batches:

• batch_size: maximum number of events/updates to send in a single network request (default: 50)
• batch_flush_interval_ms: milliseconds to wait between checking for batch requests to send (default: 5000 = 5 seconds)
• batch_request_timeout_ms: milliseconds to wait for network responses to batch requests before they are considered timed-out and retried (default: 90000 = 90 seconds)

In a future release, this mode will be enabled by default.

Cross-subdomain tracking has been improved:

• main-domain detection on extra-long TLDs (e.g., .company) has been fixed
• main-domain detection on very short .com/.org domains has been fixed
• a new cookie_domain config option allows setting the domain explicitly, for cases where the main domain cannot be picked up accurately by the SDK's heuristics (e.g., subdomain.mainsite.avocat.fr); NB the value of cookie_domain must still match the current page origin, as browsers will refuse to set cookies on other domains

Backwards compatibility has been maintained for existing multi-part domains that were detected correctly in previous SDK versions (e.g., www.oxford.ac.uk).

The new cross_site_cookie config option can be set to true if your Mixpanel implementation is a special case that runs in a 3rd-party context, e.g., in an iframe embedded in someone else's page, or in a browser extension. This will enforce the cookie attributes SameSite=None; Secure (see https://web.dev/samesite-cookies-explained/). For standard implementations this is unnecessary, as the Mixpanel cookie is set on your own domain (i.e., it's a 1st-party cookie).

The new cookie options can be set at initialization time:

mixpanel.init('my token', {cookie_domain: 'foo.bar.baz.com', cross_site_cookie: true});

mixpanel.track() now also explicitly returns false (as a synchronous return value) if it was unable to initiate/enqueue the request successfully. Asynchronous request results are still available through the callback parameter.

New config option ignore_dnt allows you to override the browser's Do Not Track setting and always send tracking requests. Set it with:

mixpanel.init('my token', {ignore_dnt: true});

This release also contains a fix for the SDK's automatic /decide GET requests when the lib is initially configured with option {api_transport: 'sendBeacon'}.

Fixes a regression introduced in v2.33.0 preventing native arrow function track() callbacks from executing, e.g.: mixpanel.track('my event', {}, () => notCalled());. Regular function()s and transpiled arrow functions were unaffected.

This release adds new options to use the (sendBeacon API)[https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon] ("for analytics and diagnostics that send data to a server before the document is unloaded"). This network transport mechanism is useful for "fire-and-forget" tracking without blocking page unload, but comes at the cost of not providing any callbacks or mechanisms for knowing whether the request succeeded. There are several ways to use it for Mixpanel tracking:

// for an individual track() call
mixpanel.track('my event', {my: 'props'}, {transport: 'sendBeacon'});

// turn on for every Mixpanel call when page is unloading
// (you would use this to use sendBeacon for everything, including
// mixpanel.people calls)
window.addEventListener(`unload`, function() {
  mixpanel.set_config({api_transport: 'sendBeacon'});
  mixpanel.track('my event');
  mixpanel.people.set({foo: 'bar'});
});

// initialize for all tracking; not recommended as it will prevent any
// request-retry facilities
mixpanel.init('my token', {api_transport: 'sendBeacon'});
mixpanel.track('my event');

Browser and browser-version detection has also been updated for the new line of Microsoft Edge (based on Chromium) as well as Samsung Internet browser.

• Tracking events and sending profile updates now occurs via HTTP POST by default, with data in the request body, rather than GET with data on the URL.
• Events now include the $insert_id property for deduplication support.
• Malformed URI params in attribution fields like utm_source no longer lead to exceptions.

To force tracking via GET instead of POST, use the api_method config option:

mixpanel.init(TOKEN, {api_method: 'GET'});