A borrowed property’s value is replaced under the following conditions:
When a more recent source event occurs where the property is set: Borrowed Properties strictly capture the property value from the most recent event where the property is set prior to the target event [Borrowing Mechanics]. For example, if multiple source events occur before your target event, the borrowed value is replaced by the value from the most recent one [Borrowing Mechanics].
When the source event falls outside the 7-day lookback window: Mixpanel applies a fixed seven-day lookback window [Borrowing Mechanics]. If the most recent source event occurred more than 7 days before the target event, the borrowed value is replaced by (not set) [Borrowing Mechanics].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
The provided knowledge sources do not explicitly state whether the virtual Session Start event can be referenced within the formula of a custom property. The documentation explains that custom properties allow you to combine existing properties (event properties and user profile properties) using formula functions, rather than referencing events themselves directly within the custom property formula [Custom Properties]. While you can create custom event properties derived from event properties, the sources do not mention if virtual events like Session Start or their associated properties can be used to construct a custom property definition. However, you can use the Session Start event directly in standard report formulas (such as dividing Page Views by Session Start in an Insights report) [Use Cases; Session Controls in Reports].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, an Event-Based Session can help you determine a landing page, provided that the event you define as the starting event includes the page URL [Event-Based Sessions; Session Properties]. Here is how it works and what to keep in mind:
1. How properties are assigned in Event-Based Sessions
Unlike timeout-based sessions (which look through the session for the first event containing the property), an event-based session defines the session start by a specific event you choose (such as "Page View" or "Login") [Event-Based Sessions; Session Properties]. Mixpanel associates properties onto the virtual Session Start event directly from that starting event [Session Properties].
2. Requirements for tracking landing pages
For the Session Start event to determine the landing page:
Your starting event must be an event fired when a user lands on a page (such as a Page View event) [Use Cases].
That starting event must track the URL property (such as Current URL or $current_url, which is captured automatically by the JavaScript SDK) [Default Properties].
If you configure an event like "Login" as your starting event, but "Login" does not track the URL or happens after a user has already browsed pages, the Session Start event will only reflect the URL where the login action occurred rather than the true landing page.
3. Analyzing the landing page
Once your event-based session has a page-load event set as the starting event, you can build an Insights report, select the Session Start event, and break down by Current URL to see your most common landing pages [Use Cases].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, page views are dedicated events and they do count toward your billing volume.
They are dedicated events: Page view tracking is turned off by default [Track Page Views]. When enabled via the JavaScript SDK (e.g., track_pageview: true) or triggered manually with mixpanel.track_pageview(), Mixpanel sends a dedicated event typically named $mp_web_page_view (or "Page View") along with associated page properties [Track Page Views; FAQ].
They count toward billing costs: Mixpanel's default pricing is event-based and calculates your charges based on the total number of events tracked across your organization's projects [How Mixpanel Pricing Works]. Mixpanel only excludes specific system events and API updates (such as $identify, $merge, or $opt_in) from event calculations; page view events are not excluded and therefore count toward your event allowance [How Mixpanel Pricing Works].
(Note: If your organization is on an MTU-based plan, a page view is a qualifying event that counts an anonymous or identified visitor as an MTU, and it counts toward the total event volume used in the MTU guardrail calculation [MTU billing].)
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
In Mixpanel, the recommended way to define and analyze landing pages with timeout-based sessions is to build an Insights report measuring the Session Start event broken down by the Current URL property [Use Cases].
How it works
Track page views on the web: Ensure each page load captures an event (such as a Page View) using the JavaScript SDK, which automatically tracks the Current URL ($current_url) property [Use Cases; Event Properties].
Property inheritance: For timeout-based sessions, Mixpanel automatically attributes the Current URL property on the Session Start event from the first event in the session where that property is defined [Session Properties].
Breakdown by URL: In your report, select Session Start as your metric and add a Breakdown by Current URL to identify your top landing pages [Use Cases].
Best practices to ensure clean landing page data
Filter out (not set) values: If your project tracks non-web events (such as mobile app activity or server-side events) that do not collect Current URL, filter your report by setting Current URL is set or by filtering to web platforms only [Falsy Values; Event Properties].
Exclude non-user actions: In Project Settings > Overview > Session Settings, exclude background, passive, or server-triggered events (such as backend notifications) from sessions [Session Computation Deep-Dive]. If these events fire before a user lands on a web page, they can inadvertently initiate the session [Session Computation Deep-Dive].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
No, it does not mean that the session had no other events. For timeout-based sessions, Mixpanel assigns properties to the Session Start event by taking the value from the first event in that session where the property is defined [Session Properties]. Therefore, if current_url is (not set), it means that none of the events triggered within that entire session contained the current_url property [Session Properties; Falsy Values]. A session could still have multiple events triggered during its duration; however, current_url will remain (not set) if:
The events came from a source that does not collect current_url: The $current_url property is automatically tracked by the JavaScript (Web) SDK, but is not automatically captured by mobile SDKs (iOS, Android, Unity) or server-side integrations [Event Properties]. If a user triggers several events on a mobile app or via backend APIs, the session will contain events, but none of them will have current_url.
Web events fired without the property: If your web events were tracked in an environment where $current_url was stripped or not populated, none of the events in the session will supply a value for Mixpanel to attribute [Falsy Values].
To verify how many events actually occurred in those sessions, you can check the built-in Session Event Count property on the Session Start event [Session Properties].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, that is correct. Mixpanel AI features are controlled globally at the organization level [Mixpanel Agent FAQ]. As long as the AI setting is enabled in Organization Settings, the Mixpanel Agent is available across all default user roles (Owner, Admin, Analyst, and Consumer) [Mixpanel Agent FAQ; Mixpanel Agent]. Disabling AI features from Organization Settings removes access for all users [Mixpanel Agent FAQ].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Inside the Mixpanel UI, users cannot build entirely custom AI agents from scratch, but you can configure specialized recurring sub-agents known as Agentic Automations [Overview]. Here is how creating and configuring agents works in Mixpanel:
1. In-Product: Agentic Automations (Beta)
Within Mixpanel, you can set up pre-built agent types to run autonomously on your behalf:
KPI Monitoring Automations: You can configure an automation by picking an event metric, setting a schedule (daily, weekly, or monthly), choosing a delivery channel (Slack or email), and providing custom Instructions to guide how the agent interprets and frames its commentary [KPI Monitoring; Add instructions].
Note: More automation types (such as Research, Event-Triggered, and Data Governance) are being explored for future releases [Types of Agentic Automations].
2. Outside the UI: Building Custom Agents via Code
If you want to create truly custom AI agents with their own logic, tools, and workflows, you must do so outside the Mixpanel web interface using:
Mixpanel Headless: A Python SDK that exposes Mixpanel’s capabilities (reports, funnels, cohorts, retention) as typed code, enabling developers to build custom autonomous agents (such as Mixpanel's investigation agent, Mixpanelyst) [Mixpanel Headless: Fully programmable product intelligence for agents and automation; Meet Mixpanelyst: Our first custom agent harness].
Mixpanel MCP: A Model Context Protocol server that lets external AI tools (like Claude or ChatGPT) interact with your Mixpanel data [Use Mixpanel Agent to Go From Question to Decision, Faster; Mixpanel Agent: For teams that want AI to just work].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on Mixpanel's documentation and announcements, Mixpanel Agent includes the following built-in agents and capabilities [What you can do with Mixpanel Agent; Mixpanel Agent: Your always-on analyst]:
Core AI Capabilities
Ask Mixpanel Agent: The conversational in-product analyst that answers plain-language questions, builds reports and multi-chart boards, creates cohorts, and analyzes trends or session replays without manual setup [What you can do with Mixpanel Agent; Ask Mixpanel Agent].
RCA Agent (Root Cause Analysis Agent): Automatically investigates metric shifts and anomalies, saving hours of manual segment slicing [What you can do with Mixpanel Agent; Mixpanel Agent: Your always-on analyst].
KPI Agent (KPI Monitoring Agent): Monitors specified metrics and delivers scheduled digests and alerts (via Slack or email) on a daily, weekly, or monthly cadence [What you can do with Mixpanel Agent; KPI Agent].
Experiments Agent: Helps teams set up, monitor, and interpret A/B test and experiment results in plain language [What you can do with Mixpanel Agent; Core Capabilities].
Additional Specialized Sub-Agents
Behind the scenes, specialized sub-agents handle specific tasks [Mixpanel Agent: Your always-on analyst]:
Dashboard Agent: Assists with generating and managing layouts and content for dashboards and Boards [Mixpanel Agent: Your always-on analyst; Core Capabilities].
Onboarding Agent: Supports onboarding and getting users up to speed with their product analytics workflows [Mixpanel Agent: Your always-on analyst].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
No, this is not possible. In Mixpanel, AI access cannot be restricted to specific individual users or limited to a specific project. According to Mixpanel's documentation:
Organization-wide toggle: Mixpanel AI features are controlled at the Organization level in Organization Settings. Disabling or enabling them affects all users across the organization [Mixpanel Agent FAQ].
MCP Server controls: Similarly, if using the external Mixpanel MCP Server, it must be explicitly enabled at the organization level by an org admin [Security Considerations]. While users can only query projects they already have permission to access, access to the AI capability itself cannot be assigned on a per-user or per-project basis [Security Considerations].
What you can control instead
While you cannot restrict who can open the AI Agent, you can control the data the AI interacts with:
Verified Mode: Admins can enable Verified Mode at the project level to restrict AI features to query only data that has been explicitly reviewed and verified in Lexicon (e.g., verified events, metrics, behaviors, and cohorts) [Verified Mode].
Project Access & Data Views: Users can only interact with projects they have been invited to, and existing project-level permissions remain in effect [Security Considerations; Data Views Overview].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
