@brototyp opened this Issue on June 22nd 2018 Member

After over a year working on the Matomo iOS SDK I now finally found some time to write down my experience of the Matomo backend (BTW: Is "backend" the real naming convention when talking about the server component?) in the aspect of tracking mobile applications, focusing on iOS applications.

I am aware of #7893 and #7131 but felt like writing a separate issue, to not disturb any discussions there.

I will write down my experience in form of my wishes.

Ease of use / Getting started

These might be some obvious and maybe even simple ones.

  • Creating a new trackable app in the backend should not be named "Create a new Website".
  • Remove the aspects of a trackable app that doesn't make sense in context of an app, such as URLs, Excluded Browser Agents and similar.
  • Add an app identifier or identifiers, such as org.matomo.client, instead of the URLs.
  • Optimize the "Tracking-Code" page in the context of a mobile app.

Tracking of an app

There are some tings that are especially important to track in the context of an app that are a bit harder than it should be.

  • Add App Version (human readable and/or automatic generated) as a default dimension (or similar) in the UI and API.
  • Set the URL parameter of a view/page as optional throughout the system (API and backend).

Nice to haves

These are just thoughts I had in general, where I am not totally sure if they are necessary at all or if they should be part of Matomo.

  • Add an Exception event. Possibly just a counter in the context of the current user. Possibly adding a severity. Possibly adding the last few lines of the log.
  • Adding performance measurement. Either "manual" gathering of performance data or automatic "Page/view X took Y milliseconds to generate" or "Action A took B milliseconds to finish" or "Networkrequest to N took M milliseconds to return".

I am open for discussions and additions on this subject, especially in the context of Android, other "trackables" in general and the possibility of these things in the context of the existing backend. Possibly some of these things are already possible but hard to discover or not streamlined enough.

Powered by GitHub Issue Mirror