Download the PHP package foothing/laravel-simple-pageviews without Composer

Laravel Simple Pageviews

Tracks page views of your Laravel 5.x app for traffic monitoring.

To date, it has been tested with Laravel up to 5.5 and PHP 7.

IMPORTANT If you are upgrading from previous 0.x version please read the release notes.

This package is meant for simple request tracking and not for in-depth traffic analysis. Features:

• track page views
• track unique page views
• customizable whitelist rules
• url filter and crawler filter
• fetch data for reports

Each log record keeps track of the user session, user ip and date.

Setup

Install module:

composer require foothing/laravel-simple-pageviews

Add the service provider in config/app.php:

Publish migration and configuration files:

php artisan vendor:publish provider="Foothing\Laravel\Visits\ServiceProvider --tag="config"

php artisan vendor:publish provider="Foothing\Laravel\Visits\ServiceProvider --tag="migrations"

Run the migration:

php artisan migrate

Finally, add the middleware in your app/Http/Kernel.php:

Configure

In config/visits.php

Rules are meant to filter requests that you don't want to track. Default ones will filter out crawlers (thanks to https://github.com/JayBizzle/Crawler-Detect) and blacklisted urls.

Query methods

Each query method allows for date filtering and will accept up to 3 arguments.

• first argument can be a string preset, a string that Carbon can parse or a Carbon date
• second argument as the first one
• third argument can be an url

Only exception is the aggregate() method, which will accept a limit argument.

Examples:

The input buffer

This package has been tested in a moderate traffic website, like ~20k pageviews / day which makes about 17k database records per day. The visits table will grow up pretty quick and the database might suffer performance issues when it comes to execute an insert or update statement on a table which count hundred thousands (or millions) rows.

For this reason an insert/update buffer has been added. Basically, each visit is tracked in a temporary table that is only used on write operations, while the report and read operations are performed on a separate table.

An artisan command has been added to handle the periodic data dump from the write table to the read table. A good practice might be dumping data each day.

TL;DR configure as follows in your app/Console/Kernel.php (please refer to Laravel docs for scheduling info):

Performances

Performances have been tested in a ~5 million records database with good results. However, i recommend to partition your database tables if size grows nasty, i.e. 1 milion record per partition. Also, a good practice would be to tune your partition to be consistent with date periods (i.e. full year in single partition, single quarter in single partition, etc.) according to your traffic and report type.

License

MIT