▸Install the Flutter SDK
# pubspec.yaml
dependencies:
flutter:
sdk: flutter
respectlytics_flutter: ^3.0.0Pure Dart — no platform channels for analytics. Same code on every platform Flutter compiles to (iOS, Android, web, macOS, Windows, Linux). On web, events are sent via the REST API; mobile platforms use the same path.
▸Initialize Respectlytics in Flutter
import 'package:flutter/material.dart';
import 'package:respectlytics_flutter/respectlytics_flutter.dart';
Future<void> main() async {
WidgetsFlutterBinding.ensureInitialized();
await Respectlytics.configure(appKey: '<YOUR_APP_KEY>');
runApp(const MyApp());
}Initialize in main() after WidgetsFlutterBinding.ensureInitialized() and before runApp(). The future completes immediately on configuration; events queued before completion are flushed once the network is available.
✦Privacy & implementation notes
Probabilistic install-attribution SDKs (AppsFlyer, Branch, Adjust) build fingerprints from model + OS + screen + locale + IP and match them across the install boundary to attribute the install to a specific ad click. Apple's SKAdNetwork and Google's Privacy Sandbox are the non-fingerprinting alternatives. Respectlytics is event analytics, not install attribution — but if you remove the install-attribution SDK from your app, the fingerprint surface goes with it.
Audit indicator: search your build for Locale.current, UIDevice.current, Build.MODEL, screen.width, Intl.DateTimeFormat().resolvedOptions().timeZone — these are the canonical fingerprint signals that SDKs reach for. If they appear in your shipped code only as part of your own UI logic (not as analytics-emission), you're clean.
The Flutter SDK is pure Dart. No MethodChannel, no platform-specific iOS or Android plugin code. The same code runs on every platform Flutter supports — including web and desktop targets. This eliminates one common audit surface ("what's the Android implementation doing?").
Always initialize after WidgetsFlutterBinding.ensureInitialized() and before runApp(). If you skip the binding step, the configure call will throw on platforms that need a binding for asynchronous I/O. The SDK documentation example uses this pattern by default.
⇋How this compares to other analytics SDKs
| Fingerprint signals | Firebase Analytics | AppsFlyer | Branch | Respectlytics |
|---|---|---|---|---|
| Model + OS version | Yes | Yes | Yes | No |
| Screen size + density | Yes | Yes | Yes | No |
| Locale + timezone | Yes | Yes | Yes | No |
| Installed font list | No | Sometimes | Sometimes | No |
| IP + User-Agent combination | Yes | Yes | Yes | IP transient, UA standard |
| Probabilistic install attribution | No | Yes | Yes | No |
❓Frequently asked questions
Does the SDK report ANY device characteristics?
Two: the platform field (iOS / Android / RN / Flutter — already in the 5-field schema) and the inferred country code from IP lookup. That's it. Model, OS version, screen size, locale, timezone are not collected.
What about User-Agent — that has model + OS in it on Android.
The HTTP request to our API includes a standard User-Agent that identifies the SDK and platform but does NOT include device model, OS build number, or other fingerprinting signals. We use a fixed UA string per SDK version + platform combination.
How do we still see crash data by device model, then?
From your crash reporter (Sentry, Crashlytics, Bugsnag) — those tools legitimately need device model for crash dedup. Respectlytics is event analytics, not crash analytics; the two have different data needs and should be wired separately.
What about A/B-test variant assignment using fingerprint stability?
Don't. Variant assignment via fingerprinting is a re-identification anti-pattern. Use a randomised assignment within your client, encode the variant in the event_name (paywall_purchase_a, paywall_purchase_b), and compute conversion rates from session-grouped event counts. No fingerprint needed.