Thanks for reporting this @SeverinEventfrog, the detail you've provided is very helpful 👍

Since this is a case of documented behavior no longer happening in the current release I'll mark this as a regression.

Hey, im expiriencing the same issue. Could you please prioritize the issue higher, because it really messes up the tracking data.
Maybe it would be a possibility for the matching in the isNewVisit() method to use not only the user-id generated visitor-id, but also the visitor-id, which would be active without user-id?

@mattab This appears to be the same issue as L3-265. Since it's a regression, should it be assigned to the next point release?

@SeverinEventfrog @janinaMi Are you only using the setUserId method when the user logs in, or does this also trigger something else, like setCookieConsentGiven or enableBrowserFeatureDetection?

@sgiehl I'm just using the setUserId method

We also only use setUserId and we only use it after the user logs in. CookieConsent does specifically not trigger it. The moethod is only triggered after the correct userID is known.

We have another user experiencing this issue. Due to how their website is setup it makes it appear as though 60% of their visits are from user that are not logged in, even though their website requires an account to access it. This leads to inaccurate reports for them because the existing visit is not claimed when the User ID is set.

We have another customer who is experiencing this issue. They have a website where users are required to be signed in to view any pages and created a Custom Report to track certain actions. That report contains two specific metrics:
Sum of Unique User IDs
Sum of Unique Visitors

The Sum of Unique Visitors is effectively 2x the Sum of Unique User IDs for any period they select.

A customer has pointed out that because of this bug "we reported the wrong numbers" for more than half a year to senior management.

Another customer reported the bug today:

We found that the visit log will separate into 2 logs after the customer login instead of updating the id in the same visit log / profile.

Hi @Starker3 and @atom-box, we had a similar issue with one of our clients.
We were able to recover this unexpected behavior by accessing the visitorLog via the API and merging visits within a short timeframe that had matching device and screen specs.

While this approach didn't alter the Matomo statistics, it served as an effective workaround given that we where already generating custom (excel) reports for our clients.

The specs we used to merge visits where:

• operatingSystem
• deviceModel
• browser
• language.

A simple merger plugin for Matomo might be a handy solution for the future, since realizing this misconfiguration is quite frustrating.

We have tried to reproduce this issue to understand exactly the scope of the problem.
It might be a combination of different JS tracker settings such as cookie consent or browser features detection etc.

There were changes in Matomo 5 (PR 20096) related to the tracking requests that might address this so it would be good if the customers could confirm this is still an issue on Matomo 5.

Additionally, we aren't seeing if this worked previously, hence removing the regression label.

We acknowledge that there might be various issues around UserID tracking, but this will require a larger piece of work to fix holistically.

Let us know when you bump into any related issues so we can look into it better.

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/two-sessions-instead-of-one-visitor-id-and-user-id/45230/9

I can only reproduce this with a Brave browser. Unable to reproduce on Cloud or on-premise with Chrome and FF...

The Brave shield was disabled during my test.
My Brave _pk_id cookie still had the original visitor ID.

EDIT: The above test was using v4.15. I was unable to reproduce this with Matomo 5 RC1.

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/problem-with-changed-idvisitor-and-idvisit-after-login/53946/4

Testing again, I can reproduce this in Matomo 4 but not with Matomo 5.

However it is important to note that not calling setUserId on every page will create a different visitor in Matomo.
For example, if setUserId is called prior to any action on the page, all actions will be tracked to that user. If the user ID is not set on any page, or any action is tracked prior to setting the user ID, a new visit and visitor to be created in Matomo and those actions will be recorded to the new visit. My guess is that this can happen at times and in the future this behaviour may be mistaken for the Matomo 4 bug.

I see comments here about users having 2x the unique visitors as user IDs. This can happen after the user logs out and is tracked without setting a User ID. This Custom Report shows the visitor with a User ID of 333Z who was then assigned a visitor ID of 6747e813356d497f after tracking an action without calling setUserId is counted as two unique visitors...

It is also important to note that if an ecommerce solution does not also set the same user ID when reporting an ecommerce transaction a new visit will be created. This seems to be quite possible with solutions such as the Matomo WooCommerce plugin which report transactions from the backend and do not have access to the User ID.

Another customer has this issue with Matomo 5, tracking via an SDK. I think they have found a reason why this can occur. If a visitor returns to the site and is not recognised by Matomo, they are assigned a new Visitor ID. If an existing User ID is then assigned to this visitor, their visit is split and all subsequent actions are tracked as a new visit. I have reproduced this with Matomo Cloud (5.0.0).

Here the visit was tracked on Firefox but after assigning an existing User ID (101), the visit was split and the browser is reported as the previous known browser (Brave) even though the actual browser for the visit was still Firefox...

We're facing the same issue in Matomo 4.16.0 and also after updating to 5.0.1, same problem. As stated almost one and a half year ago according to this issue, the docs still claim:

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."

Will this issue be fixed anytime soon? Or is the only way to solve this by setting the enable_userid_overwrites_visitorid = 0 config? If so, we wonder why the default configs in Matomo changed from upon 3 (if what we read is correct) from 0 being the default to 1 being the default. Do we have to worry about any kind of negative implications when setting it to 0 to get rid of this problem ?

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/is-visitor-data-merged-into-user-data-after-login/42511/3

The same problem for me, more or less. In my use case the user doesn't even need to log in.

As soon as the user puts something in the cart, a new visitor profile is created and an "Abandoned Cart" event appears in the Matomo real-time view for this new visitor profile. The visit is split in 2 visitor profiles. :(

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/cid-not-being-enforced-although-sent/54953/3

We're struggling with the exact same problem. In our visits log you can see

1. I already have a registered user from previous visits
2. I visit the page logged out, a new visit is created
3. I go through the login process and return to our authentication page
4. A new visit is created the moment User ID is added, with a new visit ID and Visitor ID connected to the previously registered user
   

@KarlGe
What version of Matomo did you encounter this behavior? If you're not yet using Matomo 5 I would recommend updating and see if the issue still happens.

@KarlGe What version of Matomo did you encounter this behavior? If you're not yet using Matomo 5 I would recommend updating and see if the issue still happens.

Thanks for the suggestion, from the other replies it seemed like that wouldn't fix it but I will give it a try.

Another Cloud customer is experiencing this issue. The have the same symptoms as I described above...

If a visitor returns to the site and is not recognised by Matomo, they are assigned a new Visitor ID. If an existing User ID is then assigned to this visitor, their visit is split and all subsequent actions are tracked as a new visit.

Just to confirm @Starker3
We've updated to Matomo 5 (5.0.2) and tried this again

Here you can see me first visiting the page, and it gets assigned to one unique visitor

Then when I call setUserId, and trackPageView it will connect that to the previous unique visitor that had that userId, without assigning the first part of the visit to that user, hence creating two visits for this one visit

This looks to be the exact same thing as 9joshua is describing
We've had to disable user IDs temporarily, since this is happening

I have the same issue. When I log in, a new visit started and did not merge with the current one.
UserID is set by _paq.push(['setUserId', userData.id]);

it is a SPA, so the user id is set before triggering pageview after login.

Matomo version: 5.0.3