Combine PHP + JS tracking

[moritz-h]

I want to combine server side and client side tracking, to have advantages of both.
(Server side will count all visits, also where piwik.js is blocked. While JS tracking can give addition informations where it is not blocked, like clicks an outgoing links, screen resolutions, etc.)

I know there was multiple feature requests in the past. (like #9963 or #10422)
They where all closed as duplicate of #9665.

But I think #9665 is something completely different. The discussion is about analysing server logfiles.
I want to combine with PHP tracking not using any server logfiles.

I'm thinking of something like this (just a quick idea):
In php code:

$t = new PiwikTracker(...);
$t->doTrackPageView(...);

And in the template:

<script type="text/javascript">
  var _paq = _paq || [];
  _paq.push(['trackPageView']);
  _paq.push(['<?php echo $t->getSomeId();?>']);
  ...
</script>

If JS or Matomo is blocked PHP will count the visit. If Matomo will run client side it could extend the php tracking with all information the JS Tracker usually saves.

I think this is different from #9665 because a PHP solution is independent from any other server software. Also merging the client and server side tracking data is much easier for Matomo, because it could share any kind of id between server and cliend side. I think the log file analysis is more complicated compared to this.

[tsteur]

I would actually not recommend doing this if page speed or SEO matters to you since you could assume each page view would take potentially 300ms longer. Also you would not be able to use any caching (eg a wordpress caching plugin etc).

[LeoniePhiline]

Three ideas:

1. Instead of using the PHP solution, admins could configure their servers to write the DNT (Do Not Track) header into the server logs. Log entries marked as DNT would be skipped during import. (Allow to use JavaScript tracking and Log Analytics at the same time, and merge the data / deduplicate to avoid double counting #9665) even cookie values could probably be written to the server log, so explicit cookie-based opt-in (or opt-out, which is not really GDPR-compliant) could be written to the logs as well.

2. If using the PHP solution, which can handle cookie-based opt-in more easily, then you could set up a quick script writing a log entry into a file while quickly responding with e.g. a cached CMS response. (Instead of doing a much slower request to Matomo before responding to the client.) The log write could even be done synchronously, as (if logs are rotated) this would not take long. In a second step, the existing python CLI worker would process the php-written and opt-in-filtered log, importing log entries. Matomo would only need to provide a composer package to plug into webites and CMSes, writing a log in a common format, which is pre-filtered by opt-in, augmented with desired attributes and possibly user identifiers, and used instead of the nginx/Apache log.

3. Note that PHP-FPM can also do work after the response has been sent, during shutdown. Laravel even has official support for dispatchAfterResponse(): https://github.com/laravel/framework/blob/302f201400c623a5fe09ab66fdd237dfeff21375/src/Illuminate/Bus/Dispatcher.php#L261 / https://laravel.com/docs/8.x/queues#dispatching-after-the-response-is-sent-to-browser . This means that any software running on PHP-FPM could perform its request and then performa a calm and easy matomo log during termination.