📄️ Overview
The B2Metric Flutter SDK is the official client library for sending analytics data from Flutter applications to the B2Metric platform. It is designed to be a complete, drop-in solution: it captures user interactions as events, manages user sessions automatically, registers push notification tokens, and handles the entire delivery pipeline — batching, retry logic, offline persistence — without requiring any additional setup.
📄️ Installation
Installing the SDK is a two-step process: add the package as a dependency in your Flutter project, then import it in your Dart source code. The SDK is published on pub.dev under the name b2metric_sdk, so the standard Flutter tooling handles the download, version resolution, and platform-specific setup automatically. No manual changes to Gradle, CocoaPods, or platform-level configuration files are required.
📄️ Quick Start
This section shows the absolute minimum code required to get the SDK running and to send your first event to the B2Metric platform. Use it as a smoke test after installation — once you see an event arriving in your dashboard, you know the integration is working and you can start instrumenting the rest of your application.
📄️ Configuration
The SDK is configured through a single immutable B2MetricConfig object passed to init(). All configuration is applied once at initialization and cannot be changed afterwards without restarting the SDK. This design keeps the runtime behavior predictable: once the SDK is running, every event you log is processed with the same batching, retry, and session rules.
📄️ Event Tracking
Events are the fundamental unit of data in the B2Metric platform. An event represents a single thing that happened in your application at a specific point in time — a user opening a screen, tapping a button, completing a purchase, or anything else worth measuring. Every event has a name (what happened) and may carry properties (additional context about what happened).
📄️ Push Notifications
Push notifications are a powerful way to re-engage users, but they only produce useful analytics if every leg of the journey is tracked: the token must be registered against the right user, deliveries must be linked back to campaigns, and opens must be attributed to whichever notification triggered them. The SDK provides two methods that, together, cover the full push lifecycle.
📄️ Lifecycle Management
The SDK manages most of its own lifecycle automatically: it starts a background worker on init, batches events, sends them periodically, persists anything that can't be delivered, and resumes when the device comes back online. For the vast majority of integrations you do not need to think about lifecycle at all. The two methods documented in this section exist for the cases where you do — when a critical event must be sent immediately, or when you want to tear the SDK down cleanly at sign-out.
📄️ Complete Integration Example
The example below ties everything from the previous sections into a single, realistic integration. It shows what a typical e-commerce application looks like once the SDK is wired in end-to-end: initialization with full configuration, push token registration, an add-to-cart event with item-level data, and a purchase event followed by an immediate flush so the critical revenue data leaves the device right away. You can use this snippet as a reference when integrating the SDK in your own application — replace the screen and handler stubs with your real code, and the rest stays valid.
📄️ API Reference
This section is a complete listing of every public method and enum exposed by the SDK. Each previous section in this guide covers when and how to use these methods in practice; this one is the quick-lookup reference you can come back to after you've integrated the SDK and just need to remember a signature.
📄️ Troubleshooting
This section covers the most common questions and issues teams encounter while integrating the SDK. If your problem isn't listed here, the first diagnostic step is almost always the same: set logLevel to LogLevel.debug, reproduce the issue, and read the console output. The SDK logs every meaningful internal decision at debug level, which is usually enough to pinpoint what's going wrong.