Attachment: Tracking Debug Output
piwik.html

Attachment: Visitor Log: Only one visit (instead of several), wrong visitor id
crushed.png

Using Piwik 1.10.1 . API key is admin user of idsite(2).

Oh, sorry: auth_token should be token_auth, of course. Attached a new version of the output, as the problem remains:

Matching visitors with: visitorId=1234567890123456 OR configId=6da98b12e33904b4<br />
The visitor is known (idvisitor = bb0ccf88648b5ee2,
...

In case of a forced (vs. indicated via _id) visitorId it should only match by visitorId.

Attachment: 2nd test output
test.html

I've sent a pull request on github: #35 - which fixed the issue for me.

Thanks for the report, very nice find. I agree with your proposal, that when a user has called $tracker->setVisitorId( ) and has authenticated with token_auth, then the visitor ID should be enforced.

In 12c3fbe: Fixes #3776, Fixes #3787

Adding integration test to test this code.

I also updated tracking api reference to explain "cid" parameter.

cid (requires token_auth to be set) defines the visitor ID for this request. You must set this value to exactly a 16 character hexadecimal string (containing only characters 01234567890abcdefABCDEF). When specified, the Visitor ID will be enforced. This means that if there is no recent visit with this visitor ID, a new one will be created. If a visit is found in the last 30 minutes with your specified Visitor Id, then the new action will be recorded to this existing visit.

Tracking API updated

see also #6109

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.

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/1

@fulstadev As this issue is closed, but your feedback is valued, could you please re-create a new issue with your information?