Wire this into the same code path that handles trial-to-paid renewal — typically a webhook from your billing vendor, surfaced to the client through your own backend, OR a client-side StoreKit transaction listener. Avoid passing the transaction ID, the renewal amount, or the new plan — those live in your billing system.
▸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:purchases_flutter/purchases_flutter.dart'; // RevenueCat
Purchases.addCustomerInfoUpdateListener((info) {
final active = info.entitlements.active['premium'];
if (active != null &&
!(active.isActive == false) &&
active.willRenew == true) {
// Detected the moment the entitlement leaves the intro period.
Respectlytics.track('trial_conversion');
}
});For server-side firing, send the event from your RevenueCat webhook handler via the Respectlytics REST API.
✦Privacy & implementation notes
If both your client and your backend listen to billing events, ensure exactly one of them fires the analytics event — usually the backend, because it sees the authoritative webhook even when the user has closed the app. Double-firing produces conversion rates above 100%, which always looks more dramatic than the bug actually is.
Treat trial conversion as two separate metrics with separate systems of record: the product engagement signal (Respectlytics, session-scoped) and the revenue signal (your billing system, per-user). Asking analytics to do both ends with neither being trustworthy.
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
| Trial conversion event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Per-user revenue attribution | Yes | Yes | Out of scope (use billing system) |
| Transaction ID stored | Yes | Yes | Rejected by API |
| Renewal amount / currency stored | Yes | Yes | Rejected by API |
| Plan ID stored | Yes | Yes | Use distinct event_name per plan |
| Useful for product funnel? | Yes | Yes | Yes (session-grouped) |
| Useful for revenue forecasting? | Yes | Yes | No (use billing system) |
❓Frequently asked questions
Where should this event fire — client or server?
If your client gets a verifiable in-app receipt (StoreKit, Billing Library), the client is fine. If you rely on RevenueCat / Stripe webhooks for the source of truth, fire from your backend after the webhook resolves — using your server-side Respectlytics SDK or REST call. Don't fire on both — you'll double-count.
What if the user converts via a desktop web flow, not in-app?
Fire from your backend when the conversion completes — tagged with the platform field set to whatever channel produced it (platform: web). The session ID for backend-fired events is generated server-side and rotates the same way.
How do we handle different plan tiers (basic, pro, team)?
Distinct event names per tier: trial_conversion_basic, trial_conversion_pro, etc. Keep tier count modest; bucket long tails as _other.
What about double-counting if the user converts and then refunds within 24h?
Don't try to retract the analytics event. Your billing system has the refund data. The product question is "how many trials converted at all?" — that's what trial_conversion measures. Refund analysis happens against the billing system, not the analytics pipeline.