Pageview and batch/retry updates

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.

Batch/queue/retry support

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.

Cookie options and improvements for cross-subdomain and cross-site cookies

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.

ignore_dnt option and sendBeacon/GET request fix

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'}.

Fix for native arrow-function track() callbacks not executing

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.

sendBeacon support and User Agent updates

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 infrastructure updates

• 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'});

New default API server

The default API server address has changed from https://api.mixpanel.com to https://api-js.mixpanel.com. Functionality is unchanged.

2.29.1

Fix a race condition for events tracked before notifications are loaded

Improved identity management support

mixpanel.identify() now sends a special $identify event to the API. This is not treated like a regular tracking event, but will aid in future platform improvements to support advanced identity management (linking anonymous and logged-in usage, multiple users on one system, etc.).

This release also contains a fix for accidental non-debug-mode console logging in the Group API module.