Hi @Jarek ,
My name is Yves, and I am Elena’s colleague.
What you describe is exactly what we did. So here is a typical case and maybe you can highlight what might be wrong or if there is a limitation in how Piwik behaves.
Here is the full technical implementation.
We have a commercial domain: https://beebole.com and an app domain https://beebole-apps.com
The Piwik JS is installed on the commercial domain and on the Signup/Signin pages of the app domain.
All events on the commercial website are tracked using the Piwik JS, then when someone decides to sign up for a trial, the Visitor ID is retrieved using this method:
And then sent with a URL decoration:
To make sure the visitor ID is correctly passed through the two domains.
On the Signup page, once the signup form is completed, the Visitor ID is retrieved from the Piwik cookie and sent to our back end to identify the Visitor ID with the newly created User ID.
We store then the signup event with both IDs and that event is then sent as a backend event to Piwik via the API.
It usually works well, with the limitation of 3rd party cookies, …
Here is an example:
The source and medium is there, the back-end event appears correctly, …
Now, the trial lasts for usually 30 days.
If an account becomes a customer, it triggers another event, with is then also stored in an event BQ table along with the User ID, but also with the first instance of the Visitor ID we have for that user. (Typically the visitor ID that was there when the person signed up.
Here is an example of that table where you can see the two events, with the same user ID and visitor ID:
The become_customer event is then also sent via the API to Piwik.
But if I look for the example above, here is what I see for the signup and for the subscribed events:
The Signup attribution report will correctly identify the source/medium.
The subscribed will just show as direct/direct.
Despite the visitor ID being sent for the subscribed event and being the same as the signup event.
So, is there something to change?
Yves