Matomo: Allow administrators to define a custom site ID

[Jon-IB]

We plan to host many sites in Piwik. Each of these sites is already identified by a global site ID that we use elsewhere in our business. Thus it would be handy to use the same ID in the Piwik tracking code and API calls, so we don't have to define a mapping of our global site ID to the Piwik site ID.

This also seems to follow good design practices IMHO. Piwik could encapsulate its own internal site IDs, and not require other systems to be aware of these IDs, if the administrator desires.

Here's one way to solve this:

1. When a new site is created, the API and the admin UI would have an optional field to allow the user to define a custom site ID. This would default to the auto-incremented "idsite" value.
   
   
   
   • This custom site ID field would be a text field, which would allow administrators to namespace the ID. For example, an administrator could define a site ID of "Canada:12345", or whatever they want, rather than just "12345".
   
   
2. This value would be stored in a new field in the piwik_site table. This field would be used to match tracking requests to the correct website. Yes, this would require a match on a text field vs. a numerical field, but this shouldn't be too bad with an index.
3. If the administrator doesn't provide a custom site ID, then Piwik will default to use the auto-incremented "idsite" value in this new field. Thus if an admin doesn't bother to define a custom site ID, then everything continues to operate as before.
4. All existing functionality would continue to link to the internal "idsite" value. The custom site ID field is only for matching incoming tracking requests.
5. The API might require substantial changes to support a custom site ID. Or maybe not. Perhaps the API could stay as-is, except that the definition of the "idSite" parameter would be changed to this new custom site ID. This seems ideal to me, since the whole point of this request is to isolate Piwik's internal site ID within the Piwik application. And nothing would change for existing API users. But it is somewhat confusing, since "idSite" has historically referred to the internal Piwik ID, and that's the actual name of the db field.
6. Migrating existing data to support this feature is simple -- just copy the existing "idsite" values to the new field in the piwik_site table.

Does this sound like a useful feature? It seems helpful to have the flexibility to define our own custom site ID. And it doesn't seem too impactful to the code base, db schema, or existing use cases. But I'd like to hear what the core team thinks.

Also, would it make more sense to implement this as a plugin? I'd be concerned about performance. But maybe it's not so bad to do a lookup or join to the piwik_site table from a plugin. I haven't looked closely at the Piwik plugin API yet.

[mattab]

Thanks for the suggestion. At this stage this is not scheduled for 2.x. But it's definitely a reasonable and quite useful feature request!

[chmielot]

I am meeting the same requirements, +1

[GieltjE]

This would indeed be very helpfull

[magnabytes]

This would be a welcomed addition +1

[mattab]

This could maybe be done in a Third party plugin, see @tsteur explanation in https://github.com/piwik/piwik/issues/9975#issuecomment-203092388

[joubertredrat]

@mattab @tsteur I think that this can be developed like this https://github.com/joubertredrat/Piwik-ProtectTrackID

But, is possible to plugin have your tables on database or manipulate other database? If is possible, then, is create link between table with idSite and plugin table to provide this custom id.

[mattab]

@joubertredrat Great to see you released the plugin on the marketplace! if you have any further question or issue, please consider creating a new issue (or if not so important, asking in https://forum.piwik.org/c/plugins-platform )

[mfilotto]

It would be very usefull to keep our ui app agnostic from environment.
We have a piwik per environment so for the same app, the project id is different on each environment.
It's very unconveninient