Filament Panphp Laravel Package

Product Decisions This Supports

• Instrumenting a product without a third-party analytics vendor. PanPHP is a lightweight, self-hosted, cookie-free product analytics layer for Laravel; this package surfaces that data inside a Filament admin panel. The PM decision it unlocks is "can we get feature-usage visibility from our own database instead of buying into GA4/Mixpanel/PostHog?" — useful when privacy posture, DPA overhead, or cost make SaaS analytics a hard sell.
• Feature adoption and roadmap prioritization in-app. If the team already runs Filament for back-office work, an analytics widget inside the same panel gives PMs and CS a zero-context-switch view of what customers actually touch. That supports kill/keep decisions on low-adoption features, beta rollout monitoring, and "is anyone using the thing we shipped last quarter?" questions.
• Build vs. buy for internal dashboards. The realistic comparison is not "this vs. Mixpanel" but "this vs. two weeks of an engineer wiring a custom widget." A 26-star, 0-dependent Filament plugin is a prototype accelerator, not a platform commitment — good for a spike, an internal tool, or a v1 dashboard you intend to replace.
• Reducing vendor surface and data-residency risk. Self-hosted event data stays in your own MySQL/Postgres. That's a genuine product/compliance decision for EU customers or regulated verticals where "no third-party JS on authenticated pages" is a stated requirement.
• Validating the analytics need before investing. Deploying a thin self-hosted tracker behind the admin panel is a cheap way to learn whether the org will actually look at product usage data. If nobody opens the dashboard in 60 days, you've saved yourself a six-figure analytics contract.
• Not supported: experimentation platforms, revenue attribution, cohort/funnel analysis at depth, cross-device identity, or anything requiring a mature SDK ecosystem. Treat this as basic event counting with a UI, not an analytics strategy.

When to Consider This Package

Adopt or prototype when all of the following hold:

• You are already on Laravel + Filament, and the people who will consume the data already have panel access. The integration cost is close to zero only in that context.
• Your analytics needs are modest and first-party: page/feature views, simple event counts, "who used what." No funnels, no attribution, no warehouse sync.
• Privacy-first or self-hosted is a requirement, not a nice-to-have — cookie consent burden, EU data residency, or a security review that blocks third-party scripts on authenticated pages.
• You want a spike or internal tool, and you can absorb the cost of throwing it away. Budget it as a two-to-five-day evaluation, not a quarterly initiative.
• You have someone who can read the source — with 26 stars, 0 dependents, a last release in October 2024, and a middling score, there is no community safety net. Vendor risk is the dominant factor.

Look elsewhere when:

• You need production-grade analytics — retention curves, funnels, segmentation, A/B test readouts. Use PostHog, Amplitude, or a warehouse-native stack; PanPHP's event model is deliberately simple.
• Scale matters. High event volume in your primary application database is an operational decision you should make deliberately, not inherit from a plugin.
• Maturity is a hard requirement. Single-maintainer package, no dependents, no recent release: no security response process, no upgrade path guarantee across Filament major versions, and API churn risk on Filament's widget/page contracts is real.
• You need mobile app, server-side-only, or multi-tenant SaaS analytics out of the box — this is a Filament view over a Laravel package, not an ingestion platform.
• Your team is not on Filament. The entire value is the panel integration; without it, use PanPHP directly and build your own reporting.
• Mitigation if you do adopt: pin the version, wrap it behind your own thin dashboard page so the plugin is replaceable, and keep PanPHP's raw tables as the source of truth so you never lose data if the Filament layer is abandoned.

How to Pitch It (Stakeholders)

To executives: "This is a small, free, MIT-licensed add-on that lets us see basic product usage inside the admin tool our team already uses — no new vendor, no new contract, no customer data leaving our servers. The strategic upside is proving whether in-product analytics is worth funding properly; the downside is bounded to a short evaluation and a dashboard we can delete. Recommendation: timebox a spike, don't standardize on it."

To engineering: "It's a Filament widget/page layer over PanPHP, which stores first-party events in our own database. Integration is minimal and reversible — the plugin is presentation only, so we keep the raw event tables and can swap the UI. Caveats: one maintainer, 26 stars, zero dependents, last release October 2024, and it tracks Filament's widget APIs, so pin the version and isolate it behind our own page. Treat it as a spike, not a dependency."

Framing to use in the room: the decision is "do we want first-party, self-hosted product analytics at all?" — this package is the cheapest possible way to answer that question, and explicitly not the answer to "which analytics platform do we standardize on." Keep the build-vs-buy conversation separate from the vendor-risk conversation; conflating them is how a 26-star plugin ends up load-bearing in a roadmap review six months later.