-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Ping requests to report a better 'time on page' #2041
Comments
(In [3788]) fixes #739 - addEventListeners() on mouseup and mousedown; good catch, Matt!
refs #2041 - setHeartBeatTimer - uses setTimeout, so it happens only once (vs setInterval is recurring); only happens on the landing page; intended to be used to improve bounce rate report; changed it to send ping=1 in the request |
I reworked setHeartBeatTimer() in [3830]. It now takes an initalPingDelay and recurringHeartBeatDelay as parameters. By default, this is disabled. |
The initial ping request contains "ping=1". Use this to improve bounce rates and visit time. Subsequent heartbeat requests (if recurringDelay != 0) contain "hb=1". I'm going to defer adding event handlers as there are issues with propagating some events like keyclicks. Mental notes to self:
|
how do you define 'activity'? Will the ping be sent if user is looking at another tab, another window, or even away from computer? |
activity: mousemove, click, mouseup, mousedown, mousewheel, scroll, DOMMouseScroll, resize, keypress, keydown, keyup, focus, and blur
Yes, ping would be sent. That's why there's a check for activity. If there's no activity, I propose to no longer check. I'll commit my changes after some more testing. |
(In [3838]) refs #2041 - setHeartBeatTimer() now takes the minimumVisitLength and the heartBeatPeriod (time between pings) as parameters; this is simpler than initial ping + recurring hb; requests contain "ping=1". also updated to jslint 2011-02-03 |
(In [3839]) refs #2041 - rollback buggy n/2 logic |
(In [3840]) refs #2041 - undo previous optimizaton to ping on first page of a new session |
(In [3841]) refs #2041 - add guard |
Client-side changes are done, so it would be nice to have the server-side change done in time for 1.2 but we can roll into the next milestone. |
How often are the activity tests done? every second? Just thinking of keeping JS performance overhead low with this new feature. I wont be able to do this in time for 1.2, so it will go in 1.3. Is pinging disabled by default? thx |
Yes, disabled by default; frequency is user-defined. |
Before enabling this by default I think we could try it on some heavy websites, that are using GA, other libraries (jquery eg.) and doing Javascript heavily. Then we could see if Piwik adds any unexpected performance overhead. For example it would be nice to say: Piwik will query a few JS variables every second to assess if the visitor is active or not, but will not conflict with any other library or Javascript and should not affect performance at all. What do you think? for example, have you tried it on a a running piwik loading the dashboard full of widgets. |
I think, disabled by default, but easy to enable, this would make it a really cool feautre. Also, should be made available via the 'advanced' javascript tag generator see #1845 |
Just wondering where we are on this. I'm in the process of switching several sites from GA to Piwik, and this feature is pretty important to me. Does 1.x mean it's going to be in an indefinite release between now and 2? |
Polrbear, yes currently not roadmapped for 1.7 but it might change |
I'm interessed too by this feature. I have activate it on my website, but the presentation in the server side, isn't perfect (the ping is show as a new page visit). I hope, that it can be made for 1.7. Thanks. |
Another bug report: http://forum.piwik.org/read.php?2,83913,page=1#msg-84060 NOTE: This feature does not work currently |
Proof Reading the upcoming book about Piwik, it's really good. it gives me an idea related to this feature:
We could allow for this other addon: send a fake Pageview 15seconds after arrival: http://analytics.blogspot.com/2012/07/tracking-adjusted-bounce-rate-in-google.html - might require the ping query so it doesn't inflate Page view counts, but changes Bounce rates for all other metrics. |
Note from Anthon: The original thinking was, fire a ping once the page has been open some minimum amount of time, and keep pinging as long as there's some mouse activity. Basically, the goal would be to report lower bounce rates (ie if the first and only page visited) and more accurate time on site for the last page visited on a site. The Page Visibility and traceCallback changes means the ping isn't sent until a tab gains focus and has been open the minimum amount of time. Further pings require some activity while the tab is open. We probably need a way to restart the heartbeat if the tab regains visibility. Also, the inactivity logic doesn't work with passive activities (eg streaming media), but I think could be addressed by adding an API for players. (Are you using event tracking for this?) This obviously isn't feature complete, so if anyone has ideas on how this should work or could work better, feel free to share your thoughts. |
I'm very interested in this feature but unfortunately time is missing to implement it for now, unless someone jumps in and produces a patch we can use! Or if you can sponsor the feature please get in touch at sponsors at piwik.org |
Great feature, looking forward to it. (Just commenting to add myself to the CC list.) |
See also: #5208 Detect when a user is actively browsing or using the webpage, for more accurate Time on page |
Summary of discussion so far:
Maybe you have more thoughts, cc @diosmosis |
thanks for the summary. Hopefully it's ok when I would like to ask to clarify the target even more:
Many thanks! |
@hpvd currently there is no feature - the code related to heartbeat timer / |
Hey guys, This is how it should be . About the : need to decide on "ping" strategy eg. ping first time after 20s, then ping less and less often eg. [20, 40, 60, 100, 160, 260, ....] ? ,ping strategy,i think from 15seconds ,to 15 seconds is okay or even from 20 seconds to 20 seconds,but this also can depends on user shared enverimonths,if the user haves Shared hosting,and this ping in eats lots of resources from the server,cpu,ram,i think their should be an recomandation for shared ,vps and dedicated server. we need to ping only when the page is actively viewed (we need to detect active tab/window somehow, maybe Page Visibility API can do this?) Exactly,we need to ping in,only when the page is actively viewed,and this can be done with the events,that we talked more earlier.If they are no events,basically the page is maybe left in the tab for hours,and user is watching an youtube clip,so it`s not in your page tab,so basically this will just inflate the numbers witch is not good. The events should also be there,and easily accesibile,as options in piwik,and we let the user freedom to decide,maybe some of us only needs some of the events,or all,it depends from case to case. @matt : define & document a new Tracking API parameter, eg ping=1 (or better name!) I think tracking api parameter, ping =1 ,is an good name,but what 1 will represent ? Hopefully we will see this in the new piwik 2.14. |
"1) = additional thing to other already available "site is active" signals" (maybe one should taking into account the date this ticket about supporting ping requests was created/ started: "21 Jan 2011" - at this time there was no great "event tracking" available within piwik) |
so this will work,basically on 15 seconds to 15 seconds to the end user pings? I agree,hpvd,there is no great "Event tracking" available in piwik. |
@masteranalyze now standard event tracking is fine for me. |
@hpvd is clearly that from that time to today,piwik did have an great evolution,but i think it can be even more great,as except the fact the anaytics are private,there is one more good thing and an big advantage for PIWIK - Server Side Tracking,witch is not possible neither in Google Analytics,neither in StatCounter,neither in Clicky or any other stats available on the market today. The event tracking we have today,of course is more good,that what it was missing in 2011,i totally agree with you,but nowdays for every event tracking,you need to add one more line code into the javascript,one more for another event and so on,it will be alot more easily,if in the event tracking back -end it will be events with options : YES ,NO ,and addiacently the options to it,so everybody can Enable or use them,right now Events are not quite so easily setup for someone who does not write code. "If you are using event tracking today, you got lots of activity signals from each site during the usage by the visitor." - i totally agree with you,with the pointing of that only people who setup the events and puts additionally script,can track the events,or if the software your using,haves integer piwik,you will have those events,else not. " So the ping only needs to be an additional possibility to determine if there is activity. hpvd,create an new ticket for PIWIK EVENTS SCRIPTS,and there we can put an list of EVENTS,and the accordingly script,but afterwards,how we manage to put them into the backend of piwik?! |
@masteranalyze |
Fixed in #8069. |
@diosmosis \o/ |
Hi all, |
+1 to this as well. And agreed with @jgebal. This would be really great option to enable! |
@ReessKennedy feel free to post in the other issue: #8225 (this issue here is closed) |
Feature is now documented at Accurately measure the time spent on each page |
many thanks for documenting this! |
This is documented in the changelog: http://developer.piwik.org/changelog On 18/12/15 11:43, hpvd wrote:
V.G.Hindriksen MSc., CEO |
thanks for pointing there. |
@hpvd improved the doc, and also created New FAQ: How do I improve accuracy of “Time spent on page” and “Visit duration” metrics? |
Thanks very much! |
good work @mattab and the team! |
Currently, the last page view is set with a 'time on page' of zero seconds.
Instead, we could regularly ping the Piwik server with a request that notifies Piwik that the user is still on the website.
This request should not record new page view, only increase the visit_total_time counter.
Also, we should only throw this request when the user is actually looking at the page, not doing something else in some other tabs.
The risk with this feature is that instead of improving the report accuracy, we end up inflating numbers: a lot of users leave pages open in other tabs for hours and don't do anything about it. We should heavily test to ensure we never throw a request on a page where the user didn't interact with recently. Some interactions we can maybe detect: mouse click, mouse move, etc.
Of course, we should not make everything slow by adding handlers on mouse move, etc.
Also, once this feature is implemented, a new checkbox should be added to the Advanced section in the 'Tracking Code' admin page. Checking it will generate JS code that enables this feature.
The text was updated successfully, but these errors were encountered: