Weave Code
Analytics Laravel Package
artisanpack-ui/analytics
Privacy-first analytics for Laravel with local database storage, GDPR consent management, a real-time Livewire dashboard, session and event tracking, conversion goals, multi-tenant support, and optional GA4 or Plausible integration.
ArtisanPack UI Analytics is a privacy-first analytics package for Laravel that keeps every byte of data in your own database. Built on Livewire 3, it combines session and page-view tracking, custom events, conversion goals, and a real-time dashboard with GDPR-compliant consent management—no third-party data sharing required.
- Privacy first: local storage, IP anonymization, Do Not Track, bot filtering
- Live dashboard: Livewire components with real-time visitor counts
- Multi-tenant: resolve tenants by domain, subdomain, API key, or header
- Extensible: optional Google Analytics 4 and Plausible providers
- Built to scale: queue processing, configurable retention, and aggregation
Frequently asked questions about Analytics
- How do I install artisanpack-ui/analytics in a Laravel application?
- Install it with composer require artisanpack-ui/analytics, then run php artisan analytics:install to publish migrations, config, and assets. You can also publish manually with the vendor:publish command against ArtisanPackUI\Analytics\AnalyticsServiceProvider and then run php artisan migrate. The host app must run Laravel 11 or 12 on PHP 8.2+, or Laravel 13 on PHP 8.3+, with Livewire 3.6.4 or newer. After that, drop the @analyticsScripts directive in your layout and optionally add @analyticsConsentBanner.
- Does this package work in an Inertia, React, or Vue application?
- Partially. Tracking helpers like trackPageView() and trackEvent() are backend PHP calls and work regardless of your frontend stack, but the bundled dashboard is a Livewire 3 component, so rendering the analytics UI requires Livewire in the host app. If you are on Inertia or Vue you would either add Livewire as a dependency or build your own presentation layer against the same data. Treat Livewire 3.6.4+ as a hard constraint when evaluating fit, since a Livewire 4 upgrade becomes a cross-cutting project.
- Can I use artisanpack-ui/analytics alongside Google Analytics 4 or Plausible?
- Yes. The active_providers setting accepts local, google, plausible, or a combination, so you can run the local database pipeline as your system of record and treat GA4 and Plausible as optional fan-out. Be deliberate about which provider is authoritative, because running all three in parallel produces three divergent sets of numbers. Most teams keep local as the source of truth and use the external providers only for cross-checking or ad-platform attribution.
- How does the GDPR consent banner and Do Not Track support work?
- The package ships a consent banner via the @analyticsConsentBanner Blade directive plus ConsentGiven and ConsentRevoked events you can listen to for your own compliance logging. It also supports Do Not Track headers and includes IP anonymization for GDPR-compliant address handling. Consent state is stored locally, so you do not need a third-party consent management platform for basic compliance. If you have strict regulatory requirements, review the consent flow against your own legal guidance before shipping.
- Can I store analytics data in a separate database connection from my main app?
- Yes. Set ANALYTICS_DB_CONNECTION to route analytics tables to an isolated connection instead of your primary database. This is useful for keeping high-write tracking traffic away from transactional tables, or for retention and deletion policies that differ from the rest of your application. Note that you will need to publish and run migrations against that connection as part of deployment.
- Does the package support multi-tenant analytics dashboards?
- Yes, with domain, subdomain, API key, and header-based tenant resolution. Be aware that the multi-tenant configuration moved in version 1.5.0 from analytics.multi_tenant to the shared artisanpack.php core.multi_tenant key, with deprecated keys carried onto the shared configuration at boot as a compatibility shim. That shim signals a future breaking change, so plan accordingly. If you only need single-tenant reporting, keeping it simple shrinks your risk surface considerably.
- How do I stop analytics data being deleted after the default retention period?
- The default retention period is 90 days, after which the cleanup command removes raw records and leaves aggregated history. Set ANALYTICS_RETENTION_PERIOD to null if you want to keep raw page views, sessions, and events indefinitely, or raise it to a value that matches your own data policy. Plan storage growth before you disable retention, since raw event tables grow quickly on busy sites.
- What artisan commands does the package provide for maintenance?
- It ships commands for the full lifecycle: analytics:install for setup, cleanup for retention enforcement, aggregate for rolling raw data into summaries, warm-cache for dashboard performance, export for extracting data, and delete-visitor for honoring erasure requests. These are the hooks you would wire into your scheduler and your data subject request workflow. Review each one's defaults against your retention and privacy policy before enabling them in production.
- Are the AI features safe to enable, and what data leaves my application?
- The package ships four AI agents that call external models, defaulting to claude-sonnet-4-6, which is in tension with a privacy-first posture. Each feature is individually toggleable via artisanpack.ai.features.{key}.enabled, and access is gated by an analytics.ai.use gate whose shipped default allows any authenticated user, so you should override that gate before enabling anything. Treat LLM egress of aggregate metrics as a decision for legal and security, and disclose it in your privacy documentation if you turn the agents on.
- Is artisanpack-ui/analytics production ready, and how should I test an integration?
- Technically it is easy to install, but it currently has zero stars and zero dependents, making it effectively single-maintainer with no independent security review signal or community migration stories. Dependencies are thin (doctrine/dbal, carbon, livewire/livewire) and the dashboard middleware is configurable, defaulting to web and auth. For production, wrap trackEvent() and trackPageView() behind your own anti-corruption layer so you can swap in Plausible or Matomo without rewriting application code, and cover the tracking path with integration tests including your queue configuration.
Weaver
How can I help you explore Laravel packages today?