Comparison: Mixpanel Actions vs. Mixpanel Classic Destinations when using Segment

This blog was written by Steven Aldrich, the co-CEO of Ragnarok. Ragnarok is a professional services agency that provides strategic and technical guidance, as well as hands-on engineering and analyst support for Mixpanel and Segment.

Since the release of Segment’s Actions destinations in late 2021, there have been major overhauls to the method in which Segment sends data to other Martech tools. Namely, it moves away from a limited, predefined naming convention in favor of more customized and streamlined configuration. Compared to other destinations, the changes reflected in Mixpanel with the launch of Actions are significant; the hope here is to give you clarity on what’s changed and how you can further leverage the power of both tools to enhance your analytics capability.

Actions vs. Classic destinations

Before proceeding on what’s new in the Actions destination, let’s first recap the main structural differences between Classic and Actions. In Classic, the structure of the event is standardized and must be passed in a very specific way for Mixpanel to interpret it correctly. The standard is a basic mapping of Track to Mixpanel’s Event method, Identify to Mixpanel’s People and Identify methods, and Group to Mixpanel’s Group method, with all properties and traits carrying over as either standard or custom Mixpanel properties, depending on how they were named. The data is structured and sent by either having the payload in its correct and final form from the source, or writing a custom Segment function to handle any transformation. 

A good example of the strictness of this naming convention in the Classic destination is represented in collecting and passing UTM parameters server side for marketing campaign attribution. In Classic, it’s required that the parameters be passed in either the traits or properties objects in the following format:

"properties" : {
  "utm_source" : "string",
  "utm_medium" : "string",
  "utm_campaign" : "string",
  "utm_content" : "string",
  "utm_term" : "string"
}

In Actions, the naming of these key/value pairs are not as critical (see figure 1), as they can map to any object based on whatever naming parameters you desire.

Figure 1: Actions destination configuration for specific Mixpanel standard properties.

While this appears to be a quality of life improvement, it actually helps maintain governance changes and reduces the impact of developer error during implementation, as resolutions can now happen without a code change.

There is one other notable difference in the Actions destination, specifically removing the requirement in Classic to map each individual trait for any Group and Identify calls. These will now happen automatically in the new setup process.

New Capabilities with Mixpanel’s Action Destinations

Beyond the standard transformation that Segment’s Actions framework offers, it’s also packed with additional features to enhance capability for large volume senders, supports Mixpanel’s Ecommerce and revenue reporting, and enables Segment’s new Reverse ETL product.

Batching

Large volume senders can now effectively batch data into Mixpanel, helping to alleviate previous issues around events received out of order due to the processing rate limits. With batching, events will be pulled into the maximum sized batches and sent together, ensuring events are processed in order. Enabling batching is a simple configuration change (see figure 2) and can be configured for specific individual events or for event types.

Figure 2: Data batching enablement features in Segment for Mixpanel Actions destination.

Ecommerce mapping

Whether leveraging Mixpanel’s A/B testing features or diving deep into the value of a specific funnel, mapping specific transaction information will provide a more complete picture of your analysis. Mixpanel prefers to have separate events for each transaction line item in an order, as this allows users to either map a lookup table to a SKU or product_id or to measure the aggregate values of any specific property. 

With the new Actions destination, simply tracking an Order Completed event with each line item as an array of objects in the properties will automatically parse each item into a separate Product Purchased event sent in addition to the Order Completed event. This reduces the amount of development work required, as Segment will only require a summary event. Product attributes can be mapped individually and the Mixpanel Actions destination provides a framework of suggested properties, the most critical of these being product_id, price and quantity (see figure 3). 

After these events are passed in, a simple formula can be leveraged to display the revenue per SKU by multiplying the sum of the price and the quantity, breaking it down by SKU (see figure 4).

Sample JSON sent into Segment

Figure 3: Ecommerce selection options and how it looks in Mixpanel.

{
  "userId": "00001982",
  "event": "Order Completed",
  "properties": {
    "products" : [{
      "name": "Item Sample",
      "product_id" : "12345678",
      "sku" : "SAMP-123",
      "category" : "Sample",
      "brand" : "Ragnarok",
      "variant" : "Blue",
      "price" : 21.99,
      "quantity" : 3,
      "coupon" : "SAMPLE10",
      "position" : 3,
      "url" : "https://www.placekitten.com",
      "image_url" : "https://www.placekitten.com/300/200"
    },{
      "name": "Item Sample 2",
      "product_id" : "12345678 9",
      "sku" : "SAMP-124",
      "category" : "Sample",
      "brand" : "Ragnarok",
      "variant" : "Green",
      "price" : 78.99,
      "quantity" : 5,
      "coupon" : "SAMPLE15",
      "position" : 4,
      "url" : "https://www.placekitten.com",
      "image_url" : "https://www.placekitten.com/400/300"
    }]
  },
  "context": {
    "ip": "24.5.68.47"
  },
  "timestamp": "2022-12-27T21:24:12.984Z"
}

Figure 4: Using Product Purchased in Analysis.

Reverse ETL

Segment’s latest Beta feature enables a sync between Google BigQuery and/or Snowflake to send the records based on written SQL statements; this is an alternative to tracking individual events through a Segment library. The delta values will be synced up automatically to the intended destination; this feature only works with Actions destinations. After setting up a Reverse ETL model, the structure follows a similar pattern to setting up any event or track call based on the values returned in the SQL statement; generally this includes a userId, timestamp, event type (Identify or Track), as well as a mapping for traits, properties, and event names.

How to convert from Classic to Actions

Converting from a Mixpanel Classic destination to an Actions destination is simple. This demo video outlines how to set up Actions in just a few clicks.  The default settings for Actions will largely mimic what’s already available in the limited settings of Classic. The main change is that client side sources will no longer require device-mode configurations, reducing the need to load the Mixpanel SDK side-by-side with the Segment SDK. To complete the shift, simply setup a new Mixpanel destination in the Segment UI for your selected Source, be sure to select Actions from the connection mode, add your project ID and project secret, and Segment will take it from there. Be sure to disable the Classic destination to avoid double-sending events.

About Ragnarok

Founded in 2012, Ragnarok is a seasoned professional services agency that provides strategic and technical guidance, along with hands-on engineering and analyst support for Mixpanel and Segment. Having led over 200+ clients in their Martech integration and investment, Ragnarok boasts a roster featuring prestige brands like A+E Networks, Dropbox, Afterpay and more. Ragnarok works with clients of all sizes, effectively realizing their initiatives and delivering products and experiences that drive incremental revenue for their business. Click here to learn more about Ragnarok.