kapa.ai

I'm sorry, but the knowledge sources do not contain enough information to provide a confident answer about shifting a time breakdown within an Insights report to a different timezone than the project timezone. What the knowledge sources do confirm is:

Based on this, the most straightforward option available would be to change your project's timezone to GMT in Project Settings:

This would cause all report outputs (including your hourly breakdown) to display in GMT. However, this would affect all reports in the project, not just the one board.

⚠️ There is no information in the knowledge sources about a way to override the timezone on a per-report or per-board basis within the Insights UI.

For more nuanced options (e.g., per-report timezone offsets), I'd recommend reaching out to Mixpanel Support or checking the Mixpanel Community for the latest guidance.

Thank you for clarifying — you're already using inline filters correctly. Given that setup, here are a few things that could still explain the unexpected results:

With a choice_selected event used for all steps, Mixpanel needs to match the right occurrences of that event in sequence. If a user fires choice_selected events rapidly (e.g., multiple questions in quick succession), the funnel may be matching events out of the intended logical flow — particularly if the conversion window is wide enough to pick up events from a different question path. Check: Tighten your conversion window to reflect the realistic time a user takes to go through your question sequence.

Mixpanel has a built-in two-second grace period where consecutive steps with timestamps within two seconds of each other are considered interchangeable. If your choice_selected events fire very close together, steps could be matched in an unintended order. [Funnels FAQ]

When you break down Step 3 by property D, the breakdown value is determined by property attribution (First Step Defined, Last Step Defined, or per-step). If attribution is pulling the property value from a different step than expected, it could surface values that seem inconsistent with the prior steps. Check: Click on the attribution selector below the funnel chart and ensure it is set to the specific step you want (e.g., "Step 3") rather than "First Step Defined" or "Last Step Defined". [Property Attribution]

I want to be transparent: the knowledge sources don't explicitly address a scenario where inline filters on repeated same-event funnels still produce logically impossible combinations. This may be a nuanced data or implementation issue — for example:

If the above suggestions don't resolve it, I'd recommend reaching out to Mixpanel Support directly, as they can inspect your actual event data and funnel configuration.

The issue you're describing — seeing results for choices that shouldn't be possible given prior selections — is likely related to how your funnel's counting method and property attribution work together. Here are the key things to check and configure:

Make sure your funnel is set to Specific Order, not "Any Order". Specific Order requires each step to be completed in sequence before the next one counts. [Funnel Ordering]

This is likely the most important fix for your situation. You need to apply inline filters to each funnel step to restrict which choice_selected events qualify at each step. For example:

Inline filters are applied pre-query, meaning only events matching the filter criteria are even considered for that step. This prevents events from unrelated questions or invalid choices from being counted. [Funnel Filters]

Without inline filters, Mixpanel may pick up any choice_selected event for a step, regardless of which question it belongs to.

If your choice_selected events share a property that ties them to a specific question flow (e.g., a session_id or flow_id), you can hold that property constant to ensure all steps in the funnel belong to the same user journey through the same question path. [Hold Property Constant]

If you're currently using global filters to try to restrict steps, that's likely why invalid choices are appearing — the funnel calculates first, then filters.

The core fix is to use inline filters on each funnel step to tightly define which choice_selected events are valid at that point in the flow.

Yes, both types of cohorts are kept dynamically updated over time. Here's how it works: Cohorts are computed dynamically, not as static snapshots. Every time you use a cohort in a query, Mixpanel freshly computes the set of users who currently qualify for that cohort at the time the query is run. [How Cohorts Are Computed] This applies regardless of whether the cohort is defined by:

In both cases, the cohort reflects users who qualify as of right now, not a historical snapshot of users who ever qualified. [How Cohorts Are Computed] One important distinction to keep in mind:

Exception — CSV-based cohorts: If you create a cohort by uploading a CSV, that cohort is static and will not update over time, since it's tied to a fixed user property set at upload time. [Creating a Cohort via CSV]

When you apply the "is set" filter to a property on an event, it means you are only including events where that property has a defined, non-null value. In other words, the event must have been tracked with that property present and containing a value — it excludes any events where the property is:

[Falsy Values]

Say you have a Page View event and you filter by Campaign ID is set:

[Falsy Values]

Based on the knowledge sources, I need to be transparent about the limitations of what's documented.

Mixpanel's deduplication logic treats events as duplicates when all four of these match:

"Events with identical values for (event, time, distinct_id, $insert_id) are considered duplicates; only the latest ingested one will be considered in queries." [Ingestion API]

If all four fields match but properties differ, Mixpanel keeps the latest ingested version — which theoretically means the new properties could replace the old ones. However:

The knowledge sources do not explicitly cover:

Given that you previously observed property updates happening within a 10-minute window (from our earlier discussion), but the behavior for older events or property merging vs. replacing is unclear, I strongly recommend:

This is a complex situation with multiple layers. Let me break down each discrepancy.

The extra 1,278 rows (285,313 - 284,035) likely come from late-arriving data that was ingested into the new project independently — not from your import. This can happen if:

"Late data can arrive multiple days later due to a mobile client being offline. The import API can add data to previous days." [Data Sync]

Your imported file had no duplicate $insert_ids, yet the new project shows duplicates. This strongly suggests those duplicate rows came from a separate data source (e.g., SDK, another import, or pipeline) that sent the same events independently — resulting in the same $insert_id arriving via two different ingestion paths.

"Events exported via pipelines (i.e. raw exports) can contain duplicates. Deduplication should be performed using 4 event properties: event_name, time, distinct_id, and insert_id." [Common SQL Queries]

The gap of ~1,363 events between Insights (273,077) and unique $insert_ids (274,440) in the raw export is likely caused by:

Data is exported in UTC from the Raw Export API, but Insights displays data in your project's timezone. Events near the day boundary (midnight) may fall on a different date in Insights vs. Raw Export.

"The from_date and to_date params are interpreted using UTC timezones. For projects created before 1 January 2023, the from_date and to_date params are interpreted using your current project timezone." [Export Methods]

Insights only shows visible events. If any events were hidden via Lexicon, they won't appear in Insights but will still appear in Raw Export.

"Mixpanel exports all events to your destination, even ones that are hidden in the UI via Lexicon." [Data Pipelines FAQ]

Insights may be counting by unique users or sessions rather than total event count, which would produce a lower number.

"It's important to look out for comparisons between unique user count vs. total event count." [Debugging]

"You can also check if you have imported data or if data was ingested later by breaking down a report by the property mp_processing_time_ms." [Debugging]

The most likely root cause is that another data source is also sending events to the new project, creating duplicates with the same $insert_id but arriving via a different ingestion path — bypassing deduplication. I'd recommend contacting Mixpanel Support with these specific numbers for deeper investigation.

You can use Data Classification to restrict access to a specific property within your project. This feature allows you to mark a property as "classified" so only certain users can view it.

For individual users:

For teams:

Yes, that is correct. A user must first be a project member before they can be added to a Data View. As stated in the Data Views documentation, when you click + Add User inside a Data View:

"The modal shows only users that are part of your project."

[Data Views] So the workflow is always:

Alternatively, if you manage users via Teams, you can add a team to a Data View, and all project members within that team will automatically get access to it. [Teams]

Project Users are all members who have access to the entire project and its data. They are assigned a project-level role (Owner, Admin, Analyst, or Consumer) that determines what actions they can perform. [Project Roles]

Data View Users are project members who have been granted access to a specific Data View, which acts as a filtered subset of the project data. [Data Views]