Fire on the framework's "screen became visible" callback: viewDidAppear on iOS, onResume on Android, useFocusEffect on RN, RouteObserver.didPush on Flutter. Don't pass the screen title, route path, or query parameters as metadata.
▸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:flutter/widgets.dart';
import 'package:respectlytics_flutter/respectlytics_flutter.dart';
class TrackedScreen extends StatefulWidget {
final String eventName;
final Widget child;
const TrackedScreen({super.key, required this.eventName, required this.child});
@override
State<TrackedScreen> createState() => _TrackedScreenState();
}
class _TrackedScreenState extends State<TrackedScreen> {
@override
void initState() {
super.initState();
Respectlytics.track(widget.eventName);
}
@override
Widget build(BuildContext context) => widget.child;
}For Navigator-based routing with RouteObserver, override didPush and didPopNext — both should fire the screen event so back-navigation re-entries get counted.
✦Privacy & implementation notes
A common failure mode: 200 distinct screen names accumulate over time as engineers add screens without coordinating. Maintain the screen taxonomy as an explicit document, not a String literal scattered through code. Respectlytics's funnel auto-discovery surfaces patterns across all event names — a clean taxonomy makes it useful; a noisy one makes it noise.
Screen views are typically 70%+ of total event volume in apps that auto-track. Most of that volume carries no decision-grade signal. Manually instrumenting 10–20 screens you actually care about is more useful than 200 auto-tracked ones, and keeps your analytics pipeline interpretable.
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
| Screen view event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Screen name as parameter | Recommended (`screen_name`) | Recommended | Use distinct event_name |
| Screen class as parameter | Recommended | N/A | Use distinct event_name |
| Time-on-screen | Per-user | Per-user | Session-scoped derivation |
| Per-route parameter (`product_id`) | Recommended | Recommended | Forbidden (use bucketed event_name) |
| Screen sequence within session | Per-user | Per-user | Session-scoped |
❓Frequently asked questions
How do we handle screens with parameters like `/products/{id}`?
Bucket. Fire screen_product_detail for all product detail screens, regardless of which product. The product ID is content-routing data, not analytics data — your support and product-mgmt tools have it. If you absolutely need a top-N breakdown (your 10 most-viewed products), encode those into distinct event names by name; bucket the long tail.
Should we track every screen, or just the major ones?
Just the major ones. "Auto-tracking every screen" sounds comprehensive but produces a flood of events that drown the high-signal funnel events. Pick 10–20 product-meaningful screens; instrument those by hand.
How do we measure time-on-screen?
Compute it server-side from consecutive timestamped events in the same session. The interval between screen_view_a and screen_view_b is the time spent on a. Don't store duration as an event property — Respectlytics rejects parameters.
What about modals and sheets?
Track them as their own events with distinct names: modal_settings_opened. Don't conflate modal-presentation with screen-view; they answer different product questions and obey different lifecycle rules.