Best Practices for Sending Anonymous Events to Mixpanel

Tom G. · 2025-12-16T16:39:24.956Z

I have set up server side tracking on GTM and want to push these events into Mixpanel, the goal being that we can track all website traffic including those that have opted out of cookies by purely tracking "what" happened and not "who" (ie anonymous events for opted out users). My question is what is the best practice for inserting these events in MixPanel? Should we create a new "anon_[randomnumber]" distinctID for every event that we insert? Should we assign all events to an "anonymous" distinctID? Are there are any other options and what is the best practice?

Best Practices for Sending Anonymous Events to Mixpanel | Mixpanel Community

4 comments

· Sorted by Oldest

kapa.ai
APP
·
·
Hi Tom G., Please stand by as I search the Mixpanel knowledge base for an AI-powered answer. I normally take about 15 seconds or so. In case AI cannot answer your question, feel free to reach out to Mixpanel support at mixpanel.com/get-support. If you have follow-up questions for this thread, please tag me again with your question: @kapa.ai <follow-up question> 👋
Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai
kapa.ai
APP
·
·
Mixpanel’s docs don’t describe a special pattern specifically for “cookie‑opted‑out but still tracked anonymously via GTM server‑side,” but they do give clear rules and constraints for distinct_id and anonymous tracking that you can apply.Key points from the docs: 1. Every event must have a distinct_id (except in some hot‑shard edge cases). It’s required for behavioral analysis and must not be one of several disallowed “generic” values like anon, anonymous, null, 0, etc. [Import events; Identity FAQ]2. If an event is not associated with any user, you can set distinct_id to the empty string. Those events will be excluded from all behavioral analysis (uniques, funnels, retention, cohorts). [Import events]3. For server‑side anonymous tracking under the Simplified ID Merge API, the recommended pattern is: - Generate an anonymous ID (e.g. UUID) that persists for that browser/session. - Send it as $device_id on events; Mixpanel will derive distinct_id from $device_id if no $user_id is present. [Server-side identity (Simplified); Understanding Simplified ID Merge]4. Using a single shared value like "anonymous" as distinct_id is explicitly disallowed; that value is on the blocked list. [Import events]Given that, here’s how your options line up against best practices:
Option A – New random distinct_id per event
You could generate a fresh distinct_id for every event, but then: - Mixpanel will treat every event as a different user, so you lose any notion of sessions or per‑user behavior. - This is not recommended anywhere in the docs and defeats most behavioral analysis.Nothing in the docs suggests this as a best practice.
Option B – Single shared "anonymous" distinct_id
This is not allowed: values like anon, anonymous, 0, null, etc. are rejected for distinct_id. [Import events]So you cannot assign all events to "anonymous".
Option C – Proper anonymous IDs (recommended)
The documented server‑side best practice is: - For each anonymous browser/session, generate a unique anonymous ID (e.g. UUID) and persist it server‑side (e.g. via a first‑party cookie or some other non‑cookie mechanism you deem privacy‑compliant). - On each event: - If you’re using Simplified ID Merge, send it as $device_id and let Mixpanel derive distinct_id. [Server-side identity (Simplified); Understanding Simplified ID Merge] - If you’re on the Original API, set it directly as distinct_id. [Server-side identity (Original)]This gives you: - No PII (you control the ID format; it can be a random UUID). - Ability to analyze behavior per anonymous user/session. - Compatibility with Mixpanel’s identity model if you ever decide to merge with logged‑in users later.
Option D – Use empty distinct_id for fully de‑identified events
If you want events that are completely unlinked to any user identity, you can set distinct_id to "" (empty string). Those events will be ingested but excluded from all behavioral analysis. [Import events]This is only useful if you care about raw event counts or downstream processing, not user‑level analytics.---**Practical recommendation based on docs:**- Do not use a single "anonymous" ID. - Do not generate a new ID per event. - Instead, for opted‑out users: - If you still want user‑level but non‑PII analytics, follow the anonymous ID pattern (Option C) with random, non‑PII IDs. - If you want events that are truly unlinked to any user, use empty distinct_id (Option D), understanding they won’t appear in funnels/retention/cohorts.The docs don’t go deeper into consent‑law specifics, so for the exact way you persist or generate those anonymous IDs in GTM server‑side, you’d need to align with your legal/privacy requirements beyond what Mixpanel documents.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Tom G.
·
·
Tim V. opinions on option C here? Seems like we'd be going in circles because a new UUID would generate for each page view
Tim V.
·
·
As discussed agree on option D!
👍1

kapa.ai
APP
·
·
Hi Tom G., Please stand by as I search the Mixpanel knowledge base for an AI-powered answer. I normally take about 15 seconds or so. In case AI cannot answer your question, feel free to reach out to Mixpanel support at mixpanel.com/get-support. If you have follow-up questions for this thread, please tag me again with your question: @kapa.ai <follow-up question> 👋
Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai
kapa.ai
APP
·
·
Mixpanel’s docs don’t describe a special pattern specifically for “cookie‑opted‑out but still tracked anonymously via GTM server‑side,” but they do give clear rules and constraints for distinct_id and anonymous tracking that you can apply.Key points from the docs: 1. Every event must have a distinct_id (except in some hot‑shard edge cases). It’s required for behavioral analysis and must not be one of several disallowed “generic” values like anon, anonymous, null, 0, etc. [Import events; Identity FAQ]2. If an event is not associated with any user, you can set distinct_id to the empty string. Those events will be excluded from all behavioral analysis (uniques, funnels, retention, cohorts). [Import events]3. For server‑side anonymous tracking under the Simplified ID Merge API, the recommended pattern is: - Generate an anonymous ID (e.g. UUID) that persists for that browser/session. - Send it as $device_id on events; Mixpanel will derive distinct_id from $device_id if no $user_id is present. [Server-side identity (Simplified); Understanding Simplified ID Merge]4. Using a single shared value like "anonymous" as distinct_id is explicitly disallowed; that value is on the blocked list. [Import events]Given that, here’s how your options line up against best practices:
Option A – New random distinct_id per event
You could generate a fresh distinct_id for every event, but then: - Mixpanel will treat every event as a different user, so you lose any notion of sessions or per‑user behavior. - This is not recommended anywhere in the docs and defeats most behavioral analysis.Nothing in the docs suggests this as a best practice.
Option B – Single shared "anonymous" distinct_id
This is not allowed: values like anon, anonymous, 0, null, etc. are rejected for distinct_id. [Import events]So you cannot assign all events to "anonymous".
Option C – Proper anonymous IDs (recommended)
The documented server‑side best practice is: - For each anonymous browser/session, generate a unique anonymous ID (e.g. UUID) and persist it server‑side (e.g. via a first‑party cookie or some other non‑cookie mechanism you deem privacy‑compliant). - On each event: - If you’re using Simplified ID Merge, send it as $device_id and let Mixpanel derive distinct_id. [Server-side identity (Simplified); Understanding Simplified ID Merge] - If you’re on the Original API, set it directly as distinct_id. [Server-side identity (Original)]This gives you: - No PII (you control the ID format; it can be a random UUID). - Ability to analyze behavior per anonymous user/session. - Compatibility with Mixpanel’s identity model if you ever decide to merge with logged‑in users later.
Option D – Use empty distinct_id for fully de‑identified events
If you want events that are completely unlinked to any user identity, you can set distinct_id to "" (empty string). Those events will be ingested but excluded from all behavioral analysis. [Import events]This is only useful if you care about raw event counts or downstream processing, not user‑level analytics.---**Practical recommendation based on docs:**- Do not use a single "anonymous" ID. - Do not generate a new ID per event. - Instead, for opted‑out users: - If you still want user‑level but non‑PII analytics, follow the anonymous ID pattern (Option C) with random, non‑PII IDs. - If you want events that are truly unlinked to any user, use empty distinct_id (Option D), understanding they won’t appear in funnels/retention/cohorts.The docs don’t go deeper into consent‑law specifics, so for the exact way you persist or generate those anonymous IDs in GTM server‑side, you’d need to align with your legal/privacy requirements beyond what Mixpanel documents.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Tom G.
·
·
Tim V. opinions on option C here? Seems like we'd be going in circles because a new UUID would generate for each page view
Tim V.
·
·
As discussed agree on option D!
👍1

Best Practices for Sending Anonymous Events to Mixpanel

4 comments

Option A – New random `distinct_id` per event

Option B – Single shared `"anonymous"` `distinct_id`

Option C – Proper anonymous IDs (recommended)

Option D – Use empty `distinct_id` for fully de‑identified events

Option A – New random `distinct_id` per event

Option B – Single shared `"anonymous"` `distinct_id`

Option C – Proper anonymous IDs (recommended)

Option D – Use empty `distinct_id` for fully de‑identified events

4 comments

Option A – New random distinct_id per event

Option B – Single shared "anonymous" distinct_id

Option C – Proper anonymous IDs (recommended)

Option D – Use empty distinct_id for fully de‑identified events

Option A – New random distinct_id per event

Option B – Single shared "anonymous" distinct_id

Option C – Proper anonymous IDs (recommended)

Option D – Use empty distinct_id for fully de‑identified events

Option A – New random `distinct_id` per event

Option B – Single shared `"anonymous"` `distinct_id`

Option D – Use empty `distinct_id` for fully de‑identified events

Option A – New random `distinct_id` per event

Option B – Single shared `"anonymous"` `distinct_id`

Option D – Use empty `distinct_id` for fully de‑identified events