Mixpanel
Overview
Section titled “Overview”Signals sends event data to Mixpanel, so the actions your source systems already record can be analyzed alongside everything else in your product analytics.
That is the reason to use it. Mixpanel is where teams look at user journeys, feature adoption and retention, and this connector puts events from your website and store into the same place without an export step.
Mixpanel is an analytics destination rather than an advertising one, which changes what matters. There is no audience to match and no attribution window to respect. What matters is that the event lands against the right person, which is what the primary identifier decides.
Supported sources
Section titled “Supported sources”Prerequisites
Section titled “Prerequisites”Before connecting Mixpanel, make sure you have:
- A Mixpanel account, with the credentials to connect it.
- A Mixpanel project to send the events into.
- A Datahash Studio account with the target project selected.
- A source connected in the same project. Events reach Mixpanel through the source, so a connected destination on its own sends nothing.
- Agreement on what each event is called, since the name you send is the name analysts will see and filter on.
Authentication
Section titled “Authentication”In Studio, open Destinations, find the Analytics category and click the Mixpanel tile. This connector authenticates with credentials you add manually. All five fields are required.
- Enter the Service Account User Name, Service Account Secret, Project Token, API Secret and Project ID.
- Click Next.
| Field | Where to find it |
|---|---|
| Service Account User Name | In Mixpanel, create a service account under your organization settings. The user name is shown when the account is created. |
| Service Account Secret | Shown once at the moment the service account is created. If it was not recorded, create a new service account rather than trying to retrieve it. |
| Project Token | In Mixpanel, under the settings for the project you are sending to. |
| API Secret | In the same project settings as the token. |
| Project ID | In the same project settings. It identifies which project the events land in, so check it matches the project your analysts actually use. |
Configuration
Section titled “Configuration”Three fields, then finish.
| Field | What it is |
|---|---|
| Connection Name | A name for this instance, so it is recognizable in the Manage existing instance table. |
| Source Data Type | Which kind of data from the connected source is sent to Mixpanel. |
| Primary Identifier | The field Mixpanel uses to identify the person the event belongs to, for example a user ID or a device ID. |
Click Finish once they are set. Events start flowing from the connected source to Mixpanel.
Settle the primary identifier before you finish. It decides how events attach to profiles, and changing it later splits one person into two.
Manage instance
Section titled “Manage instance”To change the instance, open it from the Manage existing instance table, click the edit option in the menu to the top right, update the fields and click Finish.
Data & identifiers
Section titled “Data & identifiers”Personal identifiers are hashed on the way to Mixpanel, the same as on every other destination. Send them already hashed where you can. Plain text also works: they are normalized and SHA-256 hashed before they reach Mixpanel.
This is worth planning around, because it is different from how most Mixpanel data arrives. An email address delivered through this connector is a hash rather than a readable address, so it identifies a person consistently without being something an analyst can read. That is why the primary identifier matters: it is what makes a profile recognizable in Mixpanel.
Required
Section titled “Required”| Field | When it is required |
|---|---|
| Event name | Always. This is what the event is called in Mixpanel. |
| Event time | Always. |
| Primary identifier | Always. Whichever field you chose during setup. Without it an event cannot be attached to a profile. |
Best practices
Section titled “Best practices”- Settle the primary identifier before you connect anything. It decides how events attach to profiles, and changing it later splits one person into two.
- Use the same identifier here as your other Mixpanel sources use. Sending a CRM ID from Signals while your SDK sends a device ID produces two profiles for the same person.
- Agree the event names first. They are what analysts filter on, and renaming an event after the fact leaves the old name in every saved report.
- Send only the events someone will actually look at. Mixpanel is priced and read by event volume, so reporting everything makes the useful events harder to find.
Troubleshooting & FAQ
Section titled “Troubleshooting & FAQ”No events appear in Mixpanel. Confirm a source is connected in the same project and sending, and that the credentials point at the project you are looking at. A connected destination on its own produces nothing.
Events arrive but are not attached to a person. The primary identifier is missing on those records. Check the field you selected during setup is populated at source.
The same person appears twice. Two different identifiers are being sent for them, usually because another Mixpanel source uses a different one. Align them.
Events are counted twice. The same file or record has been sent more than once. Check whether the source has re-read a file or re-synced records for a period already delivered.
An analyst cannot read the email addresses on a profile. They arrive hashed, by design. Use the primary identifier to recognize a person rather than a readable address.