Fire the call when the user submits a search β Enter key, Search button, suggestion tap. Don't pass the query string, the result count, or any normalized form of the query.
βΈ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<List<SearchResult>> submitSearch(String query) async {
Respectlytics.track('search_query');
final results = await api.search(query);
if (results.isEmpty) {
Respectlytics.track('search_zero_results');
}
return results;
}Wire to the search-form's onSubmitted callback, not onChanged (per-keystroke is noise).
β¦Privacy & implementation notes
Search queries are some of the most sensitive content in your app β users type personal questions, medical concerns, addresses, names. The European Court of Justice has ruled IP + search-query combinations are personal data in multiple cases. Respectlytics's API rejects free-text payloads at the boundary; the query never gets that far.
Your search backend stores queries for ranking and quality work β that's its job, with proper retention and access controls. Mirroring those queries into analytics gives you a second store with weaker controls and no clear purpose. Respectlytics's role is the product-engagement layer above search, not the search-content layer itself.
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
| Search event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Query string stored | Common (free-text param) | Common | Forbidden (PII) |
| Result count as parameter | Recommended | Recommended | Out of scope |
| Per-user search history | Yes | Yes | Out of scope |
| Search β result-clicked funnel | Per-user | Per-user | Session-scoped |
| Zero-result rate | Per-user from query property | Per-user | Use distinct event_name |
βFrequently asked questions
How do we know what users search for if we don't store queries?
Your search backend (Algolia, Elastic, your own) already has the query data with appropriate retention and access controls. That's where query analytics lives. Respectlytics is for the product surface β "is search getting used and is it converting?" β not the content of queries.
What about zero-result queries?
Distinct event name: search_zero_results. Fire it instead of (or in addition to) search_query when the result set is empty. The rate of zero-result over total search is a UX-quality signal you can read directly.
Can we still measure search-driven conversion?
Yes, per-session. A session with search_query followed by product_viewed (or whatever your conversion event is) is a converting session. The funnel auto-discovery surfaces this without manual config.
What about voice search vs typed search?
Distinct event names: search_query_typed, search_query_voice. Their completion rates and result-click patterns differ enough to be worth splitting.