kapa.ai

Yes, this is possible in Mixpanel Insights, particularly when using a table chart or line chart with a breakdown applied.

Here's how it works:

When you have a line chart with a breakdown and a year-on-year comparison applied, the accompanying data table can be sorted by clicking column headers. You can click on a column (such as the comparison/lift column) to sort, and click again to reverse the order — allowing you to surface the segments with the biggest decline at the top. [Sorting Line Chart]

The table chart offers more flexible sorting options. You can:

If you enable "Percent Change over Baseline" (lift mode) in your time comparison, you'll see the percentage change for each segment, and you can then sort ascending by that lift value to show the largest YoY declines at the top. [Sorting; Comparisons]

There are several ways to check the properties of your custom event in Mixpanel:

The Events report lets you see events and all their properties in real time as they flow into your project. [Debugging guide]

Lexicon (Data Management > Lexicon) is Mixpanel's data dictionary and shows metadata for all your events and their properties, including display names, descriptions, example values, and status. [Lexicon overview]

The User Profile Activity Feed lets you inspect all events for a specific user, including their properties, in chronological order. [QA & data audit]

If you're testing a web implementation, the Mixpanel Data Inspector browser extension shows events and their full JSON payloads in real time as they're sent from your site. [Data Inspector]

Key things to verify when checking properties:

Great question! The tip about consolidating queries refers to using the Segmentation API with a where filter expression, so you can query multiple events or filter conditions in a single API call instead of making separate requests.

Here's a practical example using the Query API. Suppose you want to count events for both "Purchase" and "Add to Cart" in one query, filtered by a property (e.g., country == "US"):

Instead of making two separate API calls (one per event), you can use JQL to combine them into a single query:

function main() {
  return Events({
    from_date: params.start_date,
    to_date: params.end_date,
    event_selectors: [
      { event: "Purchase" },
      { event: "Add to Cart" }
    ]
  })
  .filter(function(e) {
    return e.properties.country == "US";
  })
  .groupBy(["name"], mixpanel.reducer.count());
}

This single query:

[JQL params example; groupBy docs]

Alternatively, if you're using the Segmentation REST API (not JQL), you can use the where parameter with an expression like:

where=properties["country"] == "US"

But note the Segmentation API only accepts a single event per call (event parameter), so for multiple events, JQL is the better approach to truly consolidate into one query. [Query API; rate limits]

The knowledge sources I have access to don't contain specific information about why you might see two mp_ cookies from the same domain in Mixpanel.

However, based on what the docs do mention, here are a couple of relevant configuration points that could be worth investigating:

For a definitive answer on duplicate mp_ cookies, I'd recommend:

Sorry Mohamad Q., I don't have permission to access files in this workspace. Please ask a workspace admin to reinstall the kapa.ai bot to grant the required permission.

Funnels and Flows are complementary but distinct reports in Mixpanel:

Funnels measure conversion through a predefined sequence of events within a set time window. You define the specific steps in order, and Mixpanel calculates how many users completed each step, where they dropped off, and how long conversion took. [Funnels Overview]

Key characteristics:

Flows identify the most frequent paths users actually take to or from any event — without requiring you to predefine every step. It's an exploratory tool that reveals organic user behavior. [Flows Overview]

Key characteristics:

The two reports are designed to complement each other. From within a Funnels report, you can click any step and select "View as Flow" to explore what dropped-off users did instead, or what paths converted users took — bridging structured conversion analysis with open-ended path exploration. [View as Flow]

In short: Funnels answer "how well are users converting through a known sequence?" while Flows answer "what paths are users actually taking?"

Even if your observed ratio appears to be 50/50, an SRM alert can still fire if the imbalance is detected at a statistically significant level — meaning even a small but consistent skew can trigger it.

The knowledge sources don't go into further detail about why an SRM alert might appear despite an apparently balanced split, but based on what's documented, here are the most likely explanations to investigate:

The recommended course of action remains the same regardless: pause the experiment, investigate the root cause, and restart after fixing it. [Advanced Statistical Methods]

For a deeper diagnosis, I'd recommend checking whether your exposure event ($experiment_started) is firing at the right moment and consistently for both variants — not at assignment time, but at actual exposure. [Experiments]

An "imbalance alert" in the context of Mixpanel Experiments refers to a Sample Ratio Mismatch (SRM) — a health check that Mixpanel runs automatically on all experiments.

What triggers an SRM (Imbalance) alert?

You get this alert when the actual distribution of users across your variants doesn't match your configured split in a statistically significant way. For example, if you set up a 50/50 split but end up with 60% in control and 40% in treatment, Mixpanel flags this as a potential problem. [Health Checks]

Mixpanel uses a Chi-squared test to determine whether the observed imbalance is likely due to random chance or signals a real issue. [Health Checks]

Common causes

What should you do?

The recommended action is to:

💡 As noted in the previous conversation, enabling CUPED can help mitigate the impact of pre-existing group bias, but it doesn't fix a broken randomization setup — that needs to be resolved at the source.

Great question. The knowledge sources don't directly address whether segmenting new vs. existing visitors replaces the need for CUPED, but here's what the documentation does tell us that's relevant:

What CUPED does:

CUPED reduces variance by accounting for how users were already behaving before the experiment. It helps isolate the true treatment effect by controlling for pre-existing behavioral differences between groups — not by segmenting users, but by adjusting the outcome measurement. [CUPED]

Where your segmentation approach helps:

Monitoring new and existing visitors separately is a sound practice — it avoids survivorship bias and surfaces different behavioral patterns. The documentation explicitly recommends using segmentation (e.g., new vs. returning users) to understand nuances in experiment results. [Reading Results]

Why CUPED may still be useful:

Bottom line: Segmenting new vs. existing visitors and using CUPED serve different purposes — they're complementary, not interchangeable. Segmentation helps you analyze subgroups correctly; CUPED helps you detect real effects faster within a group by reducing noise. The knowledge sources don't state that one eliminates the need for the other.