kapa.ai

Yes, you can remove teams from a Data View. To manage team access in a Data View:

Note: If you cannot edit the settings or remove teams, ensure that you have Project Owner or Admin permissions and that the Data View does not have Restricted editing controls enabled by another user [Manage Visibility and Editing Controls].

Yes! When adding multiple inline filters to a single event metric in Insights, you can choose whether the query matches all of the filters or any of them by clicking the and/or toggle beside the filters. [Filters doc] However, based on the knowledge sources, this toggle applies globally to all filters on that event — meaning you select either "And all" or "Or any" for the entire set of filters on that metric. There is no indication that you can mix both "And all" and "Or any" logic within the filters of a single event metric at the same time. github.com/mixpanel/docs/…/… If you need more complex logic (e.g., combining AND and OR conditions), consider these alternatives:

There are a few complementary approaches in Mixpanel to measure this:

The Frequency per User measurement in the Insights report is the most direct way to see how many times users performed an event and visualize the distribution.

[Insights Measurements]

The Frequency view in the Retention report shows how frequently users return to perform an action within a time window.

This is particularly useful for understanding habitual engagement (e.g., how many users were active on 5 out of 7 days). [Frequency View]

Once you know your frequency thresholds, you can create Cohorts to segment users by engagement level:

You can then compare these cohorts across other reports to understand what drives deeper engagement. [Cohorts]

In Insights, you can use Total per User with percentile aggregations to define engagement tiers:

[Analyze User Engagement]

Recommended starting point: Use Frequency per User → Distribution in Insights for an immediate view of the engagement spread, then build cohorts from those thresholds to track changes over time.

The knowledge sources don't explicitly address this exact scenario, but based on what's documented, here's what's relevant: Mixpanel's opt-out tools are designed to prevent unconsented user data from being sent at all. If a user hasn't consented, the recommended approach is to either:

For aggregate/anonymous visitor counts without consent, Mixpanel does support a "CNIL exemption"-style approach, but it comes with strict requirements: data must be strictly for audience measurement, not combined with other data, not shared with third parties, and must produce only anonymous statistics. This may limit the depth of analysis available. [Cookies & GDPR] In practice, if you want a total visitor count (consented + unconsented), that aggregate number would typically need to come from an upstream source (e.g., your web server logs, a CDN, or a privacy-exempt analytics tool), since Mixpanel's SDK — when properly configured — won't fire for users who haven't consented. So to directly answer your question: yes, that number generally must come from upstream unless you qualify for and implement an exemption-based tracking approach that meets the strict anonymization requirements. Your legal/compliance team should determine which approach is appropriate for your jurisdiction.

Yes, absolutely. Starting a funnel at a mid-journey event is a valid and recommended pattern in Mixpanel. There is no requirement for a funnel to start at the very beginning of a user journey. By using the final submit button click (Step 6) as Step 1 of your second funnel, you are correctly isolating the denominator to "users who actually submitted", which gives you a clean post-submission success rate independent of the form completion rate. This is a clean separation of concerns:

[Funnels Overview]

In Default mode: It depends on timing. If the user clicks submit, hits the error, fixes their input, and clicks submit again — all within the conversion window — the funnel will look for form_submit_success after the first submit_click. If form_submit_success eventually occurs within the window, the user will be counted as converted, because Mixpanel allows other actions in between funnel steps. [Ordering] Does Optimized Re-entry change anything here? Yes, and it is relevant to your case. Since submit_click (Step 1) may fire multiple times before form_submit_success, Optimized Re-entry will:

"For the first step in a funnel, if there are multiple entries prior to step 2, we consider the most recent entry."

So in a scenario like:

submit_click → form_error → submit_click → form_submit_success

Optimized Re-entry would record the second submit_click → form_submit_success as the conversion, which is the most accurate representation of what happened. [Optimized Re-entry]

💡 Recommendation: Enable Optimized Re-entry for your success rate funnel to correctly handle retry scenarios.

This is a great goal but I want to be transparent about limitations here. For the Success vs. Error split, the cleanest native approach is using Event Comparison at Step 2:

This shows what % of submitters reached each outcome side by side. [Comparison Events] For the "no-outcome" bucket (users who submitted but reached neither success nor error), the knowledge sources do not explicitly describe a native three-way split that guarantees the buckets add up to 100% in a single report. However, you can approximate it by:

Using these three cohorts as metrics in Insights with Formulas would give you the three rates:

Success Rate      = B / A * 100
Error Rate        = C / A * 100
No-Outcome Rate   = D / A * 100

Where A = Unique users who did submit_click. [Insights Formulas]

⚠️ The three buckets should theoretically add up to ~100%, but slight discrepancies may occur due to timing and the dynamic nature of cohort computation.

Your read is correct. The issue is exactly what you identified:

These two numbers operate on completely different time bases, so dividing them produces a meaningless ratio. For example, your cohort may have 10,000 cumulative users while only 50 triggered form_submit_success today, giving you an artificially low and misleading rate. Is Funnels the only reliable way? Funnels is the most reliable approach for this ratio over time because both the numerator and denominator are computed within the same time window and conversion criteria. [Funnels FAQ] However, you can also get a reliable ratio in Insights if you ensure both metrics use the same time window and counting method:

Success Rate = B / A * 100

Where:

This is more reliable than mixing a cohort profile count with an event count, but still less precise than a Funnel because it does not enforce the sequential order (a user could do form_submit_success before submit_click and still be counted). [Funnels FAQ]

💡 Recommendation: Use Funnels as your primary metric for the success rate, and use Insights Formulas only as a supplementary trend view with the caveats above in mind.

In Mixpanel, cohorts are NOT static — they are recomputed dynamically every time they are used in a query. As the documentation states:

"Every time you run a query that uses the cohort, the cohort is freshly computed vs being a static snapshot of users."

[How Cohorts are Computed] This means:

The only case where a cohort remains static is when it is created via a CSV upload:

"Cohorts created using this method are static; they will not update over time, as the associated user property remains unchanged."

[Creating a Cohort via CSV]

💡 Note: When cohorts are used in Cohort Sync, they are recomputed every 30 minutes to send updates (adds/removes) to external destinations. [Cohort Sync]

The best way is to use a Funnel report with the following structure:

Users who dropped off at Step 2 (hit form_error but never reached form_success) are exactly the users you're looking for. To see and save those users:

This is a very important distinction. The formula:

Error Rate = C / A * 100

Where:

This metric tells you what percentage of users who started the form hit at least one form_error — but it says nothing about what happened after. It includes:

So the Error Rate formula does NOT distinguish between users who recovered and those who dropped off.

To measure only users who hit form_error and never completed the form, you need to combine the Cohort approach:

Error + Drop Off Rate = D / A * 100

This gives you the true drop-off rate for users who encountered an error and never recovered. [Cohorts]

💡 Pro tip: Use the Funnel drop-off view to identify and save these users as a cohort, then target them via a CRM integration (e.g., Braze) to re-engage them and help them complete the form. [Cohort Sync]