Avoid using Queued Tracking when importing logs

[tsteur]

fixes matomo-org/matomo#12340

When importing logs there is not really any benefit to use queued tracking for those requests. It might be even rather an overhead pretty much. There is eg no performance benefit because with the importer you can already import X requests at once (which is efficient).

I'd suggest to append to all tracking requests a URL parameter &queuedtracking=0 (see matomo-org/plugin-QueuedTracking#96) which avoids queued tracking. We could have an --enable-queued-tracking flag that sets the value to 1 if for some reason a user still wants to put the requests into queued tracking first.

This way you will always get accurate results whether logs were imported correctly, how many, etc. Queued tracking can otherwise not give this information.

cc @mattab

[Findus23]

Semi-related:
When Queued Tracking is enabled, the warning bulk tracking returned invalid JSON is always thrown as the server always returns a gif.

[EreMaijala]

Indeed, would be great to have this fixed. Here's a workaround that seems to do the trick for me: use the --tracker-endpoint-path=/piwik.php?queuedtracking=0 parameter with import_logs.py.

[Littlericket]

A combination of @EreMaijala argument and "--disable-bulk-tracking" works for us. We've set --recorders to 16 to get at least decent speed ...

[mattab]

Could we implement this fix in Matomo 4 @tsteur ?

[tsteur]

Would generally always add the parameter and not have a flag for it.

So not do this:

We could have an --enable-queued-tracking flag that sets the value to 1 if for some reason a user still wants to put the requests into queued tracking first.

but always do this:

add to all tracking requests a URL parameter &queuedtracking=0

[mattab]

would always add the parameter and not have a flag for it.

👍