Laravel Matomo Tracker Laravel Package

Product Decisions This Supports

• Privacy-first analytics strategy. Matomo is the leading self-hosted, GDPR-friendly alternative to Google Analytics. This package is the plumbing that lets a Laravel backend emit tracking data (page views, events, goals, e-commerce conversions) to a Matomo instance without JavaScript. It underpins any decision to standardize on Matomo rather than GA4 for EU/regulated markets or data-residency requirements.
• Server-side conversion tracking. Supports tracking that the browser cannot reliably capture: subscription renewals, webhook-confirmed payments, refunds, account upgrades, API/partner events, and offline or back-office actions. This directly enables funnel and LTV reporting that client-side analytics undercounts.
• Ad-blocker and ITP resilience. Server-side dispatch is not blocked by browser extensions or cookie restrictions, so conversion counts are more complete. Relevant whenever a decision hinges on "our analytics numbers don't reconcile with billing."
• Build vs. buy vs. integrate. This is a thin adapter (~a few hundred lines) over matomo/php-tracker. The real build-vs-buy call is Matomo (self-hosted, no per-event cost, ops burden) vs. a managed vendor (GA4, Plausible, PostHog). This package only reduces the integration cost of the Matomo branch to near zero — it should not itself be treated as a strategic asset.
• Unified web + backend analytics. If product already uses Matomo for the frontend, this keeps backend events in the same property, same segments, same dashboards — avoiding a second analytics vendor and a reconciliation project.
• Roadmap gating for compliance work. Useful input to decisions like "can we ship in Germany/France without a consent banner for analytics?" and "do we need a DPA with a US analytics vendor?"
• Low-priority by design. A 0.38 opportunity score is a signal: this is a commodity integration, not a differentiator. Do not let it consume roadmap attention beyond a spike and a thin internal wrapper.

When to Consider This Package

Consider it when:

• You run Laravel/PHP as the core application and already self-host Matomo (or have committed to doing so).
• You need server-side events — webhooks, queued jobs, payment confirmations, back-office actions — and want them in Matomo alongside frontend traffic.
• Data residency, GDPR/Schrems II, or procurement rules make a US-hosted analytics SaaS a hard sell, and Matomo's self-hosted model is the chosen answer.
• Your team is small and cost-sensitive: no per-event pricing, no seat costs, and the integration effort is hours rather than weeks.
• You can accept maintenance risk — fork it, pin it, or vendor the ~single class into your app.

Look elsewhere when:

• Maintenance and security posture matter. Last release was November 2021; with 20 stars and a single maintainer, expect no PHP 8.2/8.3+/Laravel 11/12 compatibility work, no CVE response, and no support SLA. For anything customer-facing or long-lived, plan to own the code.
• License is unresolved. The repository reports NOASSERTION — legal review is a hard gate before adoption. Treat it as unknown until proven otherwise; the safest path is to reimplement the ~one-class adapter against matomo/php-tracker (which has a clear license) rather than depend on this repo.
• You need more than fire-and-forget tracking. No session stitching, no client-side heatmaps/recordings, no warehouse/Reverse-ETL, no feature flags, no A/B testing, no experimentation stats.
• You want a managed product with an SLA — Plausible, PostHog, Fathom, or GA4 remove ops burden that self-hosted Matomo imposes (upgrades, archiving, DB growth, backup).
• You are not on Laravel, or your stack is polyglot and a language-specific adapter fragments your analytics instrumentation.
• You expect vendor-supported upgrades. Nothing here tracks Laravel major versions; a framework upgrade could silently break tracking, which is worse than no tracking because dashboards keep showing numbers.

Adoption criteria, in order: (1) license cleared; (2) Matomo already deployed or budgeted; (3) package vendored/forked with a named internal owner and a test suite; (4) PHP/Laravel version compatibility verified by you, not assumed; (5) a plan for what happens if the maintainer disappears — which, realistically, is "we already forked it."

How to Pitch It (Stakeholders)

To executives (one paragraph): We can capture analytics and conversion data on the server — including payments and renewals that browser-based tracking misses — while keeping all data in infrastructure we control, with no per-event fees and a much stronger GDPR position than a US-hosted analytics vendor. The integration cost is small, but the library itself is a thin, unmaintained wrapper with an unclear license, so the honest framing is: this validates the Matomo direction, not the dependency. Recommendation is to treat it as a reference implementation — spend a short spike confirming it works on our stack, then own a small internal adapter. That keeps the strategic benefits (data sovereignty, no vendor lock-in, accurate conversion counts) and removes the supply-chain and maintenance risk.

To engineering (summary):

• It's a Laravel service-provider + facade around matomo/php-tracker's HTTP API: config publish, tracker singleton, MatomoTracker calls for page views, events, goals, e-commerce, custom dimensions, and user ID.
• Last release 2021-11-18, ~20 stars, single maintainer, license flagged NOASSERTION. Assume no upstream support and no Laravel/PHP version guarantees.
• Recommended path: vendor or reimplement the adapter directly against matomo/php-tracker (clear license, actively used) in ~1 day. Keep the facade-shaped API so call sites stay clean.
• Implementation notes: dispatch from queued jobs, never in the request path (the tracker does synchronous HTTP); wrap in try/catch and fail open — analytics must never break checkout; add an idempotency key on events to survive job retries; respect Do-Not-Track and consent state at the point of dispatch; and add a health check so a dead Matomo endpoint is visible rather than silently dropping data.
• Risks: silent data loss on endpoint changes, double-counted events on retry, unbounded HTTP latency if called inline, and consent/legal exposure if server-side tracking fires for users who declined client-side tracking. Each has a cheap mitigation — own the code and instrument the pipeline.