The knowledge sources do not explicitly mention a standalone "Sign in with Google" button on the standard Mixpanel web login page or why it might disappear. Mixpanel’s standard login process uses Magic Link authentication by default (where you enter your email address and receive a login link) or standard Password Login [Login Methods]. However, depending on your organization's configuration, here are reasons you might not see expected login options:
Required Single Sign-On (SSO): If your organization has enabled Require Single Sign-On, users under claimed domains are required to authenticate through your identity provider (such as Google Workspace SAML SSO) and will not be able to log in using standard methods [Single Sign-On; Setup Google Workspace SSO].
Browser extensions or ad blockers: Content blockers, privacy tools, or ad blockers can sometimes interfere with third-party authentication scripts or embedded elements [FAQ; Frequently Asked Questions]. Disabling ad blockers or testing in an incognito/private window may help determine if an extension is hiding the button.
If you are trying to log in using Google Single Sign-On (SSO), ensure you initiate login through your organization's designated SSO flow or enter your company email so Mixpanel can route you to Google Workspace SAML authentication [Setup Google Workspace SSO].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
This highlights the exact downside of using an Any Order funnel that includes an asynchronous server event: when step ordering is relaxed to accommodate a delayed attribution event, you lose the clean, chronological step-by-step drop-off analysis of your actual product flow [Ordering; Funnels Quickstart]. Here is how you can still measure sequential drop-offs without letting the broken sequence ruin your funnel:
1. The Better Architecture: Decouple Attribution from Steps and Use User Profile Properties
To get a true step-by-step drop-off report, your funnel steps should only reflect the user's chronological actions, not background partner events [Ordering; Retain Your Users].
Step 1: Login Completed
Step 2: Playback Started
Step 3: Subscription Purchased
Because this sequence matches the actual user journey, you can keep the funnel in Specific Order [Ordering]. Mixpanel will clearly show:
Conversion rates from step to step [Funnels Quickstart].
Exactly which step users dropped off at [Funnels Overview; Retain Your Users].
How long it took users to convert from one step to the next [Funnels Overview].
How to filter by campaign without breaking the sequence: Instead of relying on event property backfilling between steps, ingest tracker_campaign_id as a User Profile Property (via your backend webhook/callback or API) [Webhooks]. User profile properties attach to the user record rather than an event, allowing you to filter or break down the entire sequential funnel by tracker_campaign_id without introducing an artificial step that disrupts the order.
2. If You Must Use "Any Order": Use Anchored Steps
If you cannot set user profile properties and must keep __START__ in the funnel steps, you can still preserve sequence for the remaining steps using Anchors [Ordering]:
In an Any Order funnel, you can click on a step number to turn it into an anchored step [Ordering].
An unanchored step (marked with an asterisk *) can be performed in any order, while an anchored step (marked with a number) must happen in its designated place before subsequent anchored steps [Ordering].
You can leave __START__ unanchored so it can arrive at any point, while anchoring Playback Started and Subscription Purchased so you can still track whether users dropped off between those core product actions [Ordering].
Additionally, when you use an Any Order funnel, you can switch the visualization to Top paths (Sankey visualization) to see the exact paths and sequences users actually took through the steps [Ordering].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, it backfills the property itself along with the value [Property Attribution]. The earlier event does not need to have the property key defined in its payload at all.
How Mixpanel Handles Absent Properties in Funnels
According to Mixpanel's documentation on Property Attribution:
"By default, Mixpanel 'backfills' event properties in instances where properties are sent in later steps of a Funnel but not sent in the earlier steps of the same funnel. This means that the property that is present in later steps of a funnel is appended to the earlier steps of the funnel where it was previously absent" [Property Attribution].
When you choose Last Step Defined attribution in a funnel breakdown or filter:
Even if Login Completed was sent without the tracking_campaign_id property in its payload, Mixpanel will append that property and its value from the later step where it was present [Property Attribution].
It does not require the property key to already exist on the earlier event.
The Requirement for This to Work
For Mixpanel to append tracking_campaign_id to Login Completed:
The event containing tracking_campaign_id (your late-arriving __START__ event) must actually be one of the steps in that funnel conversion [Property Attribution].
Because __START__ arrives later than Login Completed, the funnel cannot be evaluated in strict sequential order. You must set the funnel ordering to Any Order in the Advanced settings so that both events are recognized as part of the funnel regardless of which one arrived first [Ordering].
Once both events are part of the completed funnel, Mixpanel will backfill tracking_campaign_id from __START__ onto Login Completed where it was previously completely absent [Ordering; Property Attribution].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, that is precisely what Mixpanel's backfilling feature is designed to do within a funnel report [Property Attribution].
How It Works
Mixpanel automatically applies backfilling to event properties in funnels:
Borrowing Values from Later Steps: In instances where a property is sent on a later step of a funnel but was completely absent on earlier steps, Mixpanel "backfills" that property value by appending it to the earlier steps where it was missing [Property Attribution].
"Last Step Defined" Logic: When you select Last Step Defined in your funnel breakdown or filter, Mixpanel looks across the conversion journey for the last time that property had a non-null, defined value [Property Attribution]. It then attributes that value to the entire funnel—including the earlier steps that never had the property in their payload [Property Attribution].
The Critical Catch for Your Specific Setup
Backfilling only works across the steps that are actually part of the evaluated funnel conversion [Property Attribution].
If your funnel steps are:
Step 1: Login Completed (payload does not have tracker_campaign_id)
Step 2: Playback Started (payload does not have tracker_campaign_id)
Step 3: Subscription Purchased (payload does not have tracker_campaign_id)
And your Singular __START__ event is completely removed from the funnel steps, then none of the steps in that funnel carry tracker_campaign_id. In that scenario, Mixpanel has no later step to backfill the property from, and the property will evaluate to (not set) [Attribution FAQ].
How to Make Backfilling Work
If you want Mixpanel to populate tracker_campaign_id onto events that do not have it in their payload, you have two options supported by Mixpanel features:
Include the late event using "Any Order": Keep the Singular __START__ event in the funnel, but switch the funnel Conversion Criteria to Any Order [Ordering]. Mixpanel will count the conversion regardless of whether __START__ arrives before or after Login Completed, and Last Step Defined will backfill the tracker_campaign_id from __START__ across the rest of the funnel steps [Ordering; Property Attribution].
Use Borrowed Properties: Mixpanel has a feature called Borrowed Properties [Borrowed Properties]. This allows you to take a property from an event and automatically attach it as a custom property to another event without tracking it explicitly in that event's payload [Borrowed Properties]. Note, however, that borrowed properties take a property from a prior event and apply it to future/subsequent events [Borrowed Properties].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Option 3 does not solve the problem by creating a client-side indicator or signaling the mobile app to unblock and fire events. If you used the webhook to unblock client-side events or queue them in memory, you would encounter the exact same latency, memory risk, and timestamp issues you described. Instead, Option 3 moves the attribution handling entirely to the backend and decouples it from the client app's lifecycle [Webhooks].
How Option 3 Solves the Problem
According to Mixpanel’s documentation on webhook/callback integrations [Webhooks]:
Client Executes Completely Unblocked: Your React Native app does not listen for or wait on any webhook. It mounts normally, passes the partner device ID and Mixpanel distinct_id to your server upon launch/auth, and continues firing all client-side product events (App Launch, Login Completed, etc.) immediately with their natural, real-time timestamps [Webhooks].
Server Receives Attribution Asynchronously: The attribution partner sends the install/conversion attribution data (including campaign properties) via a webhook directly to your backend or data warehouse [Webhooks].
Attribution Ingestion via User Profile Properties: Because your backend holds the mapping between the partner device ID and the Mixpanel distinct_id, your backend sends the campaign data to Mixpanel as a user profile property update (or via a Warehouse Connector) rather than relying on an ordered event [Webhooks].
Why Webhook Delay Does Not Break the Funnel
No Queuing on the Mobile App: Your mobile app never buffers, pauses, or delays firing user events.
Profile Properties are Timestamp-Agnostic in Reports: Unlike event-level properties that depend on step-by-step chronology in strict funnels, User Profile Properties attach to the user record [Webhooks].
When you remove the late-arriving __START__ event from the funnel steps, your funnel simply tracks: Login Completed → Playback Started → Subscription Purchased [Ordering]
When you segment or breakdown this funnel by the campaign property stored on the user profile, the delay in the webhook arriving only affects when that profile property is populated in Mixpanel—it does not invalidate the chronological sequence of the client-side funnel events themselves [Ordering; Webhooks].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Not necessarily—reconfiguring the funnel report will resolve the sequence issue in the UI, but only if the campaign property actually exists on the events evaluated within that funnel [Property Attribution; Attribution FAQ]. Here is why report restructuring alone might not completely solve it without a technical change, and what your options are:
The Limitation of Funnel Restructuring Alone
Mixpanel’s Property Attribution / Backfilling feature operates across the steps defined in the funnel:
It takes a property that is present on a later step of that same funnel and backfills it to the earlier steps where it was absent [Property Attribution].
If you completely remove the Singular __START__ event from the funnel steps, and your product events (Login Completed, Playback Started, Subscription Purchased) do not carry tracker_campaign_id, there is no property value inside that sequence for the funnel engine to backfill [Property Attribution].
If a property is missing across the evaluated events, Mixpanel will categorize those entries under (not set) [Attribution FAQ].
How to Fix It
Depending on whether you want to make technical adjustments or purely UI changes, there are three paths:
Option 1: Pure UI Fix (Use "Any Order" with Anchors)
If you make no code changes and must keep the Singular S2S __START__ event carrying tracker_campaign_id:
Keep the __START__ event in the funnel definition.
Go to the Funnel report's Advanced conversion criteria and change the ordering to Any Order [Ordering].
Anchor the downstream events (like Playback Started or Subscription Purchased) if those specific user steps still need to occur in chronological order [Ordering].
Option 2: Technical/Data Ingestion Fix via User Profiles
Instead of relying solely on event-level properties:
When Singular’s S2S payload arrives (or via your backend/webhook), set tracker_campaign_id as a User Profile Property ($set) on that user’s distinct_id [Identity Management Overview; Webhooks].
In the Funnel report, remove __START__ as a step entirely.
Filter or break down your funnel using the User Profile Property tracker_campaign_id rather than the event property. Because user profile properties apply across the user’s entire history regardless of event timestamp order, all funnel steps will reflect the campaign.
Option 3: Backend Webhook / Warehouse Mapping
As noted in Mixpanel's documentation for mobile attribution, you can route the partner's data via webhooks to your server or data warehouse, map the partner ID to the Mixpanel distinct_id, and ingest the attribution data directly to Mixpanel's APIs or via Warehouse Connectors [Webhooks]. This gives you full control over how and where the properties are attached without touching the mobile app code [Webhooks].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
The criticism is completely fair: blocking or pausing client-side tracking to wait for attribution callbacks should not be done, especially in environments like iOS where App Tracking Transparency (ATT) delays can introduce significant latency or cause dropped events [Mobile Attribution]. Mixpanel’s documentation explicitly describes the SDK-to-SDK callback as an asynchronous query rather than a blocking queue [SDK to SDK]. However, even with an asynchronous callback, if the goal is to attribute early product actions (App Launch, Login Completed), waiting for client-side resolution risks missing early events or having them fire before the attribution parameters ever arrive.
Why Solution 1 (Property Backfilling / Last Step Defined) Is the Better Architecture
For your architecture, Solution 1 is indeed the correct and robust path forward:
Non-Blocking Client Execution: Your React Native app fires product events (Login Completed, Playback Started, Subscription Purchased) immediately on mount without altering the component lifecycle, buffering, or risking event loss [Client-Side Tracking].
Decoupled Steps in Funnels: By removing the late-arriving partner S2S event from Step 1 and restricting the funnel steps solely to actual user actions, you prevent the chronological sequence breakage and the resulting 0% conversion drop [Ordering; Funnels FAQ].
Query Engine Handles the Latency: Mixpanel’s query engine natively resolves the out-of-order latency using Last Step Defined property attribution [Property Attribution]:
By default, Mixpanel "backfills" event properties present in later steps/events to earlier steps of the same funnel where they were absent [Property Attribution].
Selecting Last Step Defined applies the last non-null defined property value (such as tracker_campaign_id) across the whole funnel, allowing you to filter or break down the entire conversion path cleanly without any client-side delays [Property Attribution].
Why the Docs Mention SDK-to-SDK
The knowledge sources highlight SDK-to-SDK and Webhook approaches primarily as alternatives to direct Partner Server-to-Mixpanel integrations to avoid common server-to-server pitfalls: namely, identifier mismatches and duplicate/hidden profiles caused by partners sending events with unmerged distinct IDs [Mobile Attribution; SDK to SDK]. However, the knowledge sources do not explicitly address the iOS ATT 300-second window or provide guidance for client-side event buffering during ATT authorization prompts. Given those mobile realities, prioritizing Solution 1 (Property Backfilling via Last Step Defined) or Webhooks to a Warehouse Connector avoids client-side blocking entirely and lets Mixpanel handle attribution at query time [Property Attribution; Webhooks].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
In this context, an SDK-to-SDK integration is an architecture where your mobile application leverages both the attribution partner’s SDK and Mixpanel’s SDK directly on the client device, rather than having the partner's servers forward events to Mixpanel [Mobile Attribution; SDK to SDK].
How It Works
Install both SDKs in the app: You install both the attribution partner's mobile SDK and the Mixpanel SDK in your application [SDK to SDK].
Query attribution data asynchronously: When the app launches for the first time, you use the attribution partner's SDK to fetch or query the attribution data asynchronously on the device [SDK to SDK].
Store the data locally: Once received, you check local storage (such as Shared Preferences) to see if you have already stored the attribution data; if not, you save it locally for future use (e.g., to later attach to user profiles when the user authenticates) [SDK to SDK].
Track directly via Mixpanel SDK: You immediately send your install or attribution event with those campaign properties directly through the Mixpanel SDK on the device (e.g., mixpanel.track("install", props)) [SDK to SDK].
Android Example Provided by Mixpanel
Using Adjust as an example partner, Mixpanel illustrates the workflow with the following implementation [SDK to SDK]:
private trackAttribution(AdjustAttribution attribution){
if(isAttributionAlreadyStored()){ //function to check if the data is already on the device
return;// data already stored, nothing to do
}
JSONObject props = new JSONObject();
insertJsonProperty(props, "[Adjust]Network", attribution.network);
insertJsonProperty(props, "[Adjust]Campaign", attribution.campaign);
insertJsonProperty(props, "[Adjust]Adgroup", attribution.adgroup);
insertJsonProperty(props, "[Adjust]Creative", attribution.creative);
storeAttribution(props); //store the data for later user
mixpanel.track("install", props);//send the install event since this is the first time it has been received
}
private void insertJsonProperty(JSONObject props, String name, String value) {
try {
if (value != null) {
props.put(name, value);
}
} catch(JSONException e) { }
}
Advantages
Fewer ID management issues: Because all tracking occurs directly through the local Mixpanel SDK, there is no need to join IDs from separate systems or pass distinct_id back and forth across servers [SDK to SDK].
Highly configurable: You can choose exactly what attribution properties to track and decide how and when to send them to Mixpanel [SDK to SDK].
No extra backend infrastructure: You do not need to maintain server-side pipelines or webhook receivers [SDK to SDK].
Disadvantages
Requires more implementation work in the app codebase compared to server-to-server integrations [SDK to SDK].
Any adjustments, pauses, or changes to the tracking logic require releasing an app update [SDK to SDK].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, this situation is very clear: because your attribution partner’s server-to-server event arrives with latency, placing it as Step 1 in a Specific Order funnel breaks the funnel calculation. In Mixpanel, funnels in specific order evaluate steps chronologically; any event placed in Step 1 that carries a timestamp later than Step 2 (Login Completed) will cause the user to be treated as dropped off, resulting in a 0% conversion rate [Ordering; Funnels FAQ].
Have others been in this situation?
Yes. Tracking source and channel data for mobile app installs is a known industry challenge [Mobile Attribution]. Because users go through app stores and mobile attribution partners (MMP) before or during their journey, mapping that data asynchronously often leads to delays, race conditions, and identity-joining issues when relying strictly on partner server-to-server integrations [Mobile Attribution].
How does Mixpanel recommend solving it?
Mixpanel provides two primary ways to address this: an architectural tracking change (recommended) and report-level configurations within the Funnels UI.
1. The Recommended Tracking Architecture: SDK-to-SDK Integration
Mixpanel notes that partner server-to-server tracking can lead to ID management and synchronization friction, and instead recommends using SDK-to-SDK or Webhooks as the best fit in terms of configuration and correctness [Mobile Attribution]. With the SDK-to-SDK approach [SDK to SDK]:
When your app launches for the first time, you use the attribution partner's mobile SDK to query the attribution data asynchronously on the device [SDK to SDK].
Once the device receives the attribution parameters, you store them in local storage (or shared preferences) and track an install or attribution event directly through the Mixpanel SDK [SDK to SDK].
Because tracking happens through the client-side Mixpanel SDK alongside other in-app events, you avoid out-of-order server-to-server ingestion and cross-system identity-joining issues [SDK to SDK].
2. Resolving It Inside the Funnel Report (Without App Changes)
If you must keep your existing server-to-server event setup and cannot change client-side tracking, you can restructure how the funnel is configured in the Mixpanel UI:
Remove the attribution event as a step and use Property Attribution (Backfilling): Do not include the late-arriving server event as Step 1. Instead, build the funnel purely around product actions:To filter or break down the funnel by marketing campaign (tracker_campaign_id), use Mixpanel's Last Step Defined property attribution [Property Attribution]. By default, Mixpanel "backfills" event properties present in later steps/events to earlier steps of the same funnel where they were absent, allowing the campaign property from a later event to be attributed across the entire funnel [Property Attribution].
Step 1: Login Completed
Step 2: Playback Started
Step 3: Subscription Purchased
Use "Any Order" Funnels with Anchored Steps: If you must keep the server event as an explicit funnel step, expand the "Advanced" menu in the funnel's Conversion Criteria and switch the order to Any Order [Ordering]. In an Any Order funnel, users can complete unanchored steps in any sequence within the conversion window and still count as converted [Ordering]. You can anchor subsequent steps (such as Subscription Purchased) to ensure the downstream product steps remain strictly ordered [Ordering].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Yes, this is a well-known architectural challenge in mobile attribution. Tracking app installs and campaign sources across mobile environments is inherently complex because attribution data passes through app stores or third-party partner pipelines, which often introduces latency compared to immediate client-side events [Mobile Attribution; Mobile Attribution]. According to Mixpanel’s documentation, partner integrations generally follow three main patterns, with teams adopting specific architectures depending on how they handle latency and data accuracy [Mobile Attribution]:
1. SDK-to-SDK Integration (Commonly recommended for app tracking)
Rather than relying purely on delayed server-to-server callbacks, many teams leverage the partner’s mobile SDK alongside Mixpanel's SDK directly within the app [Mobile Attribution; SDK to SDK].
When the app launches, the partner SDK queries the attribution data asynchronously on the device [SDK to SDK].
Once received, teams store that data locally (e.g., local storage or shared preferences) and track an install or attribution event directly through the Mixpanel SDK, appending those campaign parameters to subsequent events or profiles [SDK to SDK].
Benefit: It avoids ID-joining and out-of-order server-to-server synchronization issues because all tracking flows through the local Mixpanel SDK instance [Mobile Attribution; SDK to SDK].
2. Webhooks and Data Warehouse Ingestion
For teams that require high accuracy and data transformation, another common route is using partner webhooks (callbacks) [Mobile Attribution; Webhooks]:
The attribution partner sends raw callback payloads directly to the company's backend servers or data warehouse [Webhooks].
The client passes the partner's device ID and the Mixpanel distinct_id to the backend [Webhooks].
The engineering team maps the device ID to the user's distinct_id and imports clean attribution events or user profile properties into Mixpanel via the Ingestion APIs or Mixpanel Warehouse Connectors [Webhooks].
3. Decoupling the Partner Event from Funnel Sequences
When companies do rely on Partner Server-to-Mixpanel integrations, they typically do not place the partner's server-to-server event as Step 1 in a linear funnel. Instead:
They set the funnel steps to mirror only the actual in-app user actions (e.g., Login Completed → Playback Started → Subscription Purchased) [Ordering].
They leverage Mixpanel's built-in Property Attribution (such as Last Step Defined or property backfilling) to filter or break down the entire funnel by the campaign property once the late-arriving event or profile property lands [Property Attribution].
Alternatively, if the attribution event must be included as a step, they switch the funnel ordering to Any Order and anchor downstream steps so the timestamp mismatch does not drop users [Ordering].
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.