Fire the call after your authentication API returns success β not on form submit. Avoid passing the user ID, email, OAuth token, or session cookie. If you offer multiple login methods, encode the method in the event name.
βΈ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.
βΈTrack the event in Flutter
import 'package:respectlytics_flutter/respectlytics_flutter.dart';
enum LoginMethod { email, apple, google }
Future<void> handleLogin(LoginMethod method, dynamic creds) async {
final response = await api.login(creds);
if (!response.ok) {
Respectlytics.track('login_failed');
return;
}
final event = switch (method) {
LoginMethod.email => 'login_email',
LoginMethod.apple => 'login_apple',
LoginMethod.google => 'login_google',
};
Respectlytics.track(event);
}Dart 3 switch expressions handle the method β event_name mapping cleanly.
β¦Privacy & implementation notes
Most analytics SDKs use login as the moment to merge the anonymous pre-login session with the user's prior history. Respectlytics intentionally does not β the session ID rotates every two hours, so cross-session merging isn't a feature anyway. The trade-off: per-user funnel reconstruction lives in your billing system or user-event store, not in product analytics.
Fire after the authentication API returns success β not on submit. Submit-fire inflates login counts with failed credentials and abandoned typing. The few-hundred-millisecond delay is invisible to users and produces a clean metric.
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
| Login event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| user_id attached to all subsequent events | Yes (mandatory) | Yes | Never |
| Email / username as event property | Common | Common | Rejected by API |
| Login method as parameter | Recommended | Recommended | Use distinct event_name |
| Returning user vs new user signal | Per-user | Per-user | Use distinct event_name (login vs signup) |
| Session-grouped login rate by country / platform | Yes | Yes | Yes |
βFrequently asked questions
How do we distinguish returning users from new sign-ups?
Use distinct event names β login and account_created (the signup event). A session that emits login is a returning-user session; one that emits account_created is a new-user session. The two never overlap in the same session by definition.
Can we still tell which login method was used?
Distinct event names per method: login_email, login_google, login_apple. Keep the taxonomy small β under 6 methods is comfortable; past that, bucket the long tail as login_other.
What about failed login attempts?
Fire a separate event: login_failed. Most teams don't need fine-grained failure reasons in product analytics β operational logs catch those. If you do, distinguish the high-level reasons by name (login_failed_credentials, login_failed_locked_account).
Where does the user ID still get used in our system, then?
In your authentication and authorization stack, your user database, your billing system, and your customer-support tools β the systems that legitimately need it. Just not in your product analytics. The hard line between "identifies the user" and "counts what happened" is what makes Respectlytics's posture defensible.