@sgiehl opened this Issue on July 4th 2014 Member

Currently Piwik is only able to detect browsers.
Instead of detecting only browsers we should open up piwik to client based detection.
Clients can be browsers, as well as media players, mobile apps, personal information managers (like mail clients), feed readers and so on.
The DeviceDetector used by Piwik is already able to detect such clients.
As it is impossible to define short codes for all those possible clients, we might need to move away from only saving short codes (like it is actually done for browsers)

With client based detection there will be more reports possible within Piwik. So it would be nice to see which client types mostly visits a website and os on.

@ThaDafinser commented on July 29th 2014 Contributor

@sgiehl i would go further...save all client $_SERVER vars serialized in one field inside piwik_log_visit.

  • at an upgrade you can extract them, if other table fields need to be field
  • you can update the short codes or other things at an upgrade


  • possible overflow (TEXT can be too small....i had it one time as LARGETEXT....)
  • needs a lot of space
@mattab commented on April 7th 2015 Member

Hi @sgiehl - great idea of a new report for Piwik.

Do you maybe have some idea on approx estimate for this issue?

@sgiehl commented on April 7th 2015 Member

I think that would take a few days for implementation. We need to built a switch between the different client types and therefor adjust the table structure as we need additional information. Currently all client types other than browser will be reported as "unknown" browser, which will then be excluded from the browser reports. Maybe I can provide a detailed list of todos as soon as I have some time for that.

I would love to see that in the near future!

@bigretromike commented on May 17th 2017

is near feature now 👍 ?

@bigretromike commented on May 7th 2019

Hello, is there way to help with this ? Maybe sort all ShortCodes for all type of devices ?

@sgiehl commented on May 7th 2019 Member

that might require various database changes to be able to store other client types than browsers. Guess such a change won't be doable before the next major release.

@bigretromike commented on May 7th 2019

Why not store big table of shortcodes for every type? Or add column with single integer as a type and depend who detects useragent that type and short code would be saved, while everything before would be default browser int ID example 1. That would make the issue simpler. I crossfingers that this wont take next 5years, sadly I never touched php framework big project like this so Im unable to hop and coded that but I do have some knowlegth so the proposal is not out of the world

On May 7, 2019 3:13:36 PM GMT+02:00, Stefan Giehl <notifications@github.com> wrote:

that might require various database changes to be able to store other
client types than browsers. Guess such a change won't be doable before
the next major release.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@bigretromike commented on July 25th 2019

Looking thru gh I found: https://github.com/matomo-org/matomo/pull/13929 looks like you started moving from codes to names.
So could I assume the future is closer than it was year ago ?:-)

@mattab commented on August 7th 2019 Member

Would it work to simply use different shortcodes for the new clients we want to detect?

@bigretromike commented on August 7th 2019

@mattab I does exactly that! But I understand that the issue was that Matomo store '2 char value' and that would go out of stock if used that way for every client.
But as I remember moving from shortcodes to names was one of requirements to add a custom client detection without needing to edit manually detection library to detect other kinds of devices that are not browsers but yet are able to access pages and are excludes from browser raport (ex. media players)

@sgiehl commented on August 7th 2019 Member

exactly. device detector is for example able to detect names of mobile apps. that can't be be combined with short codes in any way

@bigretromike commented on August 7th 2019

that why you need currently overwrite detect library to include those in browser and exclude them from ex. mobile apps - then you are able to measure real traffic and how does it come to you.
And I have fingers cross that we be able to add our 'browsers' or change some settings to include those 'apps/applications/programs' that access our content thru web

Powered by GitHub Issue Mirror