Fire the call in the success branch of your post-OAuth handoff — after your backend verifies the provider's token and creates / fetches the user record. Don't pass any of the provider's payload. Distinct event names per provider handle the segmentation.
▸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';
import 'package:google_sign_in/google_sign_in.dart';
Future<void> googleSignIn() async {
final account = await GoogleSignIn().signIn();
final auth = await account?.authentication;
if (auth?.idToken == null) return;
final response = await api.exchangeGoogleToken(auth!.idToken!);
if (response.ok) {
Respectlytics.track('login_google');
}
}Apple via sign_in_with_apple, Facebook via flutter_facebook_auth — same pattern, distinct event_name per provider.
✦Privacy & implementation notes
OAuth tokens, refresh tokens, and provider account IDs are credentials. They belong in your authentication code path with proper access controls — not in your product analytics pipeline. Respectlytics's API rejects them at the boundary. If a teammate adds them by reflex, the integration test fails.
Don't write track('login', { provider: 'google' }) — Respectlytics rejects the parameter. Instead write track('login_google'). Aggregation buckets it automatically; the funnel auto-discovery picks it up; the breakdown is queryable without any custom configuration.
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
| Social login event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Provider account ID stored | Yes | Yes | Never |
| Provider email / name stored | Common | Common | Never |
| OAuth token / refresh token | Yes (server-side) | Yes (server-side) | Never |
| Provider as event parameter | Recommended | Recommended | Use distinct event_name |
| Per-provider login rate | Yes | Yes | Yes (default aggregation) |
❓Frequently asked questions
What event name should we use per provider?
login_google, login_apple, login_facebook, etc. — one per provider you support. Most apps have 2–3 providers; that's a comfortable taxonomy size. The aggregation gives you per-provider login rate without storing provider account IDs.
Should we track the difference between first-time social login and returning?
Yes, with distinct event names: account_created_google (first-time) and login_google (returning). The two answer different product questions — acquisition vs retention — and conflating them blurs both.
What about Sign in with Apple's hide-my-email relay?
Doesn't change anything from Respectlytics's perspective — the event you fire is login_apple regardless of whether the user used a real email or the relay. Apple's hide-my-email is between the user and your auth backend; Respectlytics wasn't going to receive an email anyway.
Should we instrument social login button views?
Useful for funnel diagnosis. login_screen_viewed + login_google gives you the per-button conversion rate. Don't bother with hover / focus events on mobile — they don't carry signal.