wp-media/wp-mixpanel

WordPress Mixpanel Integration

v1.4.4 2026-08-05 15:47 UTC

Requires

• php: >=7.3

Requires (Dev)

• php-stubs/wordpress-tests-stubs: ^6.5
• phpcompatibility/phpcompatibility-wp: ^2.0
• phpstan/extension-installer: ^1.3
• phpstan/phpstan-mockery: ^2.0
• phpstan/phpstan-phpunit: ^2.0
• roave/security-advisories: dev-master
• szepeviktor/phpstan-wordpress: ^2.0
• wp-coding-standards/wpcs: ^3
• wp-media/phpunit: ^3

GPL-3.0-or-later

• WP Media

Published on Packagist.org on 2026-08-05 15:48 UTC

README

A library for integrating Mixpanel analytics into WordPress projects of Group.One.

Overview

WP Mixpanel provides seamless integration between WordPress and Mixpanel, allowing you to track events in your WordPress projects.

Installation

Via Composer

Add the package to your project using Composer:

composer require wp-media/wp-mixpanel

Configuration

The library is composed of 3 main classes:

• Optin handles the status of the opt-in for analytics
• Tracking is the base class for interaction with Mixpanel
• TrackingPlugin extends the Tracking class with some specific configuration for usage in WordPress plugins

Initialize the Tracking class alone

new WPMedia\Mixpanel\Tracking( $mixpanel_token, $options = [] );

The $mixpanel_token is the token provided by Mixpanel corresponding to the project you want to send data to.

For Group.One, we have a sandbox project and a production project.

The $options parameter is an optional array which can be used to configure further the Mixpanel PHP library configuration.

Initialize the TrackingPlugin in a WordPress plugin

new WPMedia\Mixpanel\TrackingPlugin( $mixpanel_token, $plugin, $brand = '', $app = '' );

• The $plugin is the plugin name + the version
• The $brand and $app are optional, but should be specified based on the analytics requirements of the plugin you implement the library in.

Initialize the Optin class

new WPMedia\Mixpanel\Optin( $plugin_slug, $capability );

• The $plugin_slug is the slug used in your plugin as the prefix for options
• The $capability is the capability required to be able to modify the value of the optin

Usage Examples

Track a simple event without optin

$tracking->identify( $user_id );
$tracking->track( 'Event Name', $properties );

Calling identify() is required to associate sent events with a user ID. The $user_id provided is automatically hashed with the appropriate algorithm.

The track() method takes 2 required arguments:

• The $event_name corresponding to the event name which should be displayed in Mixpanel. Events use Start Case formatting.
• The $properties is an array of properties to associate with the event in the format property_name => value. Properties use small caps formatting and underscores.

Track an event with optin check in a plugin

if ( ! $optin->can_track() ) {
    return;
}

$tracking_plugin->identify( $user_id );
$tracking_plugin->track( 'Event Name', $properties, $event_capability = '' );

The track() method of the TrackingPlugin class is a bit different than its parent:

First, it takes an additional optional parameter $event_capability. By default, the capability required for all events is manage_options. This can be changed in two different ways:

• Using the filter wp_mixpanel_event_capability to modify the value for all events
• Passing the capability as the parameter $event_capability, to set it on a specific event

Second, the method will automatically associate the following properties to the event:

• domain: hashed value of the current hostname
• wp_version: current WP version
• php_version: current PHP version
• plugin: Plugin name and version (set in constructor)
• brand: Brand name (set in constructor)
• application: Application name (set in constructor)

wp_mixpanel_event_capability Filter usage

The filter can takes 3 arguments:

• $capability the capability for all events
• $event the current event name
• $app the current app name

Request behaviour

Events are sent with wp_remote_post() when the in-memory queue is flushed. Requests are non-blocking with a 1 second timeout, and neither value is filterable or configurable: analytics must never delay a response.

Two details are worth knowing:

• 1 second is a floor, not a choice. WordPress clamps the cURL timeout to a minimum of 1 second, so a smaller value would have no effect.
• Non-blocking is not fire-and-forget. WordPress still waits for the endpoint up to the timeout, it only discards the response. The timeout is what bounds the cost of a degraded endpoint.

A failed request is reported through the consumer's error callback and then dropped, not retried, because the producer's retry-on-flush behaviour would multiply the cost of an unreachable endpoint.

Read more about MixPanel at group.one

More information about how MixPanel is used at group.one is available in our internal documentation.