Aus öffentlichen Paketdaten erstellte Orientierung.
Das matomo_tracker-Paket bietet eine vollständig plattformübergreifende Lösung zur Integration von Matomo-Analysen in Flutter-Anwendungen. Es umschließt die Matomo-Tracking-API und ermöglicht Entwicklern die Erfassung von Nutzerverhalten über Android, iOS, Web, macOS, Windows und Linux. Mit einfachen Initialisierungs- und Ereignisverfolgungsmethoden unterstützt es benutzerdefinierte Ereignisse, Seitenaufrufe und Benutzersitzungsverfolgung. Das Paket ist für eine nahtlose Integration mit bestehenden Matomo-Installationen konzipiert und bietet zuverlässige Daten-Erfassung ohne plattformspezifischen Code. Es ist ideal für Apps, die detaillierte Analysen erfordern, während gleichzeitig datenschutzorientierte Tracking-Praktiken gewahrt werden.
Anwendungsfälle
Verfolgung von Benutzerinteraktionen in mobilen und Web-Anwendungen
Überwachung der App-Leistung über Seitenaufrufe
Benutzerverhalten mit benutzerdefinierten Ereignissen analysieren
Integration mit selbst gehosteten Matomo-Servern
Analytik über mehrere Plattformen sammeln
Hauptmerkmale
Plattformübergreifende Kompatibilität
Unterstützung für alle wichtigen OS-Plattformen
Einfache Ereignis- und Seitenansichtserfassung
Integration mit selbst gehosteten Matomo-Instanzen
Datenschutzbewusste Datenverarbeitung
Geeignet für
Flutter-Entwickler, die Analyse benötigen
Apps, die selbst gehostetes Matomo verwenden
Projekte, die eine Multiplattformverfolgung erfordern
Teams, die sich auf Nutzerverhalten einstellen
Entwickler, die Drittanbieter-Analyse-Dienste vermeiden
Hinweise
Benötigt einen laufenden Matomo-Server
Erforderliche korrekte Konfiguration der Tracking-ID
Kann die Einhaltung von Datenschutzvorschriften erfordern
Beschränkt auf Matomo-spezifische Funktionen
Abhängig von der Netzwerkverfügbarkeit für die Datenübertragung
Original-README
Originaler README-Schnappschuss aus dem verknüpften Quell-Repository. Aktuelle Inhalte finden Sie im Repository.
If your application uses authentication and you wish to have your visitors including their specific identity to Matomo, you can use the Visitor property userId with any unique identifier from your back-end, by calling the setVisitorUserId() method. Here's an example on how to do it with Firebase:
If you want to offer a way for the user to opt out of analytics, you can use the setOptOut() call.
MatomoTracker.instance.setOptOut(optout: true);
Using Dimensions
If you want to track Visit or Action dimensions you can either use the trackDimensions (if
it's a Visit level dimension) or provide data in the optional dimensions param of trackEvent
(if it's an Action level dimension):
When using cookieless tracking, the user_id won't be sent or saved locally.
Dispatching
Actions logged are not send to Matomo immediately, but are queued for a configurable duration (defaulting to 10 seconds) before beeing send in batch. A user could terminate your app while there are still undispatched actions in the queue, which by default would be lost. The queue can be configured to be persistent so that such actions would then be send on the next app launch. See the DispatchSettings class for more configuration options.
Session class and its related properties firstVisit, lastVisit and visitCount have been removed as they were not used since Matomo 4.0.0.
LocalStorage methods getFirstVisit, setFirstVisit, getVisitCount and setVisitCount have been removed accordingly.
siteId is now a String instead of an int
v4.0.0
trackScreen was renamed to trackPageView and trackScreenWithName to trackPageViewWithName.
screenId and widgetId were renamed to pvId.
userId was renamed to uid.
traceName and widgetName were renamed to actionName.
traceTitle was renamed to eventName.
forcedId property has been removed as it was never used. You should rely on the user ID instead.
An object of type EventInfo has been added, it has the following properties: category, action, name and value, use it instead of passing the event name, action and value as separate parameters.
For TraceableClientMixin and TraceableWidget to work you will have to add the matomoObserver to your MaterialApp or WidgetsApp:
trackPageView positional parameter context is now a named parameter
trackGoal positional parameter goalId is now a named parameter: id
trackDimensions positional parameter dimensions is now a named parameter
trackCartUpdate positional parameters trackingOrderItems, subTotal, taxAmount, shippingCost and discountAmount are now named parameters
trackOrder positional parameters orderId (now id), trackingOrderItems, revenue (also became a double), subTotal, taxAmount, shippingCost and discountAmount are now named parameters
trackOutlink positional parameter link is now a named required parameter (also changed the type to String)
v3.0.0
Now the initialize() method takes a LocalStorage? localStorage instead of a SharedPreferences? prefs as its parameter to override the persistent data implementation.
By default it will use an implementation of shared_preferences with the class SharedPrefsStorage, but you can provide your own implementation of LocalStorage to use a different package.