Place the call in the same code path that creates the account on your backend — after success, not before. Avoid passing the new user's email, ID, or signup channel as metadata; if you need a channel breakdown, emit a distinct event name instead.
▸ 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 SignUpMethod { email, apple, google }
Future<void> handleSignUp(SignUpMethod method, dynamic creds) async {
final response = await api.signUp(creds);
if (response.ok) {
final event = switch (method) {
SignUpMethod.email => 'account_created_email',
SignUpMethod.apple => 'account_created_apple',
SignUpMethod.google => 'account_created_google',
};
Respectlytics.track(event);
}
}Dart 3 switch expressions read cleanly here. The new user ID returned by `api.signUp` is not passed to `track` — it lives only in your account-management code path.
✦ Privacy & implementation notes
Resist the urge to send `user_id` even "just in case". Once a user_id is in your analytics pipeline, every analyst will eventually use it for something — and you'll have built a per-user dataset by accident. Respectlytics's API rejects user IDs at the boundary: there's no path to accidentally re-introduce them later.
Distinct event names per signup method scale up to roughly 8–12 categories before they become unwieldy. Past that, bucket the long tail as `account_created_other`. Most apps have 3 (email + Google + Apple) — well below the threshold.
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
| Sign-up event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| New user_id stored | Yes (mandatory) | Yes (default) | Never |
| Email / phone as event property | Recommended | Common | Rejected by API |
| Signup method as event property | Recommended (login_method) | Common | Use distinct event_name |
| Acquisition source attribution | utm_* parameters | UTM tracking | Distinct event_name per source |
| Cross-device user identification | Yes (App Instance ID) | Yes (Identity Merging) | Out of scope (sessions, not users) |
| Resulting privacy posture | Per-user, identifiable | Per-user, identifiable | Session-scoped, no PII |
❓ Frequently asked questions
How do we measure activation without joining sign-up to first action?
By session. A session that emits both `account_created` and at least one of your "meaningful action" event names is an activated session. Compute the ratio across your session set — that's activation rate. You never need to join to a user table to get this number.
What about email vs Apple vs Google sign-up channels?
Use distinct event names: `account_created_email`, `account_created_apple`, `account_created_google`. The aggregation buckets them automatically. Embedding the method as a custom parameter is rejected by the API.
Can we still compute conversion from a marketing campaign?
Yes — use distinct event names per campaign source. If you have many campaigns, that taxonomy can balloon — keep it to your top 5–10 sources and bucket the rest as `account_created_other`. The trade-off: you give up long-tail per-campaign granularity in exchange for never storing UTM parameters or referrers.
What if our backend creates the account but the user abandons before the next screen — does the sign-up still get tracked?
Only if your call to `track` runs before the abandonment. Respectlytics's event queue is RAM-only — events not flushed before app force-quit are lost by design. For a signal as critical as sign-up, instrument the event right after the API call returns, not on the next screen.