Heap vs Mixpanel: capture everything, or track what you plan

What each plan lists today

Everything in this table was read from Heap's pricing page and Mixpanel's pricing page on 7 October 2026.

Sessions against events: the cost at three traffic levels

The two vendors count different things, so a fair comparison needs a conversion. Mixpanel counts events; Heap counts sessions. The sums below use an assumption you should replace with your own number: 30 tracked events per session, which is a busy app session. A lighter product at 20 events per session lands in the second column.

One cross-check on Mixpanel's $140: its pricing documentation gives $0.00028 per event above the first million on a 1M-event Growth plan, and 500,000 events over the allowance times $0.00028 is $140, the monthly price at the 1.5M stop. The documentation adds that buying a larger volume up front lowers that rate, so the $0.00028 figure is a ceiling for bigger plans, not their price. If you cross a plan's limit on Growth, Mixpanel does not stop collecting; the extra is billed at the start of the next month.

What happens at the free ceiling differs and is worth knowing before launch day. Mixpanel's docs say a Free project that reaches 1M monthly events has its platform access limited, with no overage charge, until the month resets or you upgrade. Heap's page says it will not "drop or throttle" your data, but you get an email asking you to upgrade and cannot view your data again until you do. In both cases a traffic spike can lock you out of dashboards, so a launch week is not the moment to be on the free plan.

Autocapture and "define it later" against a tracking plan

Install Heap's snippet and, in the words of an older Heap blog post, "every customer interaction on your website; clicks, pageviews, form submissions, etc., gets recorded automatically." You then label the clicks and views that matter as events, and that post states a Heap event "will retroactively populate all historical data it has collected." Renaming or redefining works over history too. Its comparison point is a tag manager, where a tag "only collects data from that point forward." For a team that finds out in month six that it should have been measuring a particular button, that is the real selling point.

Mixpanel starts from the other side. Its introduction describes three concepts, events, users and properties, and tells you to plan the first events you want to track, adding that choosing them should take no more than five minutes. Its JavaScript documentation now lists an autocapture mode as well: from SDK version 2.60.0, setting autocapture: true turns on pageview, click, dead click, input, rage click, scroll and submit tracking, with text content capture off by default. The documentation pages read for this comparison describe that mode as collecting events going forward; they do not describe defining new events on top of old autocapture data the way Heap's blog does, so treat retroactive definition as Heap's headline strength.

The trade-off is cleanliness. A plan written in advance gives you named events with known properties, which is easier to keep consistent across web, mobile and server. Retroactive definitions depend on the page still looking like it did when the data was recorded, so a redesign can leave you redefining events. Neither approach fixes the harder problem of deciding what a "successful onboarding" means for your product.

Data governance and cleaning up

Mixpanel's Lexicon is its data dictionary, and its docs are specific about the clean-up actions. Hiding an event "does not affect data ingestion" and hidden items still "count toward your data allowance", so hiding tidies the interface but not the bill. Blocking stops Mixpanel storing new data for that event or property, and the docs warn that you cannot recover event data after you block it. Merging combines selected events into one without touching the raw data, and Mixpanel says it can reduce costs by removing redundant events. Fewer duplicate events means a smaller bill because the pricing unit is the event.

Heap's levers are on the plan page. Enterprise-style controls such as advanced user permissions, unlimited projects, behavioral targeting and region-specific storage appear only on Premier, and a data warehouse integration is listed there too. Heap's free plan allows 1 project, which matters if you want separate staging and production spaces. Mixpanel's own documentation says a Free project has features such as lookup tables, custom properties and permissions left out, and that governance features are aimed at Enterprise.

Identity, accounts and billing events for a SaaS

Mixpanel documents its identity model in detail. Its simplified ID merge uses $device_id as the anonymous ID and $user_id once someone is known; the docs say to call .identify on registration or login and to "send at least one event after the .identify() call", then .reset() on logout. They also state that "it is not possible to merge 2 $user_ids together using the Simplified API", which matters if people sign up twice with different emails and you later want one profile. Mixpanel's pricing docs list $identify, $create_alias, $merge and profile updates as non-qualifying, so identity calls do not eat your event allowance.

B2B products usually need reports by company, not just by person. Mixpanel sells Group Analytics as an add-on for exactly this and warns it "can't be implemented retroactively" for events already ingested, so decide before you collect. Heap's equivalent is account analytics, listed from the Pro plan up, which means the analysis you need for a B2B product sits behind a custom-priced tier.

Billing events are the same problem in both tools. Trial start, upgrade, failed payment and cancellation are decided in Stripe, Paddle or Chargebee, not in the browser, so autocapture never sees them. Forward them from your webhook handler as named events carrying the same user ID you used on the client; each one then counts as an event on Mixpanel's meter. Keep that list short, because a webhook that fires per invoice line adds volume. The Stripe vs Paddle page lists which events each billing system emits.

Moving from Heap to Mixpanel, or the reverse

1. List the events your dashboards depend on. In Heap these are definitions over raw capture; in Mixpanel each becomes a track call or an autocapture setting, so write them down with their properties before you start.
2. Choose the user ID now. Use your database ID as $user_id on Mixpanel and send it on every server-side event, or you will split people across devices.
3. Run both tools in parallel for at least a full billing cycle, comparing the same funnel in each. Counts will not match exactly, since Heap counts sessions and Mixpanel counts events.
4. Decide about history. Heap's pricing page lists a warehouse sync add-on that syncs data "automatically and retroactively", and its Premier plan lists data warehouse integration. Mixpanel's pricing docs say events are billed by ingestion time and that importing old data counts toward the month you import it, so a large backfill can push you past your allowance in that month.
5. Cut over reports, then remove the old snippet. Keep the export from the old tool for as long as you need to answer year-on-year questions.

Which to choose

• Heap fits product teams that cannot predict their questions, have little engineering time for tracking code, and can accept a price shown after installation. Its free plan covers up to 10k monthly sessions and 6 months of history.
• Mixpanel fits teams that want a readable price curve, a free tier measured in 1M events, a data dictionary with block, hide and merge, and clear identity rules. Its pricing page also advertises a Startup Plan with a first year free for companies founded less than 5 years ago with up to $8M in total funding.
• A third option is worth a look if neither pricing unit suits you. Mixpanel vs Amplitude and PostHog vs Amplitude cover the next names on most shortlists.

Related reading: an analytics stack for SaaS, product analytics practices, the product analytics category and all comparisons.