Laravel Pirsch Laravel Package

Product Decisions This Supports

• Privacy-first analytics strategy: Pirsch is a cookie-less, GDPR/DSGVO-friendly, EU-hosted analytics platform. This package is the official Laravel integration, letting the product team ship first-party, server-side analytics without a cookie consent banner — a meaningful conversion-rate and legal-risk lever.
• Build vs. buy: Replaces the "should we build our own event pipeline or wire up GA4/Plausible/Matomo?" debate with a thin, low-maintenance integration over a hosted API. Engineering cost is a composer require plus a small config; the vendor carries storage, dashboards, and compliance.
• Server-side tracking / ad-blocker resilience: Because events can be sent from the Laravel backend rather than the browser, the PM can rely on conversion and funnel numbers that aren't systematically undercounted by uBlock/ITP — a prerequisite for trustworthy roadmap prioritisation.
• Feature-level product telemetry: Server-side pageview and custom-event calls are enough to instrument onboarding funnels, activation, pricing-page behaviour, and feature adoption without a full CDP.
• Roadmap fit for the 1.1.0 release: The Laravel 13 compatibility bump is a pure maintenance signal. It de-risks our planned framework upgrade and confirms the package is actively maintained — relevant if we are choosing between this and an abandoned wrapper.
• Self-hosting and data-residency options: Supports the EU-data-residency and "no data leaves our infrastructure" requirements that come up in enterprise procurement and DPA reviews.

When to Consider This Package

Adopt when:

• The backend is Laravel (8–13) and we want analytics wired into the app with a facade/config, not a separate JS snippet and tag manager.
• Privacy compliance (GDPR/DSGVO/CCPA), cookie-banner reduction, or EU hosting is an explicit requirement.
• We need lightweight pageview + custom-event tracking, not a full product-analytics stack (cohorts, session replay, A/B testing, warehouse-native SQL).
• We want tracking calls that survive ad blockers and can be invoked from jobs, CLI commands, and webhooks — not just HTTP requests.
• We are willing to depend on a paid SaaS endpoint (Pirsch) or run Pirsch's self-hosted option; the package is a client, not the analytics engine.
• We value a small, auditable dependency: the 1.1.0 changelog is a single compatibility PR, which means low surface area and cheap upgrades.

Look elsewhere when:

• We need product analytics depth (Amplitude/PostHog/Mixpanel-class), session replay, experimentation, or a warehouse-first model (Segment/RudderStack/dbt).
• The org has standardised on GA4/Meta and needs ad-network integrations and audience exports.
• We cannot accept an external analytics vendor or self-hosted Pirsch operational overhead.
• The team is not on Laravel, or is on a version outside the supported matrix — the package's value proposition is the framework integration, not the API.
• We need guaranteed SLA, vendor security review artifacts, or a formal support contract; this is a community-style integration around a commercial API.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can replace cookie-banner-gated analytics with a privacy-compliant, EU-hosted setup in roughly a day of engineering. Pirsch's official Laravel package gives us server-side pageview and event tracking from our existing codebase, which means fewer consent prompts, fewer legal reviews, and conversion numbers that ad blockers can't quietly erase. The just-released 1.1.0 is a compatibility update adding Laravel 13 support — no breaking changes — which tells us the integration is being kept current and won't become a liability during our next framework upgrade. Cost is the Pirsch subscription; the integration itself is near-zero maintenance.

For engineering: It's a thin, official wrapper — config file, facade, and a handful of tracking calls that can be made from controllers, middleware, jobs, or console commands. Upgrade path from 1.0.0 to 1.1.0 is a single PR adding Laravel 13 support; no API changes, no migrations, so it can ride along with the framework bump. Keep tracking calls behind a small internal service or event listener so the vendor dependency stays swappable if pricing or requirements change. Worth confirming we're comfortable with the package's support model and that the client ID/host config is environment-scoped before we instrument anything user-facing.