mixpanel-mastery

Project root: every relative path in this skill (knowledge/..., tools/..., .claude/skills/...) resolves against ~/dev/jove-hq, never the current working directory. This skill is invocable from any cwd, so prefix accordingly: ~/dev/jove-hq/knowledge/jove-labs/STATUS.md.

Mixpanel mastery

Full evidence trail: knowledge/jove-labs/mixpanel-mastery.md in jove-hq (1,481 lines; schema claims re-verified live 7 Sep 2026). This skill is the operational distillation of that document. When the two disagree, the mastery doc is the source of truth, update this skill from it, not the other way round.

Before any tool call

1. Call Get-Business-Context first, every session, before any other Mixpanel tool. It resolves project nicknames and org vocabulary you can't infer from tool names.
2. Know which project you're in. Production is 2857603 ("www.jove.com - LIVE"). The dev/preview project, where PREVIEW-LYHRM and any pre-launch testing lands, is 2875597 ("New Website - Dev team (new)"). Stage and QA have their own separate projects. A wrong project pick returns confidently empty results, it doesn't error.
3. The one construct everything else hangs on: counting something across two different people (a lab touched by a trainer, then by a trainee) is

   {"type": "aggregate-property", "math": "unique_values", "propertyName": "lab_id"}
   

   inside an Insights Run-Query. The UI calls this "Distinct Count of lab_id". It is not a funnel, not Hold Property Constant, and not a saved Metric: Create-Metric's math enum is unique | total | session | dau | wau | mau and has no aggregate-property option at all (re-verified live 7 Sep 2026), so this measurement can never be centralized, it must be repeated in every report that needs it.

The eleven traps, read every one before building or reviewing a tile

Ordered by how likely each is to ship unnoticed. Full detail and live evidence for each is in references/traps-detail.md.

1. Building a cross-user tile as a funnel. Two different actors in one funnel returns a near-zero number, and it doesn't error. Check: read the two events, name who fires each. Different people means no funnel, use Distinct Count instead.
2. Reaching for Hold Property Constant to "fix" trap 1. It requires one user to carry the value through every step, it narrows the funnel, it doesn't re-key it across users. Legitimate only when every step really is the same person in one session.
3. Summing distinct counts. Not additive across breakdown segments (live proof: 4,552 unbroken vs 4,556 broken-down, a lab in two buckets counts in both) and not additive across time on line charts either. Headline totals come from their own unbroken metric/bar tile, never from summing a column or a line.
4. Right-censoring a rolling-window denominator. A relative "last 30 days" window on a "did X happen within 7 days" tile counts things too young to possibly qualify, understating the rate worst exactly when growth is fastest. The window must end at least N days in the past, and say why on the board.
5. Shipping a formula tile with no denominator. A formula call in Run-Query suppresses its input metrics entirely, verified live, so a 98.9% over n=4,552 and a 98.9% over n=3 render identically. Every formula tile needs a companion tile showing its denominator.
6. Sending a number as a string. A numeric-filter-driving property (days_since_lab_created etc.) arriving as "3" instead of 3 is silently excluded from numeric filters, no error anywhere, and Mixpanel infers type with no schema declaration and no documented retroactive fix. Assert the JSON type at the source.
7. Trusting an institution/property breakdown at face value. Missing values arrive in at least 3-5 disguises simultaneously ("", "undefined", "-", absent, null, all rendering (not set)), and values are case-sensitive with zero folding ("jove" and "JoVE" are different buckets). One canonical missing representation, one canonical casing, both enforced server-side, plus a coverage companion tile.
8. Assuming super properties reach server-emitted events. Super properties are a client-SDK-only concept with no server-side equivalent, documented explicitly. A server event not stamped with the property by hand is simply undefined for it, which looks like an adoption problem rather than a tracking bug.
9. Reading today's number. Late-arriving data means today's figure for today's date range is always provisional and always low; caching adds up to an hour of staleness on top. Every tile's window ends yesterday.
10. Omitting or reusing $insert_id on server events. Without it, ingestion succeeds but dedup never applies, so every retry double-counts permanently. Reusing a business key (e.g. lab_id) as the insert id silently deletes legitimate repeat events instead.
11. Assuming a never-fired event renders as a zero. It does not render at all. A Run-Query naming only never-fired events returns an empty result, and in a mixed tile the missing metric is dropped in silence: a three-metric tile whose middle event has never fired comes back with A and C, no row and no gap where B belongs. A table captioned "AC7 usage events" then reads as a short list and nobody can tell a missing row from an unbuilt tile. The only honest way to state that an event never fired is a text card. Verified live 7 Sep 2026 on project 2875597.