Nova Matomo Analytics Laravel Package

Product Decisions This Supports

• Build vs. buy for an internal analytics glance. The integration surface is a Matomo URL, a site ID, an API token, a published config file, and one card registration in NovaServiceProvider. That is small enough that "build it ourselves" is genuinely on the table, so the decision is not "platform or no platform" — it is whether a sub-day integration beats a one-to-two day first-party Nova card against the Matomo Reporting API. Price it as a time-to-first-dashboard purchase, not a strategic commitment.
• Where analytics live in the daily workflow. The business case is consolidation of context: traffic, campaign, and content-performance numbers adjacent to the admin tasks they inform (publishing cadence, section launches, marketing pushes) instead of a second tool and a second login. This is an adoption and context-switching decision first, a technical one second.
• Roadmap positioning. If adopted, it becomes the low-effort "quick pulse" baseline covering the 80% case of "someone just wants to see the number." It does not justify deferring a real BI/reporting investment — it renders Matomo's existing views and does not compose new metrics. Keep the proper reporting roadmap item open and say so explicitly in the decision record.
• Access and governance. Token-based access to a private Matomo instance forces decisions that are yours, not the package's: who inside the admin panel sees which site IDs, whether the card respects Nova's authorization model (assume it does not, until proven), and whether a Matomo token in an admin surface clears your security posture. These need a named owner before rollout, not after.
• Multi-site and multi-brand policy. The package displays Matomo's reports; it does not consolidate them. Multi-site setups force a choice between one card per site ID (duplicated config) and a consolidated cross-site view — the latter is a genuine product gap worth recording as out of scope.
• Release and dependency policy. Pre-1.0, last release April 2021, 22 stars, zero dependents, single maintainer. That supports a decision to pin the version, treat it as a timeboxed pilot, and set the expectation that this is a convenience dependency you may fork (MIT permits it) or replace — not a long-lived commitment. Budget a recurring half-day per upgrade cycle to re-validate against Nova, Laravel, PHP, CSP, and Matomo changes.
• Pilot success criteria you define up front. Useful, measurable framing: weekly active viewers of the card, reduction in Matomo logins and tab-switching, time-to-answer for routine traffic questions, and ticket volume for "this number looks wrong." Pre-agree the kill trigger — Nova incompatibility, unresolved token-exposure concern, or maintenance cost exceeding a first-party rebuild — so the decision is made on evidence rather than drift.

When to Consider This Package

Consider it when:

• You already run both Laravel Nova and a self-hosted Matomo instance. The entire value is the bridge; with only one of the two, there is nothing to evaluate.
• You want a read-only pulse dashboard for a small internal audience (marketing ops, content team, founders) and the acceptable answer is "surface the Matomo report we already trust," not "rebuild the report."
• You accept that the work is configuration, not engineering: Matomo URL, site ID, auth token, publish config and assets, register the card.
• You can pin the version and accept 2021-era code with no active maintenance — after verifying compatibility against your Nova major and PHP/Laravel versions on a throwaway branch first.
• Your security review permits exposing Matomo data inside the admin panel with a scoped, read-only, rotatable token, and (if the implementation is an embed) a CSP frame-src allowance plus framing enabled on the Matomo side.
• You want to avoid duplicating analytics logic — the numbers stay defined by Matomo, which is a real advantage over hand-rolled cards that silently drift from the source of truth.

Look elsewhere when:

• You need consolidated multi-site or cross-property reporting, custom metric definitions, or metrics Matomo does not already render. This package displays Matomo's views; it does not compose new ones.
• You need SLA, active maintenance, or a supported 1.0 API. Zero dependents and a four-year-old last release mean you are effectively the maintainer of your fork if it breaks.
• Your admin panel is customer-facing or externally visible — embedding third-party analytics and credentials in a user-facing surface is a hardening project, not a config change.
• Nova version compatibility is unverified for your install. Nova is a paid, closed-source host whose card and asset APIs have moved across majors; if it does not render cleanly, the fallback is a bounded first-party card against the Matomo API, which is often the cheaper path.
• You need analytics to drive automated decisions (alerts, thresholds, gating) rather than human eyeballs — call the Matomo API directly.
• You cannot tolerate embed UX compromises — fixed heights, theming mismatch, no deep-linking into Matomo reports, limited responsiveness inside the Nova shell.
• You are not prepared to resolve the implementation ambiguity first: the package description describes iframe embedding of Matomo widgets, while the v0.5.0 changelog describes card aggregation changes (sum instead of latest value, an avg_time_generation rename). Those imply different implementations with different security reviews, failure modes, and metric semantics. If nobody on the team will read the source before committing, this is not the right package.

How to Pitch It (Stakeholders)

For executives. This is a small, free (MIT) integration that puts our existing Matomo website analytics inside the Laravel Nova admin panel, so the team can check traffic and campaign performance without leaving the tool they already use. The business case is reduced context switching and faster routine decisions — the numbers are Matomo's own, unchanged, so this adds convenience, not new analytical capability. The costs are low but real: a pre-1.0, 2021-era package with negligible adoption and a single maintainer. The recommendation is therefore a timeboxed pilot on an internal, non-critical dashboard with a pinned version and a defined kill switch — not a standard. Approve a short trial with success metrics (weekly viewers, fewer Matomo logins, support-ticket volume) and a go/no-go review; if the integration proves brittle, a first-party Nova card against the Matomo API is a well-understood fallback that should be sized before we commit, so we choose this package deliberately rather than by default.

For engineering. It is a config-driven Nova card that surfaces Matomo reports in the admin panel, with the Matomo URL, site ID, and token supplied through a published config file; install, publish, register — no schema, migrations, queue workers, or data pipeline, so blast radius is confined to the admin UI and rollback is removing the card registration. The real work is not the integration, it is the perimeter. Verify Nova major and PHP/Laravel compatibility first on a throwaway branch, because that is the most likely hard stop, and treat this as a plugin pinned to a vendor product you also keep upgrading. Resolve the documentation inconsistency before estimating: read the source and determine whether the card is an iframe of a Matomo report, a Reporting API client, or both — it changes the security review, the scaling model, the failure modes, and whether an outage is our problem or Matomo's. Determine where the token lives and who can read it, and insist on a scoped, read-only, rotatable Matomo token. Confirm the card respects Nova's authorization model rather than exposing analytics to every Nova user, add the Matomo host to CSP frame-src with framing enabled and no mixed content, and decide what the card does when Matomo is unreachable (blank card vs. exception in the dashboard render path). If the sum-vs-latest aggregation change is real, note that it silently redefines numbers under unchanged labels — the dashboard owner, not the package, owns that correctness risk. Pin the version, assume no upstream fixes, plan for fork-on-first-breakage, and assign an owner now for the recurring half-day per upgrade cycle.