@peterbo opened this Issue on March 27th 2015 Contributor

The Signing-out use-case in the Docs states: "In the case where a visitor visits your website and is logged-in (User ID is set) then a visit will be created for this User ID. If then visitor logs out then the visitor has no User ID set any more and a new visit will be created on the page view right after logging out. (if User ID was not used then the requests would have been tracked into one visit and one unique visitor)."

This seems to be not the case. When a user logs out (User-Id will not be set at all (not even empty string) anymore after logging out), all actions are still attributed to the visitor that had the UserId set, if the action is within "visit_standard_length" (or window_look_back_for_visitor). After waiting for timeout of "visit_standard_length", a new visitor without UserId is created, which would be expected even within "visit_standard_length".

@mattab commented on March 29th 2015 Owner

Thanks @peterbo for reporting this!

  • We need to define an official way for users to record requests from a signed-out user.
  • setUserId('') (called with empty string) should be ignored as some users call it this way and it breaks User ID tracking if we change this (it was reported in #7368)
  • maybe we can use setUserId(false) for the "Signing out" use case

Steps:

  • make PR #7518 work well (it aims to solve this issue) and check JS tests are there
  • update the user guide: http://piwik.org/docs/user-id/ to explain to use setUserId(false) when user signed out
@peterbo commented on March 31st 2015 Contributor

Hi Matt!

Instead of calling "setUserId(false)" we could introduce a convenience method like "resetUserId" or "logoutUser" or something more verbose.

Additionally, the recognition code confuses me a bit - in https://github.com/piwik/piwik/blob/master/core/Tracker/Visitor.php#L147 we say that the tracker should not only trust the UserId but also has to search for the user's config_id. In https://github.com/piwik/piwik/blob/master/core/Tracker/Model.php#L358 we UNION results with a) Config_id matched, user_id IS NULL and b) user_id equals the provided user-ID. That includes Users which logged out (no user_id but config_id matches).

Shouldn't we strictly search for the Visitor by user_id if one was provided and at the same time only search a Visitor with user_id IS NULL when a user_id wasn't provided?

@mattab commented on April 8th 2015 Owner

Shouldn't we strictly search for the Visitor by user_id if one was provided and at the same time only search a Visitor with user_id IS NULL when a user_id wasn't provided?

the reason of this lookup is that the first time the User ID is set, we want to assign it to the visit already created - it was done in https://github.com/piwik/piwik/commit/cd1b52dd2e5807d2871e6037815cae2390c5243d / #6313

@kachkaev commented on October 23rd 2015

Looks like the issue still remains. I tried one suggested workaround, but it did not help:

if (Piwik.getAsyncTracker().getUserId()) {
    _paq.push(['appendToTrackingUrl', 'new_visit=1']); // (1) forces a new visit
    _paq.push(["deleteCookies"]); // (2) deletes existing tracking cookies to start the new visit
    _paq.push(["setUserId", false]); // tried null, "", etc.
}
_paq.push(["trackPageView"]);
_paq.push(['appendToTrackingUrl', 'new_visit=0']); // undo forcing a new visit in future calls to "trackPageView"

This script was supposed to run when a user presses "log out" in my web app. Network profiling showed that uid remained in the following tracking requests as it was set up previously.

It seems that the only way it is possible to reset a user at the moment is to refresh the page and start the JS tracker from scratch. That's not what may be wanted in some applications.

In meantime, is there any way of getting access to the raw piwik data and just changing the uid parameter in some dirty way? Restarting the app on logout does not look like a good temporal hack to fix tracking data :ā€“)

UPD:_ I finally discovered that it's possible to have some sort of a solution by setting user to "guest" after logging out:

_paq.push(["setUserId", "guest"]);

That's a bit better, but still not ideal in the reports.

@mattab commented on November 16th 2015 Owner

@kachkaev @peterbo I wanted to reproduce this issue but AFAIK the documentation at User ID is still valid, as of today is says:

Signing-in use case: In the case where a person connects to your website and is not logged-in (User ID is not set), a visit is created. If the visitor then logs-in your website and has a User ID set then the first existing visit without User ID will be updated with the User ID and all future requests from this User ID will be added in this same visit. Result: one user, one visit, one unique visitor. (if User ID was not used it would also have created one visit and one unique visitor).

Signing-out use case: In the case where a visitor visits your website and is logged-in (User ID is set) then a visit will be created for this User ID. If then visitor logs out then the visitor has no User ID set any more and a new visit will be created on the page view right after logging out. (if User ID was not used then the requests would have been tracked into one visit and one unique visitor).

ie:

  • actions before the User ID is set, will be attributed to the same visit as the visit with User ID (ie. the User ID will be set for the existing visit)
  • actions after the User logged out (ie. when setUserId is not called at all) will be recorded in a new visit.

it seems the user guides are correct, but maybe I'm missing something?

@mattab commented on November 16th 2015 Owner

Related issue: Piwik might create too many visits when using userId feature #7691

@kachkaev commented on November 17th 2015

@mattab the guides are correct for cases when a website is a set of standalone pages, not a single-page web app. When opening a new page is just rendering a different template without reloading css and js, then this problem with user sign out takes place. I could not find the way of unsetting userId in the JS tracker ā€“ it looks like the only thing you can do is to call location.reload(); just after they click "logout". Otherwise all the following events and page views will belong to a user that has recently logged out.

@mattab commented on November 18th 2015 Owner

@kachkaev could you try this patch, whether this works for you? https://github.com/piwik/piwik/compare/7556?expand=1

@kachkaev commented on November 18th 2015

@mattab Iā€™m afraid it will be difficult for me to check this case now since I have already switched to another user-tracking approach in my web app.

Looking at the implementation of setUserId in the PHP tracker and in your change, I see a tiny bit of inconsistency. It may be worth changing the behaviour a little.

The PHP version of the method strictly requires you to supply false to reset userId. The patch suggests that the JS method will also work when you give it undefined or null (as well as no argument). I think it would be nice to handle the data in the same way. Maybe by making things strict and throwing an error when userId is not false or a non-empty string, it will be possible to avoid confusion with the method.

@vladgurovich commented on December 23rd 2015

I second @kachkaev request -- in a modern single page application where there are NO full page reloads, we need a way to reset the user id upon sign out

@kernins commented on August 22nd 2016

In my opinion, there should be no "magic" values to reset userID, but two clearly distinct API methods: setUserId & resetUserId. Resetting userID is necessary only on specific event - user logout, there is no need to reset it just in case (as no-user-id is the default), and so - no need in more "opaque" universal set/reset method

Or, if there are some strong reasons to have one universal method, magic value must be accompanied with proper validation, which will throw an exception when value is invalid and not magic, as already suggested above.

@1ucay commented on September 24th 2016

Any workaround for this? Thx

@saithis commented on August 21st 2017

We also have this problem with a Angular SPA. There is no full page reload, how should we unset the userId on logout?

@znerol commented on October 3rd 2017

PR: #12141

Powered by GitHub Issue Mirror