Mixpanel vs Heap

How each tool gets data in

Mixpanel's model is that you decide what is worth recording. Its JavaScript SDK documentation shows a track call carrying an event name and a few properties, and it advises against names that contain the reserved $ or mp prefixes. For a B2B product this is where you encode the events that matter to a buyer: workspace created, teammate invited, integration connected, report shared. Mixpanel also supports server-side sending, which is the right path for subscription changes and anything else that happens on your backend.

The same documentation page describes an opt-in autocapture mode, available from SDK version 2.60.0. You turn it on with an autocapture option in the init call, and its defaults record clicks, dead clicks, rage clicks, inputs, scrolls and form submits. Element text is not captured unless you enable it, and you can exclude whole URL patterns or elements with block and allow settings. This changes the usual advice. A Mixpanel team can start with autocapture for exploratory questions and keep explicit events for the handful of numbers that go on a board slide.

Heap's model is that you should not have to decide in advance. Its capture page says one snippet automatically captures every view, click, swipe and form fill, and that teams can add manually defined custom events and server-side events through its APIs. The raw interactions sit in storage until you need them; you then create a virtual event, a readable name that points at the underlying data, and the definition applies back to the moment Heap was installed, according to Heap's own explanation of autocapture. That post is several years old, so confirm in the current product that the behavior you depend on, especially retroactive property snapshots, still works as described.

• If your key product moments are clicks on pages you already ship, Heap lets you count them today without a release.
• If your key moments are server facts (a trial converted, an invoice paid), both tools need you to send them from the backend, so Heap's head start shrinks.
• If your front end is redesigned often, expect to re-point Heap definitions at the new elements, and expect Mixpanel's explicit events to keep working untouched.

Identity: anonymous visitors, logins and companies

Mixpanel derives a distinct ID from a device ID and a user ID. Before login, events carry only the device ID. When you call identify with your internal user ID and then send at least one more event, Mixpanel joins the two into an identity cluster and updates earlier anonymous events, as described in its Simplified ID Merge documentation. Two caveats from that page matter to a SaaS team. A user ID cannot be changed, so an email address is a poor choice. And profile properties you set on the anonymous device ID are not carried over, so set them again after identify. Mixpanel's JavaScript docs also recommend against calling identify for anonymous visitors.

Heap's identify reference describes a string that uniquely identifies a user and must be shorter than 255 characters; applying the same identity on another device merges earlier sessions into the existing Heap user. The page warns that passing a non-unique value such as undefined, null or user merges all anonymous data into one profile, which it says cannot be undone. Whichever tool you choose, write the identify call once, in one place, using your internal database ID.

Companies are the harder half of B2B identity. Mixpanel's Group Analytics lets you choose an event property such as a company ID or billing ID as the counting unit, and its Company Analytics view is aimed at B2B SaaS, with account health and activation measured from underlying user activity. The docs describe it as an add-on package for Growth and Enterprise customers. Heap lists account analytics on Pro, together with the engagement matrix and report alerts, so a team on Free or Growth will be reading user-level charts only.

Funnels and retention in practice

Both tools cover the two reports a B2B team opens first. Mixpanel's funnels report measures conversion through a series of events in a time window and is available on free and paid plans. Its retention documentation offers on-or-after, on, and on-or-before criteria, rolling or calendar windows, custom brackets such as days 15 to 30, and a frequency view that shows how many intervals a user was active in. One limit to plan around: day-level retention is capped at 60 days, so longer questions move to weeks or months.

Heap's charts page groups funnels, journey maps and retention charts together, and its pricing page lists funnels, journeys and retention from the Free plan up. The practical difference is not the chart type but what feeds it. In Heap a funnel step is a virtual event you can redefine and re-run on past data. In Mixpanel a funnel step is an event someone already sent, so a step you forgot to track is empty until you ship the code and wait for new traffic.

Worked example: sessions and events at three sizes

Both prices depend on numbers you can estimate in an afternoon. The example uses two assumptions of ours, not vendor figures: each active user opens the product 4 times a month (four sessions), and each session fires 30 events. Replace both with your own counts. Remember that Heap ends a web session after 30 minutes without a pageview, so someone who steps away for lunch and returns counts as two sessions.

• Small team, 2,000 monthly users: 2,000 x 4 = 8,000 sessions, which sits under Heap's 10k free allowance. Events: 8,000 x 30 = 240,000, well under Mixpanel's 1M. Both tools are free.
• Growing product, 10,000 monthly users: 10,000 x 4 = 40,000 sessions, four times Heap's free allowance, so you need Growth or higher and Heap gives an estimate after you install its snippet. Events: 40,000 x 30 = 1,200,000, which is 200,000 over Mixpanel's free 1M, so you move to Growth at $120 a month billed annually ($1,440 a year) or $140 on a monthly plan ($1,680 a year) as the starting price, with the final figure coming from Mixpanel's estimator.
• The same product with tighter tracking: if you cut to 20 events per session, 40,000 x 20 = 800,000 events, and Mixpanel stays free. Trimming events is the cheapest lever Mixpanel gives you; Heap has no equivalent, since sessions are set by how people use the product.
• Larger product, 50,000 monthly users: 50,000 x 4 = 200,000 sessions, which is 20 times Heap's free allowance and puts you in a quoted conversation. Events: 200,000 x 30 = 6,000,000, which is 30 percent of Growth's 20M ceiling (6 / 20), so Mixpanel is still self-serve, with the price read from its estimator.

Migrating from Mixpanel to Heap

1. Export a list of the events your live dashboards actually use. Mixpanel's own migration guide says fewer than 20% of the data in a product analytics tool serves more than 80% of queries; the same audit tells you what to recreate in Heap and what to leave behind.
2. Install the Heap snippet on staging first, then production. Heap collects from install onward, so your Mixpanel history does not follow you; keep the Mixpanel project available for older comparisons.
3. Define a virtual event for each used Mixpanel event that is a page action, starting with the steps of your onboarding funnel. Name them the way Mixpanel named them so dashboards read the same.
4. Send the events that never touch the browser, such as trial converted or invoice paid, through Heap's API from your backend, because the snippet cannot see them.
5. Call Heap's identify with the same internal user ID you pass to Mixpanel identify, and never a placeholder like null or user.
6. Run both for a full reporting cycle. Watch your session count against the 10k free allowance: Heap will not drop data above the limit, but you must upgrade before you can view it again.
7. Switch off the Mixpanel track calls once the funnels agree, and keep read access for history.

Migrating from Heap to Mixpanel

Pricing was read from Mixpanel and Heap on 2026-10-07. For other pairings see Mixpanel vs Amplitude, Amplitude vs Heap, Heap vs PostHog and Mixpanel vs PostHog.

1. Decide whether you need Heap's history. Heap Connect syncs your data to a warehouse automatically and retroactively, and is an add-on for Pro or included with Premier; on a lower plan, ask Heap how to export before your contract ends.
2. Run a data audit using Mixpanel's migration guide: anything not queried in 30 days is probably stale and should not be re-instrumented.
3. Write a tracking plan. Each Heap virtual event that mattered becomes either an explicit track call or an event captured by Mixpanel's autocapture option. Choose names once, because renaming an event in code later starts a separate series in your reports.
4. Send identify at login with the same user ID Heap used, and call reset at logout so shared devices do not merge people.
5. Backfill carefully. The guide recommends a year of history or less, a test load of one day into a separate project first, and either the warehouse connector or the Import API. It also warns that backfills can affect your bill.
6. Rebuild dashboards team by team and compare numbers for a week. The guide estimates the technical piece for one engineer at a single sprint of one to three weeks, and it says migration will not fix data quality problems you already had.