Nova Google Analytics Laravel Package

Product Decisions This Supports

• "Analytics where the team already works" vs. buying a dashboard. The core decision this package informs is whether site performance belongs inside Laravel Nova or in a separate BI/analytics tool. It converts a vague roadmap aspiration ("let's surface marketing data") into a cheap, demoable option you can put in front of stakeholders within a day rather than a quarter.
• Build vs. buy for internal reporting. Any request framed as "we should build an internal dashboard showing traffic next to our operational data" now has a credible off-the-shelf baseline. Use it to pressure-test build estimates: if a Nova card plus a service account covers 80% of the ask, the custom GA4 Data API integration needs a much stronger justification.
• Reinforcing Nova as the internal back-office platform. Adopting a Nova card is a small, visible vote for consolidating internal tooling in Nova. That matters at renewal time and when defending the Nova line item — this is a concrete capability the licence is already paying for, not just CRUD screens.
• Deflecting ad-hoc analytics requests from engineering. The measurable product value is reclaimed engineering hours: non-technical stakeholders get read-only sessions, users, pageviews, top pages, and referrers with familiar date-range controls, instead of filing "can you pull the numbers?" tickets. Track the volume of those requests before and after — that is the ROI story.
• Scoping the boundary on purpose. This card covers a weekly glance, not analysis. The moment someone asks for funnels, cohorts, attribution, custom-event exploration, or multi-property rollups, that is a signal to escalate to a BI decision. Writing that boundary down now prevents a "small dashboard request" from quietly becoming a platform commitment.
• Explicitly out of scope for the product roadmap. This is an internal operator tool. It should never appear on a customer-facing roadmap, and it does not substitute for product-side analytics or GA4 data modelling work.

When to Consider This Package

Consider it when all of these hold:

• You run Laravel Nova. It is a Nova card, not a general Laravel package — there is no partial-value path outside a Nova dashboard. If Nova is not in the stack, stop here.
• You have an active GA4 property. v4.0.0 migrated off the retired Universal Analytics API; treat v4.0.0 as the only viable version and verify your property is GA4.
• You are on (or heading to) Laravel 11. Laravel 11 support is the headline of v4.0.0 and the main reason an existing v3 install should move. Land it after the framework upgrade, not in parallel — two independent breaking changes will obscure which one broke the dashboard.
• Someone will own the credentials. A Google service account with Viewer access on the property plus the GA4 Data API enabled is the real adoption cost. Governance — who owns the Google Cloud project, the key lifecycle, the permission grant — matters more than the composer require.
• Stakeholders want glanceable metrics only — sessions, users, pageviews, top pages, acquisition — and accept cache-driven freshness rather than real-time.
• Privacy/security review signs off on analytics credentials residing on the app server. Settle this before engineering effort is spent.

Look elsewhere when:

• You need deep GA4 exploration — custom events, audiences, explorations, monetisation. The GA4 Data API surface is large; a Nova card will not mirror it.
• You need multi-property or multi-tenant reporting aggregated across sites. That is a reporting-layer problem, not a dashboard card.
• You need high-frequency or real-time refreshes. GA4 quotas are per-property; every admin dashboard refresh consumes them.
• You are not on Nova, or your Nova major is outside the supported matrix.
• You need vendor SLAs. This is a Tighten open-source package with a small contributor base, zero dependents, and a last release in mid-2024. The realistic posture is "we may maintain a fork." If that is unacceptable, do not adopt.

Adoption caveat worth a ticket: v4.0.0 is a major release with a breaking UA→GA4 migration. Expect config keys, credential shape, and metric names to differ from v3, and plan QA against a real property — not a patch bump.

How to Pitch It (Stakeholders)

For executives: We can put website traffic and acquisition numbers inside the admin panel the team already uses, at essentially zero licence cost. The relevant release is v4.0.0, which moves to Google's current platform (GA4) and supports Laravel 11 — so it aligns with our framework upgrade rather than sitting on a retired Google API. The trade-off is deliberate: it gives us the handful of numbers people actually ask for, not a BI replacement. It reduces a recurring tax on engineering from manual number-pulling, the blast radius is small (a read-only dashboard card with no writes to our domain), and it is fully reversible — removing the card is the rollback. The governance cost is real but bounded: one named owner for the Google service account and property permissions. If analytics becomes strategic, we revisit with a paid platform.

For engineering: A Nova card from Tighten, inert outside a Nova dashboard. Pin v4.0.0 — it is a breaking major (GA4 migration plus Laravel 11 support) and the breaking-change surface differs between fresh install and upgrade from v3. Verify Composer constraints against our Nova major and PHP version. Treat credential provisioning as a discrete, owned work item: service account, GA4 Data API enabled, Viewer grant on the property — a missing grant yields an empty card that reads like a bug. Wire a dedicated AnalyticsDashboard rather than crowding MainDashboard, gate visibility via policy or canSee, and reconcile displayed metrics against the GA4 UI across two or three date ranges and at least one non-admin role before promoting. Cache aggressively around GA4 quotas, make the card show a clear "analytics unavailable" state rather than misleading zeroes, and give us an off switch so it can be disabled without a deploy. Document the credential rotation runbook and metric definitions outside the repository so a future major cannot silently change what a displayed number means.

For marketing/analytics ops: You get a read-only view of selected GA4 metrics with familiar date-range controls, inside the tool the team already uses. You own property access and interpretation of the numbers; engineering owns installation and credential rotation. Expect to hear about freshness up front — this is a convenience view, not a live analytics console, and the GA4 UI remains the place for anything exploratory.