0s pageviews, even though heartbeat time is enabled

Hi there,

my heartbeat timer is enabled and set to two seconds, which works for 70% of all users. However, I’m still getting a view 0s pageviews. This is the tracking code in Borlabs:

<!-- Matomo -->
<script type="text/javascript">
var _paq = window._paq || [];
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */
_paq.push(['enableHeartBeatTimer', 2]);

(function() {
var u="%%matomoUrl%%";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '%%matomoSiteId%%']);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
<!-- End Matomo Code -->


Shows 0s on the site.

What could the problem be?


Matomo only sends the heartbeat after at least 15 seconds (which you can change).

Is it possible that 30% of the visitors leave the website in less than 15 seconds?



that could be possible, however, I’ve configured Matomo to send the heartbeat after 2 seconds:
_paq.push([‘enableHeartBeatTimer’, 2]);

Hi I have the same problem. I set the time to 5

1 Like

Note: The delay can’t be lower than 5. If you pass a lower value Matomo will automatically use 5


Ohh okay, so you think the 0s pageviews are all page views under 5 seconds? There’s no way to further improve that?

Might be possible to do that with a custom javascript. Something like this could work
window.addEventListener('beforeunload', Matomo.getAsyncTracker.ping);

But that might actually also cause 2 ping requests if the unload is triggered after the configured delay…

I have enabled heartbeat timer in Matomo tag manager but I see a lot of 0s hits on our relatively busy site

I had asked about this on github https://github.com/matomo-org/matomo/issues/19663#issuecomment-1225478157 and was pointed to the forum (by you :slight_smile:

I have tested this locally now and the time spent gets updated correctly also for single page visits after a short while.

I know @SteveG said previously this could be caused by having cookies disabled, which would make it more difficult to match the original hit that should be updated. In addition we also limit ip addresses to the first 2 places.

I’m still puzzled though by how well this works locally and how badly on the providers’ infrastructure. I know they are using some go-between caching layer (nginx - redis - php maybe). Could that be a problem for the matching?

Hi @miiimoooo
As said Steve, “Visitors are identified with unique visitor ids, that are sent with the tracking requests. […] The visitorid is stored in the cookie if possible. So not using cookies might make the visitor recognition a bit less accurate, as the visitors are then being matches based on a config hash, that is build out of various browser details.
The visitor ID is computed thanks to browser / IP information (that don’t change during a single visit) and some salt that is updated every 1 or 2 days. Then you shouldn’t loose the visitor ID (and if it was the case, you would get a lot of visits with only 1 page view…)
Maybe lots of your clients stay less than 5 seconds on your last page? It can be the case on portals where users know the page very well and jump to another site quickly…?