Mixpanel User Management

Mixpanel permissions span organizations and projects. Use this guide to manage how the collaborator joins, changes, and departs your Mixpanel environments, ensuring proper access governance across your analytics infrastructure.

How Mixpanel Structures Access

Mixpanel implements a dual-layer permission system that provides granular control over who can access what data and perform which operations.

Organization-Level Roles

Organization Owner

• Complete billing and subscription control
• Can transfer organization ownership to another user
• Manages organization deletion (permanent and irreversible)
• Configures organization-wide SSO and SCIM settings
• Controls data residency and retention policies
• Ultimate authority over all projects and members
• Recommendation: Restrict to client finance/IT leadership; collaborators rarely need this role

Organization Admin

• Creates and deletes projects within the organization
• Invites, removes, and manages organization members
• Configures SSO settings and identity provider integrations
• Sets up SCIM provisioning workflows
• Views billing information (cannot modify)
• Manages organization-level integrations
• Typical collaborator use case: When you're managing Mixpanel governance for a client or need to create projects

Organization Member

• No organization-level privileges
• Access determined entirely by project-level roles
• Cannot see other organization members unless they share a project
• Cannot create new projects
• Cannot modify organization settings or billing
• Default for most collaborators: Sufficient when work is scoped to specific projects

Project-Level Roles

Projects are the fundamental unit of data organization in Mixpanel. Each project has its own data, reports, and access controls.

Project Admin

Full control over a specific project:

Data Management:
✓ Define and modify Lexicon (event and property descriptions)
✓ Merge and hide events/properties
✓ Create and manage custom properties
✓ Configure data governance rules
✓ Set up data retention policies
✓ Delete old data or entire datasets

Analysis & Reporting:
✓ Create, edit, and delete reports
✓ Build and share dashboards and boards
✓ Create cohorts and segments
✓ Set up funnels and retention analyses
✓ Configure alerts and scheduled reports

Integrations & Exports:
✓ Configure Data Pipelines to Snowflake, BigQuery, S3
✓ Set up Cohort Syncs to ad platforms (Facebook, Google Ads)
✓ Manage warehouse connectors
✓ Configure webhook integrations
✓ Export raw data

User Management:
✓ Invite users to the project
✓ Assign project roles to other members
✓ Remove users from the project

Project Configuration:
✓ Modify project settings (name, timezone, data residency)
✓ Manage API credentials and project tokens
✓ Configure tracking implementation settings
✓ Set up session replay and product analytics features

When to grant Admin:

• Full implementation and instrumentation projects
• Lexicon management and event taxonomy work
• Data Pipeline configuration and maintenance
• Integration setup with ad platforms or warehouses
• Event schema governance and cleanup initiatives

Project Analyst

Analysis and reporting capabilities without configuration access:

Analysis & Reporting:
✓ Create, edit, and delete their own reports
✓ Build and share dashboards and boards
✓ Create cohorts for segmentation
✓ Build funnels, retention, and flow analyses
✓ Set up alerts for their own reports
✓ Schedule email reports

Data Access:
✓ View all events and properties
✓ Use Lexicon definitions (cannot edit)
✓ Export data to CSV from reports
✓ Access JQL (Mixpanel Query Language) console

Limitations:
✗ Cannot modify Lexicon or merge events
✗ Cannot configure Data Pipelines or integrations
✗ Cannot manage project settings
✗ Cannot invite or remove users
✗ Cannot access API credentials
✗ Cannot configure cohort syncs

When to grant Analyst:

• Ongoing analytics and reporting work
• Campaign performance analysis
• Dashboard creation and maintenance
• Ad-hoc data exploration
• Post-implementation support phase

Project Viewer

Read-only access to existing analyses:

View Access:
✓ View existing reports and dashboards
✓ Filter and slice existing views
✓ See cohort definitions (cannot edit)
✓ Export visible data to CSV
✓ View alerts (cannot create)

Limitations:
✗ Cannot create new reports or analyses
✗ Cannot modify existing dashboards
✗ Cannot create cohorts or segments
✗ Cannot access raw data or API
✗ Cannot use JQL console
✗ Cannot schedule reports

When to grant Viewer:

• Executive stakeholder review
• Compliance-friendly read-only access
• Client teams who consume reports but don't create them
• Temporary audit or assessment access
• Post-engagement historical reference

Comprehensive Permissions Matrix

*Organization Admins can prevent Project Admins from deleting projects

API and Service Account Tokens

Project Tokens

Each Mixpanel project has unique API tokens for data ingestion and querying:

• Project Token: Used for tracking events from client-side implementations
• API Secret: Used for server-side tracking and administrative API calls
• Service Account API Secret: Used for programmatic access to reports and data

Token Characteristics:

• Tokens are project-specific (not user-specific)
• Remain valid indefinitely unless manually rotated
• Can be accessed by anyone with Project Admin role
• Should be stored in secrets management systems (AWS Secrets Manager, HashiCorp Vault, 1Password)

User-Level API Access:

Users can generate personal API secrets for programmatic access:

1. Navigate to Project Settings → Service Accounts
2. Create a service account (Project Admins only)
3. Service account inherits permissions of the creating user
4. API calls authenticate using the service account secret

Critical Security Practice: Rotate all API secrets when:

• A user with Admin access is removed
• A team member changes roles
• A security incident occurs
• Quarterly as part of security hygiene

Access Requests at a Glance

• Add User Access explains how to invite the service account and assign project roles.
• Update Access & Roles covers role adjustments when scopes change or new projects launch.
• Remove User Access details the offboarding workflow and documentation requirements.

Add, Update, Remove - Lifecycle Overview

Add User Access

When to Add:

• New collaborator onboarding for analytics implementation
• Consultant joins for instrumentation audit or optimization
• Third-party agency requires dashboard access
• New team member hired for analytics function
• Contractor begins project-based engagement

Prerequisites:

1. Approved IAM ticket or access request form
2. Defined scope of work specifying required projects
3. Security attestation (NDA, training completion)
4. Determination of organization vs. project role needs
5. SSO/SCIM group assignment (if applicable)

Implementation Steps:

1. Determine Organization Role

   • Does the collaborator need to create projects? → Org Admin
   • Will they manage SSO or organization members? → Org Admin
   • Is work scoped to existing projects only? → Org Member (default)

2. Invite to Organization

   • Navigate to Organization Settings → Members
   • Click Invite Member
   • Enter collaborator's email address
   • Select organization role (Owner/Admin/Member)
   • Send invitation

3. Assign Project Access

   • Once invitation is accepted, navigate to Organization Settings → Members
   • Click on the collaborator's row
   • Scroll to Project Access section
   • For each required project:
     • Click + Add Project
     • Select project from dropdown
     • Choose role: Admin, Analyst, or Viewer
     • Consider environment (production vs. staging vs. QA)
   • Save changes

4. Configure Project-Specific Settings

   • For Admin roles: Review which integrations they can access
   • For data-sensitive projects: Verify compliance with data access policies
   • For multi-regional setups: Confirm data residency requirements are met

5. Set Up API Access (if needed)

   • Navigate to project Settings → Service Accounts
   • Create service account for the collaborator
   • Store API secret in your secrets vault
   • Document which integrations will use this secret

6. Verify and Document

   • Ask collaborator to log in and confirm access
   • Export Activity Log showing the access grant
   • Take screenshot of Organization → Members showing assigned projects
   • File documentation in your IAM tracking system
   • Schedule first access review (30, 60, or 90 days out)

Evidence to Retain:

• IAM ticket with approval chain
• Screenshot of organization members page showing project assignments
• Activity log export confirming invitation and role grants
• Email confirmation to collaborator detailing access scope
• Vault reference for any API secrets generated

Update User Access

When to Update:

• New projects launch and the collaborator needs access
• Scope expands to include additional mobile apps or web properties
• Implementation phase completes and access should reduce to reporting-only
• Collaborator takes on Lexicon management responsibilities
• Integration work (Data Pipelines, Cohort Syncs) requires elevated privileges
• Security audit reveals over-provisioned permissions
• Contract amendment changes project coverage
• SSO/SCIM group membership updates

Common Update Scenarios:

Scenario 1: Implementation → Maintenance

Initial State (Months 1-3):
- Org Role: Member
- Web-Production: Admin
- Web-Staging: Admin
- iOS-Production: Admin
- iOS-Staging: Admin
- Android-Production: Admin

Updated State (Month 4+):
- Org Role: Member
- Web-Production: Analyst
- Web-Staging: No Access
- iOS-Production: Analyst
- iOS-Staging: No Access
- Android-Production: Analyst

Rationale: Implementation work complete; ongoing analysis only

Scenario 2: Expand to Data Pipeline Management

Previous:
- Org Role: Member
- Web-Production: Analyst

Updated:
- Org Role: Member
- Web-Production: Admin

Rationale: Now managing Snowflake Data Pipeline; needs Admin to configure exports

Scenario 3: Seasonal Campaign Access

Pre-Campaign (2 weeks before launch):
- Add Project: Holiday-Campaign-2024
- Role: Admin

During Campaign (4 weeks):
- No change; monitor performance

Post-Campaign (1 week after end):
- Holiday-Campaign-2024: Downgrade to Viewer

After 90 Days:
- Holiday-Campaign-2024: Remove Access

Implementation Steps:

1. Document the Change Request

   • Requestor name and justification
   • Specific projects and role changes
   • Effective date and duration (if temporary)
   • Approval from project owner or manager

2. Perform the Update

   • Navigate to Organization Settings → Members
   • Find the collaborator
   • Modify organization role if needed (rare)
   • Update project access:
     • Add new projects
     • Change roles on existing projects
     • Remove access to out-of-scope projects
   • Save changes

3. Handle API Credential Implications

   • If upgrading to Admin: No action needed (expanded access)
   • If downgrading from Admin: Consider rotating project tokens if they had access
   • If removing access: Rotate any service account secrets they created

4. Verify the Update

   • Check Activity Log for confirmation entry
   • Have collaborator test access to ensure expected permissions
   • Verify they can perform required tasks (create report, edit Lexicon, etc.)
   • Confirm they cannot access removed projects

5. Notify Stakeholders

   • Send email to collaborator confirming changes
   • Notify project owners if access was added/removed
   • Update IAM tracking spreadsheet or system
   • Schedule next review date

SSO/SCIM Considerations:

If your organization uses SCIM provisioning:

• Manual changes in Mixpanel may be overridden by next sync
• Update IdP group memberships instead of manual Mixpanel changes
• Verify group-to-role mappings are correct
• Allow 40-60 minutes for SCIM sync to propagate
• Check Mixpanel after sync to confirm expected state

Remove User Access

When to Remove:

• Contract or engagement ends
• Collaborator changes companies or roles
• Security incident requires immediate revocation
• Compliance audit identifies dormant accounts (90+ days inactive)
• Project completes and historical access is no longer needed
• Scope reduction eliminates need for Mixpanel access

Pre-Removal Checklist:

Before removing access, preserve institutional knowledge:

• Export all dashboards and boards created by the collaborator
• Transfer ownership of critical reports to a retained team member
• Document any custom cohorts or segments they created
• Identify alerts and scheduled reports they manage
• List any API integrations using their service account secrets
• Archive any Lexicon documentation or event taxonomy notes

Implementation Steps:

1. Transfer Ownership of Assets

   • Navigate to each board and report owned by the collaborator
   • Change owner to a retained admin or project lead
   • Update scheduled report recipients if needed

2. Document Current Access

   • Export Activity Log filtered by the collaborator's email
   • Screenshot Organization → Members showing all project assignments
   • List all service accounts or API secrets they created
   • Note which integrations (Data Pipelines, Cohort Syncs) they configured

3. Remove Project Access First

   • Navigate to Organization Settings → Members
   • Find the collaborator
   • Remove all project assignments one by one
   • Alternatively, set all projects to "No Access"
   • Save changes

4. Remove Organization Membership

   • After project access is removed, click Remove Member
   • Confirm the removal in the dialog
   • Note: This is permanent and cannot be undone

   Alternative: Keep the account but revoke all access

   • Useful for maintaining audit trail
   • Set all projects to "No Access"
   • Change org role to Member (if they were Admin)
   • Mark account as "Deactivated" in your IAM tracker

5. Rotate API Credentials

   • Identify which service account secrets the collaborator had access to
   • Navigate to Project Settings → Service Accounts
   • Delete service accounts created by the collaborator
   • Rotate project tokens if the collaborator had Admin access
   • Update any integrations using the old credentials:
     • Data Pipelines (Snowflake, BigQuery, S3)
     • Cohort Syncs (Facebook Ads, Google Ads)
     • Reverse ETL tools (Census, Hightouch)
     • BI tools (Tableau, Looker, Mode)

6. Verify Complete Removal

   • Attempt to log in as the collaborator (should fail or show no projects)
   • Check Activity Log for removal event
   • Verify API calls with old credentials return authentication errors
   • Confirm the collaborator's email is not in any SSO/SCIM groups

7. Final Documentation

   • Export final Activity Log entry showing removal
   • File all screenshots and documentation with IAM ticket
   • Update access inventory spreadsheet
   • Send confirmation email to:
     • Collaborator (professional courtesy)
     • Project owners and stakeholders
     • Security/compliance team

Evidence to Retain:

Store in compliance folder (e.g., /compliance/mixpanel/2024/IAM-XXXX/):

• Before/after screenshots of Members page
• Activity Log export showing access removal
• List of transferred assets (reports, dashboards, cohorts)
• List of rotated API credentials
• Email confirmations to all stakeholders
• Final access summary (what they had, why it was removed, when)

Platform Architecture and Practical Considerations

Projects Stay Separate by Design

Mixpanel deliberately keeps projects isolated:

Implications for Access Management:

• When granting access, you must explicitly add each project
• Staging and production are separate projects requiring individual assignments
• Mobile apps (iOS, Android) typically have their own projects
• Multi-brand clients often have one project per brand

Best Practice Workflow:

When onboarding a collaborator:

1. List all in-scope projects (including staging, QA, mobile)
2. Determine the appropriate role for each environment:
   • Staging/QA: Often Admin (for testing)
   • Production: Admin during implementation, then Analyst
3. Create a checklist and verify each project assignment

Example Project Assignment:

Collaborator: jane.smith@agency.com
Contract Scope: Implement web and iOS analytics

Project Assignments:
✓ acme-web-production → Admin
✓ acme-web-staging → Admin
✓ acme-ios-production → Admin
✓ acme-ios-staging → Admin
✗ acme-android-production → No Access (out of scope)
✗ acme-legacy-site → No Access (not in contract)

Lexicon and Data Pipelines Require Admin

Common Pitfall:

An Analyst-role collaborator can create reports and dashboards, but they cannot:

• Edit event or property descriptions in Lexicon
• Merge or hide duplicate events
• Configure Data Pipeline exports to warehouses
• Set up Cohort Syncs to advertising platforms
• Manage custom properties or calculated fields

Solution:

If the collaborator's work includes:

• Event taxonomy cleanup
• Data governance initiatives
• Warehouse export management
• Ad platform integration setup

Then grant Project Admin role, even if 80% of their work is analysis.

Time-Limited Admin Access:

Consider granting Admin temporarily:

1. Grant Admin for 2-week implementation sprint
2. Collaborator configures Lexicon and Data Pipelines
3. Downgrade to Analyst for ongoing reporting work
4. Document the temporary elevation in IAM ticket

API Tokens and Service Accounts Linger

The Problem:

• Project tokens persist even after a user is downgraded or removed
• Service account secrets remain valid unless explicitly rotated
• Data Pipelines continue using old credentials
• Cohort Syncs to ad platforms keep running with outdated tokens

Real-World Scenario:

1. Collaborator has Admin access, creates a service account
2. Service account is used in Data Pipeline to Snowflake
3. Collaborator leaves, you remove their Mixpanel access
4. Data Pipeline continues working (using lingering token)
5. Collaborator still has the API secret and could query data

Prevention Strategy:

Maintain an inventory of which tokens belong to which users:

Rotation Workflow:

When removing a collaborator who had Admin access:

1. Identify all service accounts they created
2. Generate new service account secrets
3. Update integrations with new credentials:
   • Data Pipelines: Update connection settings
   • BI tools: Update data source configurations
   • Reverse ETL: Update Mixpanel source credentials
4. Delete old service accounts
5. Verify integrations still function
6. Document rotation in compliance evidence

SSO and SCIM Integration

Single Sign-On (SSO)

Mixpanel supports SAML-based SSO for Enterprise plans:

Supported Identity Providers:

• Okta
• Azure Active Directory (Microsoft Entra ID)
• OneLogin
• Google Workspace
• Ping Identity
• Auth0
• Any SAML 2.0 compliant IdP

Setup Overview:

1. Configure in Mixpanel:

   • Navigate to Organization Settings → Security → Single Sign-On
   • Enable SSO
   • Copy the Mixpanel SSO URL (for IdP configuration)
   • Copy the Mixpanel Entity ID

2. Configure in Your IdP:

   • Add Mixpanel as an application
   • Use Mixpanel Entity ID as the Service Provider identifier
   • Set Mixpanel SSO URL as the ACS (Assertion Consumer Service) URL
   • Configure attribute mappings:
     • email → User email address
     • firstName → First name
     • lastName → Last name

3. Upload IdP Metadata to Mixpanel:

   • In your IdP, export SAML metadata XML
   • In Mixpanel, upload the metadata file
   • Test SSO with a test user

4. Enforce SSO (Optional):

   • Enable Require SSO to force all users to authenticate via IdP
   • Non-SSO login methods will be disabled
   • Ensure you have a backup admin account before enabling

Access Implications:

• SSO users are automatically added to the organization as Members
• Project access must still be granted manually (or via SCIM)
• Removing a user from the IdP disables their Mixpanel access
• Mixpanel account persists even after IdP removal (audit trail retained)

SCIM Provisioning

SCIM (System for Cross-domain Identity Management) automates user provisioning:

Capabilities:

• Automatic user creation: User added to IdP → Automatically added to Mixpanel
• Automatic deprovisioning: User removed from IdP → Automatically removed from Mixpanel
• Group-based role assignment: IdP groups → Mixpanel project roles
• Profile synchronization: Name/email changes in IdP → Automatically updated in Mixpanel

Setup with Okta:

1. Enable SCIM in Mixpanel:

   • Navigate to Organization Settings → Security → SCIM
   • Click Enable SCIM
   • Copy the SCIM Base URL and Bearer Token

2. Configure Okta Application:

   • In Okta, navigate to Applications → Mixpanel
   • Go to Provisioning tab
   • Click Configure API Integration
   • Paste Mixpanel SCIM Base URL and Bearer Token
   • Test connection

3. Enable Provisioning Features:

   • Create Users: New assignments in Okta create Mixpanel accounts
   • Update User Attributes: Name/email changes sync automatically
   • Deactivate Users: Unassignment removes Mixpanel access

4. Configure Group Mappings (Advanced):

   • Create Okta groups (e.g., "Mixpanel-Project1-Admins")
   • Map groups to Mixpanel project roles
   • Users in the group automatically receive the assigned role

Group-to-Role Mapping Example:

Okta Group: Mixpanel-WebApp-Admins
→ Mixpanel: Project Admin role on "WebApp-Production" project

Okta Group: Mixpanel-WebApp-Analysts
→ Mixpanel: Analyst role on "WebApp-Production" project

Okta Group: Mixpanel-AllProjects-Viewers
→ Mixpanel: Viewer role on all projects

SCIM Sync Behavior:

• Sync Frequency: Typically every 40 minutes, configurable in IdP
• Manual Sync: Can trigger on-demand sync in IdP
• Conflict Resolution: IdP always wins; manual Mixpanel changes will be overridden

Managing Access with SCIM Enabled:

When SCIM is active:

• To grant access: Add user to appropriate IdP group
• To update access: Change IdP group memberships
• To remove access: Remove user from all Mixpanel-related groups
• Avoid making manual changes in Mixpanel (will be reverted on next sync)

Security and Compliance

Data Access Governance

Principle of Least Privilege:

Grant only the minimum access required:

• Default to Viewer unless analysis is required
• Use Analyst for reporting work
• Reserve Admin for implementation and configuration needs
• Restrict Org Admin to client leadership and platform administrators

Quarterly Access Reviews:

Establish a recurring review process:

1. Generate Access Report:

   • Export member list from Organization Settings → Members
   • Include all projects and assigned roles
   • Note last login date for each user

2. Review Each User:

   • Is their access still justified by current contract/role?
   • Are they still actively using Mixpanel (login within 90 days)?
   • Do they have Admin access that could be downgraded?
   • Are there projects they no longer need?

3. Take Action:

   • Remove dormant accounts (90+ days inactive)
   • Downgrade over-provisioned roles
   • Remove access to out-of-scope projects
   • Document all changes

4. Update Documentation:

   • Export updated Activity Log
   • Update IAM tracking spreadsheet
   • File quarterly review report with compliance team

Multi-Factor Authentication (MFA)

Mixpanel MFA Support:

• Available on Enterprise plans
• Supports TOTP (Google Authenticator, Authy, 1Password)
• Can be required organization-wide or per-user

Enable Organization-Wide MFA:

1. Navigate to Organization Settings → Security
2. Enable Require Multi-Factor Authentication
3. All users are prompted to enroll on next login
4. Users without MFA cannot access Mixpanel

Verify Collaborator MFA:

Before granting Admin or Org Admin access:

1. Check their member profile for MFA status
2. Require MFA enrollment before elevated access
3. Include MFA verification in onboarding checklist

Compliance Evidence

For SOC 2, ISO 27001, GDPR Audits:

Maintain documentation for every access change:

IAM Ticket Contents:

• Requestor and approver names
• Business justification
• Specific projects and roles granted
• Effective date and review schedule
• Collaborator's security attestations (NDA, training)

Evidence Artifacts:

• Screenshot of Organization → Members before change
• Screenshot after change
• Activity Log export showing the change event
• Email notification to collaborator
• Email confirmation from collaborator accepting access

Storage:

• Organize by year and ticket number: /compliance/mixpanel/2024/IAM-XXXX/
• Retain for duration required by compliance framework (typically 7 years)
• Ensure evidence is backed up and access-controlled

Incident Response

Suspected Account Compromise:

If you suspect a collaborator's account has been compromised:

1. Immediate Actions:

   • Remove all project access immediately
   • Rotate all service account secrets they had access to
   • Review Activity Log for suspicious activity:
     • Data exports outside normal hours
     • Changes to Lexicon or project settings
     • Unusual cohort creation or modification

2. Investigation:

   • Export full Activity Log for the user
   • Check for:
     • Login from unexpected IP addresses
     • API calls from unfamiliar sources
     • Excessive data export activity
   • Coordinate with collaborator to verify legitimate activity

3. Remediation:

   • If confirmed compromise:
     • Delete the user account
     • Rotate all project tokens
     • Notify affected project owners
     • File security incident report
   • If false alarm:
     • Restore access
     • Document the investigation
     • Consider IP allowlisting for future protection

4. Post-Incident:

   • Review access controls and strengthen as needed
   • Require MFA if not already enforced
   • Consider implementing IP restrictions
   • Update incident response procedures

Roles to Maintain

Organization Owners and Admins

Ownership Strategy:

• Keep Organization Owner role with client finance/IT leadership
• Avoid granting Owner to external collaborators (irreversible actions)
• Limit Org Admins to 2-3 individuals for security
• Document who has Org Admin and why

When to Grant Org Admin to Collaborators:

• Managing Mixpanel instance for a client (MSP/consulting engagement)
• Need to create projects for multi-brand or multi-product implementations
• Responsible for SSO/SCIM configuration and maintenance
• Handling organization-wide governance initiatives

Time-Limited Org Admin:

• Grant for specific migrations or setup projects
• Set calendar reminder to downgrade after completion
• Document temporary elevation in IAM ticket

Project Admins

Default Role During Implementation:

• Most collaborators need Admin during initial setup
• Required for event taxonomy, Lexicon, and Data Pipeline work
• Plan to downgrade to Analyst once implementation completes

Ongoing Admin Access:

• Collaborators managing integrations (Cohort Syncs, Data Pipelines)
• Teams responsible for data governance and Lexicon maintenance
• DevOps engineers managing API integrations

Analysts and Viewers

Transition from Implementation to Support:

Many collaborators start as Admin and transition to Analyst:

Month 1-3 (Implementation): Admin
→ Event schema design, Lexicon setup, Data Pipeline configuration

Month 4+ (Ongoing Support): Analyst
→ Dashboard creation, campaign analysis, regular reporting

Year 2+ (Advisory): Viewer
→ Periodic performance review, strategic recommendations

Governance Checklist

Onboarding Checklist

For each new collaborator:

• IAM ticket created with approval
• Collaborator signed NDA and security attestation
• Organization role determined (usually Member)
• Project access list compiled:
  • Production projects identified
  • Staging/QA projects identified
  • Role determined for each project (Admin/Analyst/Viewer)
• Mixpanel invitation sent
• Invitation accepted by collaborator
• Project roles assigned
• MFA enrollment verified (if required)
• API access configured (if needed):
  • Service account created
  • Secret stored in vault
  • Integration documented
• Collaborator verified access works
• Activity Log exported
• Screenshot of Members page saved
• Evidence filed in compliance folder
• First review date scheduled (30/60/90 days)
• Access documented in IAM tracking spreadsheet

Quarterly Review Checklist

Every 90 days:

• Export current member list from Mixpanel
• Compare against active contracts/engagements
• Identify dormant accounts (no login in 90+ days)
• Review Admin access:
  • Still required for current work?
  • Can any be downgraded to Analyst?
• Verify project access aligns with contracts:
  • Remove access to completed projects
  • Add access for new projects
• Check SSO/SCIM group memberships (if applicable)
• Rotate service account secrets (if 90+ days old)
• Review API integration inventory:
  • Still active and needed?
  • Using current credentials?
• Document all changes in Activity Log export
• Update IAM tracking spreadsheet
• File quarterly review report with compliance
• Schedule next quarterly review

Offboarding Checklist

When a collaborator departs:

• Pre-removal audit:
  • List all boards, reports, and dashboards they created
  • Identify alerts and scheduled reports they manage
  • Document cohorts and segments they defined
  • List service accounts and API secrets they had access to
• Transfer ownership:
  • Reassign boards to retained team member
  • Update scheduled report recipients
  • Document cohort definitions for future reference
• Remove access:
  • Remove all project assignments
  • Remove organization membership (or set to Member with no projects)
• Rotate credentials:
  • Delete service accounts they created
  • Rotate project tokens (if they had Admin)
  • Update integrations with new credentials
• Documentation:
  • Export Activity Log for the user
  • Screenshot before/after Members page
  • List transferred assets
  • List rotated credentials
• Notifications:
  • Email to collaborator (confirmation)
  • Email to project owners (FYI)
  • Email to security/compliance team
• File evidence:
  • Store all documentation in compliance folder
  • Update IAM tracking spreadsheet
  • Close IAM ticket

API Integration Inventory

Maintain a live inventory of which Mixpanel API credentials power which integrations:

Review this inventory:

• When granting or removing Admin access
• Quarterly as part of access review
• After security incidents
• Before rotating credentials

By maintaining comprehensive governance practices, you ensure that collaborator access to Mixpanel remains secure, auditable, and aligned with business needs throughout the entire engagement lifecycle.