Laravel Analytics Laravel Package

Getting Started

Start by reading the package README and composer.json before installing—this is a low-adoption package (0 stars, 0 dependents), so the README and source are the source of truth, not blog posts or assumed APIs. Confirm the supported Laravel/PHP versions and the service provider alias before committing.

Minimal install flow:

composer require felipemateus/laravel-analytics
php artisan vendor:publish --provider="Felipemateus\LaravelAnalytics\AnalyticsServiceProvider"
php artisan migrate

Then inspect what was published:

• config/analytics.php (or similarly named config) for tracking toggles, table names, middleware options, and retention settings.
• database/migrations/* for the schema the package expects.
• src/ for the facade, model, middleware, and any tracking service.
• The README’s “Usage” section for the intended entry point—middleware, facade call, Blade directive, or model query.

A good first use case is the smallest one: record page views and read them back.

1. Add the package middleware to the web group in bootstrap/app.php (Laravel 11+) or app/Http/Kernel.php (Laravel 10 and below), if the package provides one.
2. Visit a few routes in the browser.
3. Query the package’s model or facade to confirm rows are being written:

use Felipemateus\LaravelAnalytics\Models\Analytics; // confirm namespace in src/

$views = Analytics::latest()->take(10)->get();

If there is no middleware, look for a helper or facade method such as Analytics::track(...) and call it from a controller, middleware, or event listener. Do not build dashboards until you have verified one row is written per request and that bot/admin traffic is handled the way you expect.

Implementation Patterns

Automatic request tracking via middleware. The most common day-to-day pattern is middleware that records each request: path, method, referrer, user agent, session or user ID, and timestamp. Register it globally or on the web group. If the package’s middleware is too broad, wrap it in your own middleware so you can skip admin routes, API routes, health checks, and asset requests.

// app/Http/Middleware/TrackAnalytics.php
public function handle($request, Closure $next)
{
    $response = $next($request);

    if (! $request->is('admin/*') && ! $request->is('horizon/*')) {
        // call the package's tracker here
    }

    return $response;
}

Manual tracking for meaningful events. Page views alone rarely answer product questions. Use manual calls for domain events—signup, checkout, report export, search—so analytics stays tied to business outcomes:

Analytics::track('signup', [
    'user_id' => $user->id,
    'plan' => $user->plan,
]);

Keep event names stable and documented. A small internal enum or constants class prevents naming drift.

Dashboard queries. Day-to-day use usually means reading aggregates, not raw rows. Build a small reporting service or repository around the package model so controllers stay thin:

$topPages = Analytics::query()
    ->where('created_at', '>=', now()->subDays(30))
    ->selectRaw('path, count(*) as views')
    ->groupBy('path')
    ->orderByDesc('views')
    ->limit(20)
    ->get();

Put these queries in a dedicated class (App\Analytics\Reports) rather than scattering them across controllers. That makes it easy to swap the package out later if adoption or maintenance becomes a problem.

Scheduled reporting. Use Laravel’s scheduler to generate daily or weekly summaries and send them to Slack, email, or a database table. This is often more valuable than a live dashboard for small teams:

// routes/console.php or app/Console/Kernel.php
$schedule->command('analytics:daily-summary')->dailyAt('07:00');

Wrap report generation in a queued job if the queries are expensive, and cache results for the dashboard.

Multi-tenant and user scoping. If the app is multi-tenant, add a tenant_id or team_id to tracked rows—either through the package’s config/extension point or by wrapping the tracker in your own service. Scope every dashboard query by the current tenant. Do not rely on global scopes alone; verify the package model respects them or add explicit where clauses.

Testing. Use RefreshDatabase and freeze time with travelTo() so date-based assertions are stable. If the package offers a fake, use it; otherwise assert against the package’s table directly:

public function test_page_view_is_recorded(): void
{
    $this->get('/pricing')->assertOk();

    $this->assertDatabaseHas('analytics', ['path' => '/pricing']);
}

Keep tracking tests focused on your integration points—middleware registration, event calls, and query scopes—not on the package’s internal implementation.

Gotchas and Tips

Treat this as an unproven dependency. Zero stars, zero dependents, and a very small adoption footprint mean low bus factor. Pin the exact version in composer.json, review the source before production use, and keep a simple fallback plan: a page_views table and a tiny middleware are easy to write if the package is abandoned. Avoid spreading its API across the codebase; isolate it behind your own AnalyticsTracker interface or service class.

Check the release metadata carefully. The listed last release date (2026-10-19) is in the future relative to normal package timelines. Verify tags on Packagist/GitHub, confirm the version constraint resolves, and make sure you are not pulling an untagged dev-main branch. Run composer show felipemateus/laravel-analytics after install to see exactly what was resolved.

Config and migration quirks. Always run php artisan config:clear after editing the package config, and remember that config:cache in production will freeze config values. If the package publishes migrations, check for table-name collisions with existing analytics or audit tables. On existing databases, review the migration before running it—especially indexes and column types.

Middleware ordering matters. If tracking depends on the authenticated user, register the middleware after StartSession and auth middleware. If it runs too early, auth()->id() will be null and user attribution will silently disappear. Test with both guests and logged-in users.

Filter bots and noise early. Raw request logging fills tables with crawlers, health checks, and asset requests. Add exclusions for known bots, robots.txt, .well-known, Horizon, Telescope, and admin paths. If the package does not provide bot detection, add a simple user-agent check or a config-driven path allowlist in your wrapper middleware.

Watch table growth and write cost. Request-level analytics can generate millions of rows quickly. Add indexes on the columns you query most (path, created_at, user_id), schedule pruning or partitioning, and consider queuing writes if the package supports it. Do not run expensive count(*) dashboards directly against a hot, growing table without caching.

Privacy and compliance. Decide early whether you store IP addresses, full user agents, and referrers. If you operate under GDPR/CCPA, anonymize or hash IPs, document retention, and provide an opt-out or consent path. Check whether the package has built-in anonymization; if not, add it in your wrapper before data hits the database.

Timezone consistency. Store timestamps in UTC and convert at the reporting layer. Date grouping bugs are common when app timezone and database timezone differ—verify config('app.timezone') and the database session timezone match your expectations.

Extension points to prefer. If the package exposes events, a custom model, or a resolvable tracker contract, use those rather than editing vendor files or forking. If it does not, wrap it. Keep your own TrackableEvent or AnalyticsService so you can add enrichment (tenant, plan, experiment bucket) without touching package internals.

Debugging checklist. If nothing is recorded: confirm the service provider is auto-discovered, the middleware is registered on the right group, config is not cached with tracking disabled, migrations ran, and the database connection is correct. If rows appear but reports are empty: check timezone filters, soft deletes/global scopes, and whether the package writes to a different table than you are querying. Log one raw row and inspect it before writing more queries.