tightenco/nova-google-analytics
A Laravel Nova card that surfaces Google Analytics data—sessions, users, page views, and top referrers—right in your Nova dashboard. Connect a service account, configure the metrics you need, and track site performance at a glance without leaving the admin panel.
Architecture fit. Treat this as a presentation-layer connector, not a data platform component. It is a Nova card that reads the GA4 Data API and renders a fixed set of traffic metrics — sessions, users, pageviews, top pages, referrers — inside an existing Laravel Nova admin panel. There is no write path into product data, no end-user surface, and no utility outside a Nova install. For a TPM that narrow contract is the point: the blast radius is one dashboard card, rollback is "remove the card," and the decision is reversible in an afternoon. It is the wrong component for cohorts, funnels, attribution, monetisation reporting, or any reporting layer other systems will consume. Frame it as an internal operator convenience, explicitly not an analytics strategy commitment.
Integration feasibility. Mechanically simple — composer require, publish config, register the card, supply a GA4 property ID plus a Google service account with Viewer access on the property and the GA4 Data API enabled. The real cost sits in governance, not code: someone must own the Google Cloud project, the service-account key lifecycle, and the per-property permission grant. A missing Viewer grant produces an empty or errored card that reads like a bug and burns support time. Budget that as a named work item with a named owner before engineering starts, and get privacy/security sign-off on analytics credentials residing on the app server up front.
Technical risk. Medium, concentrated in three places. Version risk: v4.0.0 is a breaking major — Universal Analytics to GA4 plus Laravel 11 support — so config keys, credential shape, and metric names differ from v3; treat v4.0.0 as the only viable version and do not assume v3 configuration carries over. Maintenance concentration: 166 stars, zero dependents, MIT licence, a small contributor base (the major shipped with two first-time contributors), last release mid-2024 — there is no vendor SLA. External dependency: Google's GA4 schema, quotas, and access model sit outside the package's control and can move faster than a volunteer-maintained card patches. Offset all three by keeping the integration thin, pinning the version, and documenting metric definitions outside the repository so a future major cannot silently change what a displayed number means.
Key questions.
Product decisions this unblocks. A TPM can use this card as a cheap, demoable answer to "can we see site traffic in the admin panel" — closing a recurring stakeholder request without a BI contract or a custom GA4 integration ticket. It also gives a concrete number to compare against any build estimate for internal dashboards, and it is a visible, low-cost vote for consolidating internal tooling in Nova when defending that licence line. The value to sell is reclaimed engineering hours from ad-hoc "can you pull the numbers" requests, not new capability.
Stack fit. Appropriate only where Laravel and Nova are already the operational back office. If Nova is not in the stack, there is no partial-value path — stop the evaluation rather than scope a workaround. Keep Google credentials in a secret manager or environment variables with the JSON materialised at deploy time; never in source control, and avoid inlining raw JSON into .env, because the private key's newline handling is a recurring source of silent failures.
Migration path. For an existing v3 install, scope this as a migration ticket, not a dependency bump. Branch, install v4.0.0 against staging pointed at a dedicated or staging GA4 property, publish and diff the config, re-provision GA4 access and credentials, swap UA identifiers for GA4 property IDs, re-register cards, then reconcile displayed numbers against the GA4 UI for the same date range before promotion. For a fresh install the reconciliation step still applies — it is the only way to prove the card reads the property you think it does, and it is the cheapest QA a TPM can insist on.
Compatibility. Laravel 11 support is explicit in v4.0.0; the variables to verify are the Nova major, the PHP version, and the underlying Google API client. Validate twice — a clean install and an upgrade from v3 — because the breaking-change surface differs between paths. If a framework upgrade is in flight, land this after Laravel 11 rather than in parallel; bundling two independent breaking changes into one deployment obscures which one broke the dashboard and lengthens the rollback decision.
Sequencing.
AnalyticsDashboard rather than crowding MainDashboard, and gate visibility via policy or canSee.Maintenance. Low-intensity but non-zero, because Laravel, Nova, PHP, and the GA4 Data API all move independently and this package moves on volunteer time. Assign a nominal owner, pin the version, and schedule a dependency review each framework upgrade rather than relying on a release cadence that may not come. The card itself should be treated as replaceable: keep the wiring thin enough that deleting it is a five-minute change.
Support. Two distinct queues. First-line is "the numbers look wrong," which is almost always property access, date range, or GA4 attribution semantics — resolve with documentation, not code. Second-line is credential failures and API errors, which need an on-call owner. Marketing/analytics ops owns interpretation of the numbers; engineering owns installation and rotation. Say that out loud in the launch comms so the boundary does not blur into an engineering helpdesk.
Scaling. Every admin dashboard load is a GA4 Data API call against per-property, token-based quota. Caching is not optional: set an explicit TTL, prefer fewer cards with wider date ranges over many narrow cards, and resist the drift toward "one card per stakeholder." If multi-property aggregation or high-frequency refresh becomes a requirement, that is a reporting-layer decision — escalate to a BI evaluation rather than stretching this card.
Failure modes. Expect stale cached data, empty panels from a missing Viewer grant, silent zeroes that look like a traffic collapse, quota exhaustion during demos, and breakage when Google alters the API. Mitigations: render an explicit "analytics unavailable" state rather than misleading zeroes, surface data freshness on the card, provide a config off-switch so it can be disabled without a deploy, and rehearse the demo against a real property beforehand.
Ramp-up. Hours for engineering to wire, days to weeks for governance — credential provisioning, permission grants, security review, and metric reconciliation dominate. A TPM can realistically demo this in an afternoon against a sandbox property, which is exactly the right way to test stakeholder appetite before committing the governance work. Write the scope boundary down at launch: the moment someone asks for funnels, cohorts, attribution, or custom-event exploration, that is a BI decision, not a stretch of this card.
How can I help you explore Laravel packages today?