Laravel Mixpanel Laravel Package

Product Decisions This Supports

• Instrumentation as normal backend work. The facade and helpers let events ship in the same PR as the feature — in a controller, a queued job, a model observer — rather than requiring a parallel client-side tracking plan. That collapses the gap between "shipped" and "measurable."
• Adoption, activation, and retention readouts from a trustworthy source. Signup, onboarding step completion, first use of a feature, and repeat usage are emitted from the code that owns the domain logic. Server events are closer to the source of truth than browser pixels, which drop under ad blockers, SPA routing, and consent banners.
• Revenue and lifecycle moments tracked where they happen. Plan upgrades, seat additions, subscription changes, and invite sends are recorded at the point of truth instead of being reconstructed from front-end behavior — the numbers you would take into a pricing or packaging conversation.
• The identity model is now a product decision, and this package exposes it. v13's getMixpanelKey() hook lets you choose the distinct ID: internal user UUID, email, or account/workspace ID. If B2B multi-seat or organization-level reporting is on the roadmap, this is the switch that makes it answerable. Deciding it late fragments user history and breaks cohort continuity — treat it as a one-way door.
• Build vs. buy. The wrapper is the cheap part. The expensive, product-owned asset is the event taxonomy and naming convention. Standardizing on Mixpanel through this package keeps instrumentation cheap and lets the team invest in the schema, not the client plumbing.
• Roadmap evidence. Reliable event volume is the raw material for funnels, cohorts, and experiment readouts that justify or kill bets.
• Upgrade cadence as a planning constraint. v13 adds Laravel 13 and PHP 8.5 support, so analytics stops being the reason a framework upgrade slips. That is risk reduction on the roadmap, not a technical footnote.

When to Consider This Package

Consider it when:

• You are on, or planning to move to, Laravel 13 / PHP 8.5 and want analytics tracking the framework's release cadence instead of lagging it.
• Mixpanel is already the committed vendor and you want tracking to be a small, conventional, reviewable part of the Laravel codebase rather than ad-hoc calls scattered across controllers.
• You need a configurable identity model — the getMixpanelKey() hook is the differentiator if your product has accounts, workspaces, or organizations where "the user" is not simply the authenticated person.
• You want server-side product analytics without owning Mixpanel client plumbing, config, and retry handling.
• You are consolidating scattered tracking calls behind a single typed entry point.

Look elsewhere when:

• The vendor is still undecided. This is a single-vendor wrapper; a vendor-neutral event abstraction or a warehouse-first approach preserves optionality.
• You need warehouse-native or reverse-ETL analytics. If events must land in Snowflake/BigQuery first and be modeled there, this solves a different problem.
• Client-side behavior is the core question. Scroll depth, page interaction, and UI experiment exposure need browser SDKs; server events cannot see them.
• Event volume economics are unfavorable. High-frequency server events are expensive on event-based pricing. Model expected volume against the Mixpanel plan before committing.
• You need strict PII or consent governance. Sending identifiers to a third party requires a deliberate data-processing review; a wrapper is not that policy layer.
• Your needs are trivial. A handful of events may not justify a dependency, a DPA, and a third-party integration.

v13 adoption notes a PM should plan around:

• Config relocation is a breaking change and it fails quietly. Settings move into a dedicated publishable config file; a missed token reference resolves to null and events drop with no exception. This is a scheduled, time-boxed migration with a staging smoke test, not a drop-in patch.
• The getMixpanelKey() decision is yours, not engineering's. Choose the identifier once, document it, and confirm it matches the distinct ID the client-side SDK sends. Mismatched keys scatter server and browser events across separate profiles.
• Laravel 13 / PHP 8.5 support is additive and low risk — it unblocks upgrades and changes no product behavior.
• Maturity signal. 123 stars, zero dependents, one primary maintainer. Fine for instrumentation; note the bus factor in the dependency register and keep tracking calls behind a thin internal service so a future vendor swap stays contained.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can measure whether the features we ship actually get used, at low engineering cost, by standardizing on the Mixpanel integration already running inside Laravel. This release keeps us current with Laravel 13 and PHP 8.5 — so analytics never becomes the reason a platform upgrade slips — and adds the ability to define what counts as a "user," which is what makes account- and workspace-level reporting possible. The work is a small, time-boxed config migration plus a decision, not a rebuild. The commercial decision attached to it is our Mixpanel plan and event volume, not the code.

For engineering (the substance): v13 is a major bump driven primarily by configuration: Mixpanel settings move into a dedicated publishable config file. Republish config, diff it key-by-key against the current one, and re-point every reference — application code, .env templates, CI secrets, and deployment manifests — because a missed token fails silently with events dropped and no exception. Verify with a config-cache-enabled boot test that the token resolves non-null, and smoke-test ingestion in staging. Two additive capabilities land alongside it: Laravel 13 / PHP 8.5 support, and a getMixpanelKey() hook for a custom distinct ID. Read composer.json first — the release notes list additions, not drops. Recommended sequencing: (1) confirm framework/PHP constraints before anything else, (2) audit existing call sites and event names while you are in the config anyway, (3) ship the config migration on the current framework line, (4) pilot the custom distinct ID behind a flag and confirm in Mixpanel's live view that events land on the expected profiles, (5) capture the event taxonomy in the repo so instrumentation stays reviewable in code review. Do not bundle this with a Laravel major upgrade.

Ask: Approve a small, time-boxed instrumentation and config-migration task, and a product decision on the canonical user identifier for analytics.