▸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 5-field rejection at the API boundary is the single most useful feature for keeping privacy posture consistent over time. Most teams accidentally drift toward more PII as engineers reflexively add fields to events for debugging. Respectlytics's API gives you a 400 in CI on the first commit that adds an extra field — the bad pattern fails fast.
The 5 stored fields map cleanly to the analytical dimensions most product teams actually use: WHAT happened (event_name), WHEN (timestamp), WHERE (platform + country), and the session-grouping key (session_id). What's missing is per-user identity — and that's the design point.
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
| Event payload | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Custom event properties allowed | Up to 25 params/event | Up to 250 properties | Up to ~100 | Zero (rejected) |
| User properties | Up to 25 | Unlimited (people profiles) | Unlimited | N/A |
| Stored per event | Variable | Variable | Variable | Exactly 5 fields |
| API enforcement of schema | Lenient | Lenient | Lenient | Strict (rejects extras) |
| Per-user state computable | Yes | Yes | Yes | No (use account system) |
❓Frequently asked questions
How do we segment events without custom properties?
By using distinct event_names. Instead of track('purchase', { product: 'gold_pack' }), fire track('purchase_gold_pack'). The aggregation buckets event_names automatically; no manual configuration. Keep your taxonomy under ~50 distinct names per matrix axis to stay navigable.
What about timestamps with sub-second precision?
The timestamp field is millisecond-precision UTC. That's enough for session-grouping and aggregate analysis. For higher-precision use cases (e.g., performance monitoring), use a different tool — APM is not Respectlytics's job.
Can we attach internal user IDs even if they're never returned to the user?
No. The API rejects extra fields outright with a 400. The rejection is the feature: there's no version of "send the user_id to analytics for internal use" that doesn't eventually leak through dashboards, exports, support tools, etc. The 5-field boundary keeps that surface zero.
What if we need a sixth field for legitimate reasons?
The 5-field constraint is architectural and won't change. But the constraint pushes you to a different solution: (a) encode the variant in the event_name, (b) keep per-user state in your own systems and don't mirror it to analytics, or (c) use a different tool for the use case. Most product teams find (a) or (b) sufficient.