Fire when the user navigates from cart to the first checkout screen — or, in single-screen checkouts, when they tap the primary CTA to begin entering address or payment. Don't pass the cart total, the address, or the saved payment method.
▸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/material.dart';
import 'package:respectlytics_flutter/respectlytics_flutter.dart';
class CheckoutButton extends StatelessWidget {
final bool isAuthenticated;
final VoidCallback onPressed;
const CheckoutButton({super.key, required this.isAuthenticated, required this.onPressed});
@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: () {
Respectlytics.track(
isAuthenticated ? 'checkout_start_authenticated' : 'checkout_start_guest',
);
onPressed();
},
child: const Text('Checkout'),
);
}
}Most apps see a 30-50% completion-rate gap between guest and authenticated checkout — the distinction is worth instrumenting.
✦Privacy & implementation notes
Shipping address is unambiguous personally identifiable information under every privacy regulation that exists. The Address field is rejected by Respectlytics's API at the boundary — it never reaches storage, and the rejection happens with a 400 that's visible in your integration tests. Mirror the address into your commerce database, where it has a legitimate purpose (shipping the order) and proper access controls.
Apple Pay and Google Pay completion rates routinely outperform card-entry rates by 20–40 percentage points. Distinct event names per payment method let you see this delta directly in your funnel. Foregrounding the wallet option in checkout is one of the highest-leverage UX changes in mobile commerce.
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
| Checkout start event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Cart total / currency | Recommended | Recommended | Rejected by API |
| Item count in cart | Recommended | Recommended | Rejected by API |
| Shipping address as event property | Possible | Possible | Forbidden (PII) |
| Saved payment method type | Recommended | Recommended | Use distinct event_name |
| Cart → checkout-start funnel rate | Per-user | Per-user | Session-grouped |
❓Frequently asked questions
How do we know average cart value at checkout-start without storing total?
Your commerce backend computes that — and it has the authoritative number with refund-aware totals. Respectlytics is for the rate signal; the monetary-value signal lives in commerce. Both are useful; conflating them produces drift.
Can we still differentiate guest checkout from logged-in checkout?
Distinct event names: checkout_start_guest, checkout_start_authenticated. The two flows have different completion rates and different optimization targets, so splitting them is worth it.
What about Apple Pay / Google Pay vs card?
If you instrument the payment-method choice, distinct event names: checkout_payment_apple_pay, checkout_payment_card. Most teams find Apple/Google Pay completion rates 20–40% higher; that delta is a strong case for foregrounding the wallet option.
Should we instrument address-entry abandonment specifically?
Useful in long flows. Fire checkout_shipping_address_entered when the user moves past address. The rate from checkout_start to that event is your address-form drop-off signal; address forms are notorious abandonment surfaces.