Analytics and errors

Analytics: two systems, deliberately

System	Role	Wiring
Firebase Analytics	Product analytics	Standard SDK
Matomo (matomo_tracker)	Self-hosted analytics	Initialized at startup with Marktag; a MarktagNavigatorObserver is attached to MaterialApp.router, so page views track automatically

When adding a screen or flow, check whether the Matomo observer’s automatic page-view covers it before instrumenting manually.

Errors: two sinks, deliberately

Errors go to both:

• Firebase Crashlytics — the mobile-default sink.
• Sentry (sentry_flutter + sentry_dio) — initialized in main.dart, with sentry_dio capturing API failures with request context.

Sentry is configured entirely through --dart-define flags (see Running the app): SENTRY_DSN (empty = off), SENTRY_ENVIRONMENT, SENTRY_RELEASE, SENTRY_TRACES_SAMPLE_RATE. Sentry never runs in debug builds — if you need to test error reporting, build a profile/release variant against staging.

Rules of thumb

• Don’t catch-and-swallow: an error no sink sees is an error nobody will fix.
• Attach breadcrumb context (title id, playback path, download package) where it saves a future debugging session — the deep dives name the log lines worth grepping for.
• debugPrint output is development-only; production diagnostics come from Crashlytics/Sentry, not console logs.