Problem with changed idvisitor and idvisit after login

fangyi · November 9, 2023, 9:05am

Hi all,
We have a strange problem with matomo log: idvisitor and idvisit of a viewer both change after he/she logs in. My understanding is that after logging in, the viewer’s idvisitor and idvisit should remain the same.
I tested the situation with my own account. When I checked the idvisitor value in Chrome DevTool, everything looked fine. However, in the matomo log collected, both idvisitor and idvisit values changed after log in.
Is there any suggestion for fixing this issue?

heurteph-ei · November 10, 2023, 5:04pm

Hi @fangyi
Do you use userId while tracking?

fangyi · November 13, 2023, 7:17am

Hi Philippe @heurteph-ei
Yes, we are using userId.
I can see my account information in the user_id column of matomo log, but the idvisitor value of the entry is different from the idvisitor before login (i.e. also different from the value I saw in Chrome DevTool when testing). This makes us unable to track a viewer’s journey before login.
During login process, the viewer will be briefly directed to another domain to key in login information, and then directed back to the same page. Could this be the cause of changed idvisit and idvisitor in matomo log?

heurteph-ei · November 13, 2023, 10:29am

Hi @fangyi
Is it related to:

github.com/matomo-org/matomo

UserID overwrites VisitorID, but doesn't claim existing Visit

opened 08:45AM - 28 Oct 22 UTC

SeverinEventfrog

Major worksforme Can't reproduce (yet)

We run a webshop. Users can put items in their basket and stroll around, but onl…y need to login with a userId when starting the checkout proceedure. We want to have all actions pre-login also assigned to the userId. However, when enable_userid_overwrites_visitorid = 1 is set (is by default), then Matomo will not find the existing visit pre-login and instead create a new visit for the userId. Thereby loosing a lot of user interactions, like looking at products and not buying them. ## Expected Behavior enable_userid_overwrites_visitorid = 1 Navigate to the home page 1 visit with 1 action with unknown user Navigate to the login screen 1 visit with 2 actions with unknow user Login and call setUserId function 1 visit with 3 actions with known user (merging all pass actions) Logout 1 visit with 4 actions with know user (it continues to put actions in the same visit) ## Current Behavior enable_userid_overwrites_visitorid = 1 Navigate to the home page without any Cookie 1 visit with 1 action with unknown user Navigate to the login screen 1 visit with 2 actions with unknow user Login and call setUserId function 1 visit with 2 actions with unknown user 1 visit with 1 action with known user (it didn't merged the pass actions) Logout and no longer use setUserId 1 visit with 3 actions with unknow user 1 visit with 1 action with known user ## Possible Solution When userId overwrites visitorId, the check for existing visits should also check for visits of the visitorId, if that one is supplied. As when the visitorId is supplied, the trackingrequest clearly states to be from that visitor. So claiming the visit with the newly supplied userID is expected behaviour and even documented here: https://matomo.org/faq/general/how-are-requests-with-a-user-id-tracked/ "When a user logs in, Matomo counts all actions before and after logging in as one user, one visit, and one unique visitor." Inuitively, this check could be done only, if no active visit for the userId is found. However, I would suggest claiming the given visit even if another already assigned to the userId exists, as they might be from different devices within 20 minutes and just adding to the older one would disconnect the newer visits's previous actions from the userId. Pseudocode: get_existing_visit(visitorId, userId){ visits.add(get_visits_by_visitorId(visitorId)) # make sure, that visitorId has not already been overwriten by userId! visits.add(get_visits_by_userId(userId)) visits.sort_by_last_action_time() return visits.pop() } ## Steps to Reproduce (for Bugs) See Behavior, we use JavaScript Tracking and the _paq.push(['setUserId', 'USER_ID_HERE']); ## Context In our Webshop, we want to know what a user has looked at and done during one sitting. If they happen to log in, we want all their actions to be mapped to their userID. We want this mapping to work, even if the user deletes their Cookies. We also want to be able to use the Matomo UI to click on Visitor-Profile and see all past actions of that User ( not only Visitor!). We are aware of this option: enable_userid_overwrites_visitorid = 0 Navigate to the home page 1 visit with 1 action with unknown user Navigate to the login screen 1 visit with 2 actions with unknow user Login and call setUserId function 1 visit with 3 actions with known user (just setting userID, vistorID unchanged) Logout 1 visit with 4 actions with know user (it continued to put actions in the same visit) But then, should the user ever delete their Cookie or much more likely just use another device, they would get another visitorID. The userID link is our active workaround but is slow for DB SELECTS and the Matomo Admin UI will only show all actions of the same VisitorID and not userID. ## Your Environment * Matomo Version: 4.10.0 * PHP Version: 7.3 * Server Operating System: Debian 4.19.x * Additionally installed plugins: ** FormAnalytics ** GoogleAnalyticsImporter ** HeatmapSessionRecording ** MediaAnalytics For information: Matomo 4.1.0 on Windows Edge 87 without adblocker

fangyi · January 29, 2024, 10:44am

Hi @heurteph-ei
Thank you for sharing this information. This is the same situation as what we are experiencing.
At first we tried the solution to set enable_userid_overwrites_visitorid = 1. The new setting indeed made idvisitor maintain the same value before and after a user log-in. However, we observed some bizarre behavior, such as incorrect user_id collected after the user logs in. So we went back to the previous =0 setting.
Currently we are trying out the other solution mentioned in the thread: merging visits within a short timeframe that had matching device and screen specs.