How is Tracker Debugger aggregating the data?

I am sending signup events from our app server.
The requests contain a User ID for each signup.

Since it is a test environment, some tests might present very similar ua, IP, …
But the user ID would always be different.

For some reason, in the Tracker Debugger, I am sending two signup events with different User ID, but they always show under one single User ID.

If I search for the User ID not showing in the debugger, it will still show me that some events are there, which is rather confusing:

In this screenshot, you can see that I am searching for user ID 13400_1, but the data appearing are defined for the User ID: 13401_1

Just tested it and it get’s overridden if both requests are from same workstation. IMO it’s a bug to fix on our end. I’ll coordinate that. For the time being, you have to make sure that whenever user id changes, you have to change also user agent or ip address.


In a normal context, IP/UA should be different most of the time, but sometimes, colleagues creating two different accounts might have similar IP/UA.

Is it a Tracker Debugger bug? In the sense, are the raw data correct even if the Debugger does not display them correctly?

Our dev team has to check if it’s a global or tracker debugger bug.

You’re right that this happens really rarely, I’d say 99% of cases have only one user_id per working station. On the other hand, It ruins the entire use case of tracking different users from one household, so we have to fix that.


Did you make any progress on this bug?
I have some more data to show if they are interested.

The problem is not in the tracker debugger but should be global, as far as I see.

Because, later, in the reports, the data will also show wrongly.

Here are 3 examples of payload sent to the API for goals


and the result in the reports:

It would seem logical to me that User ID is the absolute identifier above UA and IP.

Also, there was something unclear to me.

I am getting the Visitor ID on the website and send it to the API via the _id parameters as explained in the API doc: Tracking HTTP API — Piwik PRO Analytics Suite 16.39 documentation

But in the reports, the ID will appear as a Cookie ID and not as the visitor ID, which is coming from an unknown place (I am guessing your internal logic with IP and UA)

Hi. We’re currently working on improvements and a bit more control when it comes to the used identifiers when user id is set. I don’t have the ETA yet.

When it comes to the second question, the visitor ID is not always the same thing as cookie ID. If user ID is set, visitor ID is derived from its value.

What I try to achieve is the following:

On our website, users are never “identified” with the user_id.
We simply use the visitor_id created by Piwik.

Now, when they signup to our app, a few events are occurring on the server that I want to track. The JS Piwik library is not used on our app server and we don’t plan to use it.

So, by sending these API calls, where the user_id is defined and so is the _id, I am hoping to stitch everything together, the website navigation/source/medium, and the APP events.

Is that correct.

Yes, it makes sense. Is your backend app deployed on the same domain? Are those request sent after visitor’s interaction with the backend or it’s a totally separated task? I’m asking, because you can also read the cookie id server-side. It all depends on your current architecture.

Or, approaching this topic from different angle - is there any identifier that is common both for those anonymous visitor and your backend when sending a request with information about signup?

BTW. if you don’t want to merge events coming from same device/IP, you can simply disable Session ID during development.