Backend Google Analytics Bundle Laravel Package

Product Decisions This Supports

This package is a narrow instrument with one job: showing which parts of an internal admin/back office actually get used. It hooks Google Analytics pageview tracking into a Symfony-based admin panel, so internal staff behavior — not customer behavior — is recorded. For a PM, that unlocks a small but real set of decisions:

• Back-office roadmap prioritization. Pageview volume per admin module is a cheap proxy for "who actually depends on this." A screen with 40 views from 3 users in 90 days is a deprecation candidate; a "temporary" screen with 10k views is a roadmap item.
• Sunset and deprecation evidence. Before announcing removal of an admin workflow, pageview decay per module gives you a defensible, low-instrumentation signal of remaining usage.
• Onboarding/enablement investment. Whether new ops and support hires reach the modules you trained them on, or stall at step two, is visible in admin pageview funnels.
• Support and documentation prioritization. High-traffic admin screens correlated with high ticket volume are where help content and UX polish pay back fastest.
• Build-vs-buy framing for internal telemetry. The honest read is neither buy nor adopt: this is a thin integration, not a platform. Its real value is as a pattern reference — tag the admin layout, emit a pageview per route, attach a role dimension — to justify a small first-party effort.
• Roadmap justification for the platform team. "We have zero visibility into admin usage" is a legitimate funding argument, and this package is the cheapest possible proof of concept.

What it does not support: customer funnels, retention/cohort analysis, revenue attribution, or anything needing event-level granularity. Admin pageviews are a blunt instrument.

Flag up front: despite the "Laravel/PHP package" framing, this is a Symfony bundle from the Modera ecosystem — it cannot be composer required into a Laravel app and used as intended. Treat it as a reference implementation, not a dependency. Also assume it was written against Universal Analytics, which stopped processing hits in 2023; verify protocol before anyone assumes it works.

When to Consider This Package

Adoption criteria — all should hold:

• You run Symfony with the Modera backend stack. This is the entry condition; the Laravel framing is a catalog error worth closing out early before a sprint gets burned.
• You already operate GA4 under a signed DPA, and employee monitoring has cleared legal and, in the EU, your works council. Backend pageviews are personal data about staff, not anonymous traffic.
• The backend is internal-only and low-stakes, and coarse pageview-level data is enough to answer your question.
• You need something in days, not a quarter, and you accept reading the source as documentation.
• Someone on the team can own and patch a Symfony bundle indefinitely.

Look elsewhere — likely the right call — when:

• Your stack is Laravel. No port exists; you'd be writing the middleware yourself anyway, and that's ~100–200 lines.
• Community validation matters. Zero stars, zero dependents, single-maintainer origin, no security-response trail. Every unmaintained bundle in a privileged admin panel is attack surface.
• You need GA4-correct behavior. Older bundles target Universal Analytics (UA-*, ga() / /collect); hits would land in a void with no error surfaced.
• Privacy posture is strict. Admin URLs routinely embed record IDs, account numbers, and customer names in query strings. Sending those to Google is a data-leak vector, plus US transfer, consent surface, and IP handling you don't control.
• The real need is product analytics. For funnels, retention, and per-user journeys, GA on admin pages is the wrong tool. Prefer self-hosted, first-party options: Matomo (GA-shaped, privacy-friendly), Plausible, PostHog (events, funnels, replay on your own infra), or a first-party events table plus a BI dashboard.
• You'd be the sole maintainer. Then the "free" package costs more than the code it replaces.

How to Pitch It (Stakeholders)

For executives: We currently have no measurement of how our internal admin tools are used, so back-office roadmap decisions rest on opinion and the loudest voice. This package is a minimal way to get pageview-level visibility using analytics infrastructure we already pay for. But it is an unmaintained third-party component with zero adoption, it targets Symfony while our stack is Laravel, and it raises employee-monitoring and data-transfer questions that need legal sign-off. Recommendation: do not adopt it as a dependency. Fund a small first-party effort instead — self-hosted analytics or an internal events table plus a dashboard — which gives the same signal with better privacy posture and no maintenance liability. Budget days, not weeks. The decisions this unlocks — which admin features to invest in and which to retire — are worth considerably more than the build.

For engineering: Treat the repo as a reference implementation, not a dependency. The pattern is: hook the admin base layout, emit a pageview per admin route, attach a role or team dimension (never a raw email or record ID), and route to a sink we control. Concretely: ~1 sprint to stand up first-party admin event logging with a dashboard, behind a feature flag, queued off the request path, validated against GA4's debug endpoint if we go the GA4 Measurement Protocol route — with a documented answer on GA4-vs-self-hosted before anyone wires a tracker. Put the framework mismatch and the stale-UA risk in the ticket so "why not just install it" is closed out. Success criterion: we can answer "top 20 admin routes by weekly active users, last 90 days" without asking an engineer.