▸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
The most common transition pain when adopting Respectlytics is the loss of per-user retention curves. The product question "are users coming back?" can still be answered (via session-cohort rates) but the "who" can't be. Teams that need per-user retention for revenue or compliance reasons typically resolve this by querying their billing / account system instead — where the data legitimately lives.
Session-ID rotation forces a discipline most analytics setups would benefit from anyway: putting per-user metrics in the system that owns the user (your account / billing system) and product engagement in the system that observes events (your analytics). The boundary is a feature.
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
| Session / user identification | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent device-level ID | app_instance_id (UUID, persistent) | distinct_id | device_id | None |
| User-level ID after login | user_id | distinct_id (merged) | user_id | None |
| Survives app restart | Yes | Yes | Yes | No (new session_id) |
| Survives app reinstall | Yes (often, via FCM token) | No | No | No |
| Cross-app linkage on same device | Yes (via IDFA/AAID) | Optional | Yes | No |
| Joinable within one session window | Yes | Yes | Yes | Yes (within 2h) |
❓Frequently asked questions
How is the 2-hour rotation triggered?
Two ways: (1) on every app launch, the SDK generates a fresh session_id; (2) within a foreground session, if no events have been emitted for 120 minutes, the next event emits with a new session_id. Both are automatic — no application code changes the rotation.
What can you compute from a single session_id within its lifetime?
Within one session, you have an ordered list of (event_name, timestamp) pairs that all share the session_id. That's enough for funnel analysis, step-by-step conversion, time-on-task, and feature-sequence derivations. What you can't compute: per-user retention curves, per-user lifetime value, or anything that needs to span sessions for the same user.
How do we measure D1 / D7 retention without a persistent ID?
Session-cohort retention. "Of the sessions that emitted onboarding_complete on day N, what percent of sessions on day N+1 appear at all?" — bucketed by country and platform. The metric is approximately what "D1 retention" measures with cleaner identity, and it's actionable for the same product decisions.
Why 2 hours specifically?
The choice balances analytical utility (a single user's continuous app usage typically fits in a 2-hour foreground session) with privacy minimisation (longer windows allow more cross-event correlation per user). It's a trade-off; 30 minutes was deemed too aggressive (would split natural sessions), 4 hours was considered too lenient. The 2-hour mark is the current value and may be tuned in future major versions with notice.