Skip to content

Non-persistent superproperties, hooks for transforming data, delayed tracking
Compare
Choose a tag to compare
@tdumitrescu tdumitrescu released this 02 Dec 20:32
· 234 commits to master since this release
v2.40.0
f9314b6

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.

Assets 2