Mixpanel Bundle Laravel Package

Product Decisions This Supports

• Server-side analytics instrumentation. Backend-authoritative events — subscription_activated, trial_expired, invoice_paid, seat_limit_hit — are the ones Mixpanel can't reliably get from the browser. This package remains a candidate for wiring those into the Symfony service container so product/analytics teams get funnel and retention data that doesn't depend on client-side JS firing.
• Build vs. buy for the integration layer. The decision isn't "Mixpanel or not" — it's "do we own ~150 lines of HTTP client + DI config, or do we take a dependency?" Mixpanel's ingestion API (/track, /import, /engage) is a simple, stable HTTP contract, so a thin internal wrapper is a realistic alternative and should be priced against adoption. The 7.0.0 release does not change this calculus: it ships no batching, queueing, or retry capability, which is the only part of the work that is genuinely non-trivial.
• Roadmap: analytics coverage as a tracked initiative. If you're planning to make Mixpanel the source of truth for product funnels, this package tells you how much plumbing already exists vs. how much you'd be writing. Useful input to scoping "instrument the monetization funnel" as a quarter-level goal.
• Vendor and version risk as a standing line item. 7.0.0 is a major release that raises the floor to Symfony 8 / ^7.4 and drops Doctrine annotation support entirely. For a team already on Symfony this is a scheduled migration; for anyone else it's confirmation that the package's release cadence is tied to the Symfony release train, not to Mixpanel's API or to our roadmap.
• Use cases that actually justify it: (a) backend-only events invisible to the browser, (b) server-side enrichment (plan tier, account age, cohort) attached to events, (c) experiment exposure logging where a server decision determines the variant, (d) historical backfill via /import when you start tracking late.
• Not a decision it supports: anything in a Laravel codebase. This is a Symfony bundle — service definitions, Configuration tree, container compilation. 7.0.0 makes this more explicit, not less: symfony/yaml is now a declared dependency precisely because the bundle loads its own services.yml at compile time. That is a hard coupling to Symfony's container lifecycle, and it should kill this option early rather than after a spike.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony on 7.4+ or 8.x, not Laravel — this is the load-bearing criterion and it isn't satisfied by the brief. Note the narrowed constraint: 7.0.0 requires ^7.4 for the 7 line, so earlier Symfony 7 minors are now out of support.
• You want Mixpanel wired through Symfony's DI/config layer specifically (yaml-configured token, injectable tracking service, autowiring in existing services). The new explicit symfony/yaml dependency confirms the bundle owns config loading at compile time — you are adopting its conventions, not just its HTTP calls.
• You are comfortable that a major version bump is the normal upgrade path here. 7.0.0 removes Doctrine annotation support, renames the Annotation namespace to Attribute, and removes the Rector set that shipped with 6.0 — so the automated migration tooling that made 6.x upgrades cheap is now something you configure yourself from the changelog.
• You accept a low-signal dependency: still a small star count and no visible downstream consumers. The 7.0.0 release is mild positive evidence of maintenance (Symfony 8 support arrived, dependencies were tidied), but a single-maintainer project with no dependents still means no community to catch a breaking change and no ecosystem evidence that the config surface matches current Mixpanel API behavior.
• Your security/compliance review tolerates a third-party package sitting on the path that transmits user identifiers to a US analytics vendor. You'll still need your own consent gating, PII scrubbing, and a documented event taxonomy — the bundle provides none of that.

Look elsewhere — or don't adopt — when:

• You're on Laravel. Write a 100-line service around Mixpanel's HTTP endpoints behind your own interface. 7.0.0 strengthens this: an explicit symfony/yaml dependency and compile-time services.yml loading mean you'd be shimming the bundle's container integration, and there is no Laravel-side equivalent in this release.
• You need a maintained contract. The release cadence is real but tied to Symfony's schedule. There's still no evidence of independent test depth or downstream validation; treat the major-version churn as an ongoing upgrade tax rather than a one-time integration cost.
• You need queueing, batching, retries, or idempotency. 7.0.0 adds none of this — its headline features are framework-version support and dependency hygiene. Analytics calls must never block a checkout or a signup, so you're building the async layer regardless, at which point the bundle saves you almost nothing.
• You need feature-flag/experiment integration, group analytics, or data-warehouse export. Those are Mixpanel-side or ETL concerns; the bundle won't move that roadmap.
• Vendor portability matters. Low here in your favor: because the wrapper is thin, exiting to Segment, PostHog, or raw HTTP is cheap. Treat that as the mitigating factor, not a reason to adopt.

How to Pitch It (Stakeholders)

For executives (one paragraph): We re-evaluated the community Symfony bundle for sending server-side product analytics to Mixpanel following its 7.0.0 release. Recommendation is unchanged: do not adopt as-is. The new version is a maintenance release — Symfony 8 support, a tightened Symfony 7 floor, and a dependency declaration fix — plus breaking changes for existing users (Doctrine annotation support removed, namespace renamed, the bundled Rector migration config dropped). It adds no queueing, batching, or retry capability, which is the only genuinely hard part of this work, and it remains a Symfony-only package while our stack is Laravel. The underlying need is real: backend events like subscription activation and trial expiry are where our funnel analysis is thinnest, and Mixpanel's ingestion API is a stable, well-documented HTTP contract. We recommend a small in-house client behind our own interface — roughly one to two engineering days — which gives us the analytics coverage without the dependency risk and keeps us free to switch vendors. Net: same product outcome, lower ongoing risk, and no new package on the critical path of signup and billing flows.

For engineering (the summary that matters): Symfony bundle, not Laravel — 7.0.0 makes the coupling more explicit by declaring symfony/yaml as a hard dependency because the bundle loads its own services.yml at container compile time. So adoption means a shim, not a composer require. 7.0.0 is a major: Symfony 8 support, Symfony 7 narrowed to ^7.4, Doctrine annotations no longer read, Annotation namespace renamed to Attribute, and the Rector set from 6.0 removed — upgrade tooling is now copy-paste from the changelog. If you're not on Symfony, none of that is our problem to solve. It remains a thin wrapper over Mixpanel's /track and /import; the value it adds over our own client is small and the exit cost is low either way. If we do spike it, the only things worth copying are the event-enrichment and DI ergonomics. Regardless of path: dispatch through a queue, never inline in a request that touches revenue, gate on consent, and define the event taxonomy before writing a single track() call.