@tsteur opened this Issue on November 11th 2015 Member

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 commented on November 12th 2015

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 commented on November 12th 2015 Member

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 commented on November 12th 2015

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 commented on November 12th 2015 Member

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 commented on November 12th 2015

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

@hpvd commented on November 12th 2015

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

@mattab commented on November 18th 2015 Member

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 commented on November 18th 2015 Member

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

See description of issue with Time on page here: https://github.com/piwik/piwik/issues/9198#issue-116406139

@SR-mkuhn commented on November 19th 2015

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 commented on November 22nd 2015 Member

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 commented on November 23rd 2015 Member

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

@JeSuisUnCaillou commented on December 23rd 2015

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 commented on January 26th 2016

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

@tobiasblessing commented on September 3rd 2020

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.

Powered by GitHub Issue Mirror