Bounce count / rate might not be accurate: add Non-interaction events feature

[tsteur]

Just seeing bounce count is calculated by sum(case " . self::LOG_VISIT_TABLE . ".visit_total_actions when 1 then 1 when 0 then 1 else 0 end

but it looks like visit_total_actions is also increased for events, searches etc.

This means when there is a pageview followed by an event, it is not counted as bounced but it should be I think

[hpvd]

hmm why counting as bounced? If there's an event, the visitor does not disappear suddenly, do he?
Maybe you can give an example for the kind of event you have in mind?

[tsteur]

Say you use JavaScript Error Tracking feature in Piwik which triggers an event when there is a JS error. It would never count any bounce. Or maybe there's a video player on a page that starts automatically and tracks an event etc.

Some users might not want to have a bounce counted after a certain event as there was some kind of interaction but at list Piwik describes it as follows:

The percentage of visits that only had a single pageview. This means, that the visitor left the website directly from the entrance page.

With the current implementation this is not the case. For SEO only considering pageviews might be better?

[hpvd]

hmm, thanks for examples and pointing to piwiks definition of a bounce.
We make the observation, that more and more visitors visit only one page.
Maybe that's not always bad. E.g. if they find exactly what they were looking for that's pretty fine.
They could stay for 5minutes on the site: reading, open a image lightbox, watch a video etc.
That's not bad. They could also have seen the advertisements on the site directly, in image gallery or at the beginning of the video... They could perfectly keep in mind the brand of the website.
And next time they see a result in google of the site they will come back because they trust the brand and become returning visitors everytime they search on the same topic area.
So these visitors are bounced?
What should they do more if google brings them directly exactly to the place they were looking for?
The better google's algorithms work, the less pages needs to be visited (at least at non ecommerce sites)
Maybe a bounce is only if people leave within 5-10 seconds and trigger no event...

[tsteur]

A bounce doesn't have to be something bad. It can be good or bad. It always depends on the site and probably even on the page whether a bounce is good or bad. I'm not saying something is good or bad. Only saying that the current bounce calculation doesn't match the documentation in the UI and what users might expect.

[hpvd]

sure, i get this :-)
Were only examples...

[hpvd]

For many many people bounces are bad. Otherwise they would not count them...

[mattab]

For this we need a new feature, the ability to define a given Event tracking request as "Non-Interactive". By default, events are "interactive" and assume that user did an action (clicked mouse, or typed on keyboard). When an event is marked as "non Interactive" then the event would not affect the bounce rate, nor would it affect "Time on website" or "Time on page".

For reference see Google Analytics documentation about non interaction events: https://support.google.com/analytics/answer/1033068#NonInteractionEvents

And also: https://developers.google.com/analytics/devguides/collection/analyticsjs/events#non-interaction_events

[mattab]

Renamed issue. This also refs: Time spent on page calculation is buggy #9198

See description of issue with Time on page here: #9198 (comment)

[SR-mkuhn]

How is a change/misscalculation mentioned in #9198 not a bug? This might be an enhancement but as it was renamed to include #9198, it is also a bug - and set those numbers in unreliable light.
Were the numbers wrong in 2.15.0 or were they already in 2.14.3?

[tsteur]

They were already wrong/inaccurate for quite a while. Maybe it would be worth keeping the bug issue #9198 and the original issue of this since we can maybe fix them easier without big changes whereas this issue is hard to implement and probably not going to happen in next 12-24 months.

#9198 and this issue might be possible to fix with just a few lines

[mattab]

@tsteur re-opened #9198 as I didn't realise it was much easier than #9199

[JeSuisUnCaillou]

I also have a problem with the bounce rate :
The bounce count of a page is only counted for the entries. So it has to be divided by the number of entries in order to get the bounce rate.
In the Piwik API, VisitSummary is not calculating the bounce rate like this, it is dividing the bounce count by the number of visits, which results in a bounce rate way much lower.

Is it possible to fix it somehow, in order to get the right bounce count with VisitSummary ? The summary it gives us is very useful, but the bounce rate is unfortunately not corresponding to the bounce rate calculated by other API modules.

[hpvd]

for everyone interested in bounce rate,
a new characteristic ratio as a "new kind of advanced bounce rate"
is proposed in #9633

[tobiasblessing]

After implementing Matomo Analytics at our website I was wondering whether you could lable tags/events as non interaction.
So I totally vote for this enhancement.

[MatomoForumNotifications]

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/does-a-clicked-outlink-count-as-a-bounce/41795/3

[dave-anh-kpi]

Hello,
When do you think this new feature "non-interaction event" will be available in Matomo?
We were used to trigger some display events with Google Analytics (product viewed, banners, chatbot...). With Matomo, we cannot be completely free in our tracking methods since it is killing our Bounce Rate...
A lot of my clients are asking why the bounce rate is so low after migrating their tracking from GUA to Matomo.

[heurteph-ei]

For "display events" you may use content impression. Bur not sure if this is counted or not in the bounce rate calculation...

[9joshua]

I have another request for this. A customer wishes to create an event for 404 errors while still counting the visit as a bounce.

[9joshua]

Another customer request for a non-interactive event.

Curently, calling an event like this passes the 5th value as a data parameter:

_paq.push(['trackEvent', 'Category', 'Action', 'Name', '22', {
    nonInteraction: 1
}]);

Perhaps we could use this to assign an attribute to events which should be ignored for bounce calculations?

[9joshua]

Another customer has requested this. It was available to them in GA and they need continuity of their tracking strategy as they move to Matomo.

[9joshua]

I received another request for non-interaction events from a customer who needs to track content interactions while still counting the visit as a bounce if no other actions are taken.

[atom-box]

Opposite concept (folks asking for ways to take visits away from Bounce):
#17549 Report "Engagement rate" instead of "Bounce rate"
#9633 new characteristic ratio: rate of interested visitors (advanced bounce rate)

[atom-box]

Another upvote for this. A user is feeling data inconsistency:

We are consistently measuring lower bounce rates in Matomo when compared to other tools like GA and Shopify analytics for multiple clients. GA and Shopify tend to be in close agreement on the bounce rate, while our Matomo observed value is 30-50% lower than the consensus of the other two. Is this a common difference... For additional context, our other Matomo metrics compare well with the GA metrics we have access to, namely revenue, order count, and sessions.

[davidanaisparker]

Another upvote for this. We need to be able to exclude certain events from calculations especially bounce rate. We have a 3d environment and use events extensively to automate things and track what the app is doing as well, these events skew the calculations, for example we provide users a guidance animation upon first visiting to help onboarding them... when they dismiss this it should not count towards the fact the session is not a bounce.

[SW-Vincent]

Hi,

Another upvote for this,.
User case :

• we'd like js errors not to count as bounces ;
• we'd like to make some tags (ex : element visibility when element can be above the fold) not to count as bounces ;

[ayayronr]

Another upvote - we have events automatically fire that are not interactions. Bounce rate immediately took a huge hit after publishing the events, so it is no longer reliable data.