Skip to content
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

UserID no longer overwrites VisitorId #14360

Merged
merged 7 commits into from Nov 8, 2019

Conversation

MichaelRoosz
Copy link
Contributor

With these changes, the visitor ID no longer gets overwritten by the user ID.
This completely logically separates the user ID and the visitor ID feature.
It also solves problems when using the 3rd party cookie (global visitor id across sites) and user ID at the same time.

These are basically the same changes as in #13620 but without the option to turn the new behavior off, as requested by Matthieu.

He wrote to me in November:

Interesting... we discussed it a while ago and I think the conclusion was that we should unlink these two in core by default. But there were maybe some problems with this which I can't remember (but would be likely noted somewhere on Github). So maybe you could open the PR to do this in core rather than a setting, and we could start to review

@tsteur
Copy link
Member

tsteur commented Apr 22, 2019

Looks good to me and makes sense. Not sure if anything else needs updated @mattab .

For sure we should also change the behaviour in https://github.com/matomo-org/matomo-php-tracker/blob/1.4.1/PiwikTracker.php#L1241-L1245

@mattab
Copy link
Member

mattab commented Apr 23, 2019

Looks good to me also, thank you for the PR @MichaelHeerklotz 👍

Feedback:

  • +1 to update the php matomo tracker in https://github.com/matomo-org/matomo-php-tracker/blob/1.4.1/PiwikTracker.php#L1241-L1245 - would be good to include the tracker changes in this PR so we can see the overall build results (our tests use the php matomo tracker to track the test data)
  • the User ID user guide will need to be updated to reflect how User id works. 1) this part: "How requests with a User ID are tracked > Same user from multiple device use case: [....]". After the change, each simultaneous visit on separate devices would each create a new visit (but with the same user id)? 2) maybe there would be other things to add/update in the guide use cases

@mattab mattab added this to the 3.11.0 milestone Apr 23, 2019
@MichaelRoosz
Copy link
Contributor Author

Thank you.
I think this comment can then also be removed from the queued tracking plugin settings "Number of queue workers" description:

DO NOT USE more than 1 worker if you make use the UserId feature when tracking see #7691

@mattab
Copy link
Member

mattab commented May 28, 2019

HI @MichaelHeerklotz - thanks again for the PR. Would you be able to update the php matomo tracker in https://github.com/matomo-org/matomo-php-tracker/blob/1.4.1/PiwikTracker.php#L1241-L1245 to include the tracker changes in this PR so we can see the overall build results (our tests use the php matomo tracker to track the test data)?

@MichaelRoosz
Copy link
Contributor Author

MichaelRoosz commented May 28, 2019

Hello @mattab , I have created PRs for matomo-php-tracker and piwik-dotnet-tracker. I also checked all the other trackers (matomo-sdk-ios, matomo-sdk-android, piwik-java-tracker, etc) and they do not seem to need any changes.

@peachp
Copy link

peachp commented Jul 30, 2019

looking forward to this improvement. Currently I "abuse" custom dimension to record the user ID, to keep tracking the visit under same Visitor ID and then will have to access raw SQL data to get what I need.

@tsteur
Copy link
Member

tsteur commented Oct 2, 2019

@MichaelHeerklotz I was just going to give it a test but seeing there's a merge conflict. Can you have a look? I will then see if tests pass and give it also an actual test and look at all the related PRs

@MichaelRoosz
Copy link
Contributor Author

@tsteur It should be good to merge now

@tsteur
Copy link
Member

tsteur commented Oct 4, 2019

@MichaelHeerklotz a few tests are now failing see eg https://travis-ci.org/matomo-org/matomo/jobs/593032816#L823-L883. Some unrelated to your change. We're working on getting the 3.x-dev green so that all tests pass. From what I see the test changes look fine.

We can wait until the 3.x-dev branch passes again or if you want you can already upload some expected files now. We can otherwise also fix the tests after merging.

The change itself looks good though 👍

@tsteur
Copy link
Member

tsteur commented Oct 15, 2019

@MichaelHeerklotz let me know what you want to do here. We're planning to release 3.12 soonish.

@diosmosis
Copy link
Member

@tsteur I made a couple changes to a test/fixture to get them to pass (the UserIdAndVisitorIdTest one). Could you take a look and see if they look ok to you?

* Returns true if the last user_id did not change.
* @return bool
*/
protected function lastUserIdWasSetAndDoesMatch(VisitProperties $visitProperties, Request $request)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@diosmosis @mattab @MichaelHeerklotz I'm now actually wondering... on a regular website when tracking userId, and then the userId changes, would we create a new visit keeping the same visitorId maybe? Just a random thought maybe.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm seeing this is what it actually implements. Be just good to have this behaviour confirmed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good, I totally see we want this behaviour. Was not reading the code right initially.

@tsteur
Copy link
Member

tsteur commented Nov 6, 2019

@diosmosis looks all good 👍 There are a few more test failures in https://travis-ci.org/matomo-org/matomo/jobs/608100023?utm_medium=notification&utm_source=github_status that look expected and can be updated too. The UI build didn't finish so couldn't look at them. Might need to update some screenshots. We will then need to

@diosmosis
Copy link
Member

Seems harder to fix the remaining test failures in a PR so will do so after merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Review PRs that need a code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants