Fire after the commerce backend confirms order success — typically in the navigation-to-thank-you-screen handler. Don't pass the order ID, total, or line items. If you fire from your backend (more reliable for delayed-confirmation flows), use the same 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';
Future<void> placeOrder(String cartId) async {
final result = await orderApi.placeOrder(cartId);
if (result.ok) {
Respectlytics.track('checkout_complete');
} else {
Respectlytics.track('checkout_failed');
}
}Fire from the success branch of your order-placement API call — never on submit-button tap.
✦Privacy & implementation notes
If you accept payments via Apple Pay, Google Pay, or 3D-Secure flows, the final order confirmation arrives server-side via webhook — sometimes seconds after the user has closed the app. Client-side checkout_complete will miss those. Server-side firing from your commerce-backend webhook handler produces a clean count.
Resist the urge to put order total into product analytics, even "for cohort analysis." Once revenue is in your analytics pipeline, every analyst will use it for something — and the lack of refund-aware mutation, currency conversion, and tax handling will silently corrupt every report. Keep revenue in 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 complete event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Order ID stored | Yes | Yes | Rejected by API |
| Order total / line items | Yes | Yes | Rejected by API |
| Per-user revenue attribution | Yes | Yes | Use commerce backend |
| Conversion-rate by country / platform | Per-user | Per-user | Session-grouped |
| Refund / chargeback handling | Per-event mutation | Per-event mutation | Out of scope (use commerce backend) |
❓Frequently asked questions
How do we measure conversion rate without per-user attribution?
Per-session. The rate of sessions emitting checkout_complete divided by sessions emitting add_to_cart (or checkout_start) is the funnel rate. Country-bucketed and platform-bucketed gives you the segments. Per-user lifetime metrics live in your commerce backend, where they belong.
Where do we fire — client or server?
Server-side from the commerce backend's order-confirmation webhook is the most reliable path — client-side fires miss orders confirmed after the user closed the app. Use the Respectlytics REST API from your backend handler. Pick one; firing from both produces double counts.
Can we still compute average order value?
From your commerce backend, yes — that's where order totals live with authoritative timestamps and refund-aware totals. Respectlytics is the completion-rate signal; AOV is a commerce-backend signal.
What about repeat-buyer rate?
Out of scope for Respectlytics — it's an inherently per-user metric. Your commerce backend or customer-data platform has the customer history. Respectlytics tells you whether checkout is working; your CDP tells you who buys repeatedly.