Cid not being enforced although sent

[fulstadev]

This issue is similar to this issue highlighted on github, and still seems to persist: https://github.com/matomo-org/matomo/issues/3776

This issue appears to still persist / exist again. What I did:

• Added the Javascript general tracking snippet to the HTML page; to track page views out of the box.
• When a visitor submits a certain contact form, I use the server-side to:

1. identify the client via the submitted e-mail address (set the e-mail address equal to the user ID, using $tracker->setUserId(submitted_email) in PHP.
2. To be able to enforce the visitor ID according to an attempted retrieval of it from the request received from the client via $tracker->getVisitorId(), I call setTokenAuth('apiKey'), then getVisitorId(), then setVisitorId() with what has been retrieved via getVisitorId().
3. This seems to properly work, as I’ve tested it: getVisitorId() successfully returns the value of the tracking cookie I get from the client that fired the request. Then I var_dump the url that getRequest() internally generates within doTrackEvent(), and the generated URL properly holds the cid parameter equal to the tracking cookie of the client.

• Result, and that’s the problem: in the visitors log dashboard, I see a first log of the page view of a visitor of a random visitor ID, let’s call that one ‘visitor ID X’. After that, an event is tracked (of the contact form submission), with a visitor ID which is however different from the one of the page view, let’s call that ‘visitor ID Y’, although the submitted doTrackEvent() call submitted the ‘visitor ID X’ in the submitted request, as mentioned above. Hence the page view and the subsequent contact form submission are not recognized as actions of the same user, due to the visitor ID not being enforced using the PHP Packages’ setVisitorId() method.

The same happens when you do what’s mentioned above over and over, so I seemingly cannot enforce the visitorId using the PHP Package’s setVisitorId() method, even though I authenticate properly and the getRequest() method, internally called in the doTrackEvent() method generates the proper URL with the correct cid parameter value (visitor ID X).

Of course it is essential for a proper use of the user ID that the system allows to enforce the visitor ID via request from the server to the API, with the received visitor ID from the client-side cookie, such that the entire history of page views / whatever can be reconstructed.

Update: It actually seems that the problem is the simultaneous use of both setUserId() and setVisitorId() before the doTrackEvent() call. This seems to lead to the consequence that only the user ID is considered, and the visitor ID submitted via cid is simply ignored. But when I omit a call to setUserId() and only do setVisitorId() and then doTrackEvent(), the event gets properly stored and shows up in the according Dashboard under the correct visitor ID (the one grabbed from the cookie received from the client-side), but of course without the user ID in that case. This leads to the problem that either way, it is not possible to relate events related to a specific visitor ID to a specific user ID ?!

[heurteph-ei (Philippe)]

Hi @fulstadev
Then it seems related to:

Is visitor data merged into user data after login?

Dear support team, So according to this link: Is there something we’re not getting? How are you supposed to associate an existing visitor ID with a thus newly (upon login) generate user ID?

[fulstadev]

Hi thanks a lot for your quick reaction!

Yes we’ve been scanning through your flagged github issues etc., and we started to feel that many questions / issues are related to this problem of anonymous / unidentified profiles of a created visitor ID not being merged with an identified profile with a new user ID and that same visitor ID.

In one github post (https://github.com/matomo-org/matomo/issues/19927) we’ve thus asked a similar question, and our conclusion, to which we would love an answer, was:

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 ?