Hey,

Problem on matomo_tracker 1.4.1 and above.

If I call await MatomoTracker.instance.initialize( siteId: 123, url: 'someurl', );

I always get

It works fine on 1.4.0.

Maybe you could look into it.

First: thanks so much for creating/supporting this flutter package. That was one of the reasons I chose Matomo, because there is a current flutter SDK for it.

Now, I'm using Firebase and I'm running into two problems:

1. Firebase has a uuid which I'd like to put into visitorId, but Firebase's uuid has 26 characters (hex) whereas visitorId in matomo is required to be 16 characters. I guess I could just take the 16 last characters of Firebase and hope that they are unique. Or is there any better alternative?
2. Upon the first launch of the app, a user has no Firebase user yet, only after the required registration. What's the best way to handle that? Can I call MatomoTracker.instance.initialize first without visitorId and then after registration I call it again? Or should I use MatomoTracker.instance.visitor = Visitor(id: _visitorId, userId: _visitorId)?

I noticed that on an iPhone, no events were being tracked because the User-Agent HTTP header is being set to an invalid value.

This problem won't affect every device but is potentially not limited to iPhones.

In the specific case, the iPhone running ios 12 set its device name to Firstname Lastname’s iPhone as a default configuration. It is therefore likely that many/most user's of iPhones have a device name in this format. I have no newer hardware available to verify if Apple have changed this behaviour in recent years but either way, the name may well persist across iOS upgrades to even the most up to date phones.

Note that the apostrophe is not a standard ASCII apostrophe and thus it is not valid to be used in a HTTP header so Dart throws an error rather than submit the tracking request.

I have fixed the issue through two different approaches.

1. Stop setting the User-Agent HTTP Header to the device-specific value. Although I have only confirmed this works with existing users known to Matomo, I would expect that it works fine for new users too, since we already supply the ua parameter.
2. Remove the iOS device name and equivalents for other operating systems from the User agent string.

Either fix on its own would resolve this issue but I think the two combined are required to help protect against other unexpected device variables crashing the tracking process and to protect library users and end users from an unexpected leak of personal information.

Hello team,

Thank you to develop this tracker for Matomo. 👍 I noticed that the timer keeps running when the app is in the background. So I added development to handle pause and resume timer if needed and I added a lock mechanism to prevent the queue from being processed concurrently if the processing is longer than the timer periodicity.

Example of use

void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.paused) {
      MatomoTracker.instance.pause(); 
    } else if (state == AppLifecycleState.resumed){
      MatomoTracker.instance.resume();
    }
  }

I let you see if this development is interesting for the project.

Sébastien

Hello, thanks for building this great plugin. I wanted to ask if it is possible to track how long the user spent in the app or on a particular screen? Are there plans to implement this?

Thanks again.

These changes add a sendBatch(List<MatomoEvent>) function to the MatomoDispatcher, which sends the entire queue using only one HTTP POST request, as specified in the Matomo API documentation.

Additionally I have fixed the error mentioned in #33, by saving the currentScreenId in the MatomoEvent itself. Previously only the latests screen id was used in all batched requests, which resulted in Matomo assuming that all batched tracking events were performed on the same screen.

Fixes: #9

I found the problem for #9. when sending event's the event category is a mandatory field. Updated the code to reflect this. These are breaking changes

I have running the Matomo Backend via Docker https://github.com/matomo-org/docker the nginx example, Matomo Version 4.9.1

example call: http://localhost:8080/matomo.php?idsite=1&rec=1&url=https%3A%2F%2Fcom.example.example&_id=cf0cd7af39194e79&rand=822786072&apiv=1&_idvc=12&_viewts=1653736918&_idts=1653721097&res=1440x3064&h=11&m=22&s=1&cookie=1&ua=Android+12+%28SDK+32%29%2C+Google+Pixel+6+Pro&lang=de_DE&uid=cf0cd7af39194e79&pv_id=zhO56F&e_a=Click&e_n=IncrementCounter

The API Call are received in the Backend but I cant see the Increment Counter event

Hello! We make a request to matomo using this SDK. The data has been sent successfully, but they do not come to matomo. Can you tell what we could have done wrong and what data you need to send to check it?

We using matomo version 4.10.1 and sdk version 1.7.0

Describe the bug Events that get sent in the same _dequeue() loop get picked up by our Matomo instance incorrectly. This means that for example 3 quick consecutive screen views get tracked as the first view x 3 by Matomo.

To Reproduce Steps to reproduce the behavior:

1. Send multiple events in rapid succession
2. Verify in Matomo console

Additional context For now, we have resorted to a slightly hacky workaround of calling dispatchEvents() after each tracking call. We have tried to remove the Queue from matomo.dart altogether and it seems to work. Maybe someone could give us some context on why the Queue was implemented in the first place, because we would have a PR ready with the Queue removed that worked great in our testing.

What

• Adds support for tracking dimensions (Matomo documentation on Custom Dimensions: https://matomo.org/faq/reporting-tools/create-track-and-manage-custom-dimensions/)
• As mentioned in https://github.com/Floating-Dartists/matomo-tracker/issues/16, example use cases would be tracking of App Version or tracking of App Content Language.

Implementation considerations

• Basically the dimensions are key value pairs, so in the proposed implementation just adding them to the query params.
• There are two ways to add the dimensions, either when an event is tracked (and dimensions is an optional argument) via the updated trackEvent, or via a new function trackDimensions

Documentation

• Info on setting up custom dimensions on Matomo can be found here: https://matomo.org/faq/reporting-tools/create-track-and-manage-custom-dimensions/ and on the dimensions arguments in the API here: https://developer.matomo.org/api-reference/tracking-api
• Updated also the README file with usage examples