UserID "Signing out use-case" - actions still attributed to the same Visitor #7556
Comments
|
Thanks @peterbo for reporting this!
Steps:
|
|
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? |
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 cd1b52d / #6313 |
|
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 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. |
|
@kachkaev @peterbo I wanted to reproduce this issue but AFAIK the documentation at User ID is still valid, as of today is says:
ie:
it seems the user guides are correct, but maybe I'm missing something? |
|
Related issue: Piwik might create too many visits when using userId feature #7691 |
|
@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 |
|
@kachkaev could you try this patch, whether this works for you? https://github.com/piwik/piwik/compare/7556?expand=1 |
|
@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 |
|
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 |
|
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. |
|
Any workaround for this? Thx |
|
We also have this problem with a Angular SPA. There is no full page reload, how should we unset the userId on logout? |
Does not do anything unless `public.piwik` setting is populated with the
following properties:
```
"piwik": {
"url": "http://piwik.example.com/",
"site": 1
}
```
Where `url` is the base url to the piwik instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
piwik instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[piwik blog][1].
Regrettably there is currently a [piwik bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://piwik.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
|
PR: #12141 |
Does not do anything unless `public.piwik` setting is populated with the
following properties:
```
"piwik": {
"url": "http://piwik.example.com/",
"site": 1
}
```
Where `url` is the base url to the piwik instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
piwik instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[piwik blog][1].
Regrettably there is currently a [piwik bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://piwik.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.piwik` setting is populated with the
following properties:
```
"piwik": {
"url": "http://piwik.example.com/",
"site": 1
}
```
Where `url` is the base url to the piwik instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
piwik instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[piwik blog][1].
Regrettably there is currently a [piwik bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://piwik.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Implements the new resetUserId() method from JS tracker in matomo-org/matomo#12141 matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
Does not do anything unless `public.matomo` setting is populated with the
following properties:
```
"matomo": {
"url": "http://analytics.example.com/",
"site": 1
}
```
Where `url` is the base url to the matomo instance (terminating slash is
important) and `site` is the numeric id of the site configured on that
matomo instance.
Iron-router integration was implemented in accordance with
recommendations for single page applications published in the
[matomo blog][1].
Regrettably there is currently a [matomo bug][2] preventing reliable
user-tracking in single-page-applications, hence this is not supported
at this time.
[1]: https://matomo.org/blog/2017/02/how-to-track-single-page-websites-using-piwik-analytics/
[2]: matomo-org/matomo#7556
mattab
changed the title
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".
The text was updated successfully, but these errors were encountered: