Pan Laravel Package

Product Decisions This Supports

• Feature adoption and engagement measurement without third-party tooling. Pan records page views and custom events server-side inside the Laravel app, so a PM can answer "are users reaching the new flow, and how often?" using data already in the product database rather than negotiating a GA4/Segment/Amplitude integration. The value is cheap instrumentation for hypothesis validation, not analytics depth.

• Roadmap and prioritization signals. Because events are first-party and queryable, you can assemble lightweight funnels (signup → first project → invite teammate) and adoption cohorts to decide whether to invest further in a feature, iterate, or sunset it. This is the core PM use case: a decision-grade signal at near-zero incremental cost.

• Build-vs-buy for analytics. Pan reframes the decision from "which analytics vendor do we integrate?" to "do we need that vendor at all for this question?" It is a credible adopt-instead-of-build option when the alternative is hand-rolling event tracking or paying for a platform whose 90% of features you won't use.

• Privacy and compliance as a product decision. No cookies, no third-party scripts, no outbound data transfer. That directly supports decisions about consent banners, DPAs, and EU/UK market entry — the analytics choice becomes downstream of the privacy posture you want to ship, rather than a blocker to it.

• Rollout and experiment monitoring. Track adoption of a flag-gated feature or a new onboarding variant to decide whether to roll forward or back. Note this supports observational rollout monitoring, not statistically rigorous A/B testing.

• Internal product dashboards and self-serve metrics. Teams can surface simple usage numbers inside an admin panel, reducing ad-hoc data requests to engineering. Caveat: the package description advertises a built-in dashboard, while a technical read suggests the reporting layer is largely DIY — validate in a spike before promising stakeholders a dashboard out of the box.

When to Consider This Package

Adopt when:

• You are on Laravel/PHP and want analytics inside your existing stack — no new vendor, SDK, or data pipeline to operate.
• Your questions are product-usage questions (what's used, how often, where users drop off), not marketing attribution or cross-device identity.
• Privacy, GDPR/CCPA posture, or self-hosting is a stated requirement or a market differentiator.
• You want low operational overhead — a small team without a data warehouse or a dedicated analytics engineer.
• You need fast, cheap instrumentation to test a hypothesis before committing to a larger analytics investment.
• You can accept that history starts at cutover — there is no backfill, so sequence migration before you need trend lines.

Look elsewhere when:

• You need marketing analytics, ad attribution, cross-domain/cross-device tracking, or rigorous experimentation — this is not that tool.
• You require warehouse-grade modeling, SQL exploration, or BI integrations (dbt, Looker, warehouse-native tooling).
• You're not on Laravel, or your estate is polyglot and needs a consistent event pipeline across services; this is Laravel-coupled despite the "PHP package" framing.
• You have high-traffic or high-cardinality needs where writing events to the primary database is an operational risk — separate the analytics store first.
• You need enterprise governance: SSO, RBAC dashboards, formal retention tooling, vendor SLAs/DPAs. This is a community MIT package (~1.2k stars), not a supported platform.
• Your front end is SPA-routed (Inertia/Livewire/Turbo), where middleware-based page views under-count and events must be emitted explicitly — verify that path before committing.
• Compliance requires audit-grade tooling or a vendor DPA — self-hosting shifts that burden onto you.

How to Pitch It (Stakeholders)

To executives: Pan gives us first-party product analytics inside our existing Laravel application — no vendor contract, no third-party scripts, no cookie-consent complications, and data that never leaves our infrastructure. It lets us measure feature adoption and validate roadmap bets with data we already own, at effectively zero incremental cost and with a privacy posture we can market. The trade-off is scope: it answers "what are users doing in our product," not "where did they come from" or "which campaign worked," and the reporting layer is largely ours to build. For a team our size that's the right 80/20 — we can revisit a dedicated platform when our questions outgrow usage metrics. Recommendation: a time-boxed pilot on one feature, with a decision gate, before broad instrumentation.

To engineering: It's a small MIT-licensed Laravel package — a composer dependency, one published config and migration, middleware-based tracking, and a track() API for custom events, with data stored in our own database. Integration is roughly one to three engineering days; the real cost is event taxonomy design, not wiring. Key caveats to plan around: it writes to our primary database, so we need to watch volume and consider a queue or dedicated connection before high-traffic rollout; it's community-maintained with thin documentation, so pin the version and treat it as a small internal dependency rather than a platform bet; and client-side beacons fail silently (ad-blockers, CSP, swallowed non-2xx), so add a synthetic canary event and a daily non-zero assertion to catch tracking gaps. Ask the maintainer or verify in the spike: what's persisted per event (IP, user agent, user ID), retention/pruning tooling, aggregation granularity (counters vs raw rows), queueability, multi-tenancy scoping, and Laravel/PHP/database compatibility. Proposed path: staging spike → narrow ~10-event taxonomy tied to one real product question → shadow-mode production rollout behind a flag → two weeks of latency and table-growth monitoring → build the read layer → only then expand taxonomy.