Skip to main content

Event Batching & Flushing

To optimize battery life and network usage, B2Metric queues events and sends them in batches rather than making a network request for every single event.

How Event Batching Works​

The SDK maintains a local queue and automatically sends events based on these triggers:

  1. Batch size reached — When the queue hits batchSize events (default: 20)
  2. Time interval elapsed — Every flushInterval seconds (default: 30)
  3. App backgrounded — Before app goes to background
  4. App foregrounded — When app comes to foreground
  5. SDK started — On initialization (sends any previously stored events)
logEvent("button_clicked")  // Event 1 - queued
logEvent("screen_viewed")   // Event 2 - queued
...
logEvent("product_viewed")  // Event 20 - hits batchSize → All 20 sent immediately

logEvent("add_to_cart")     // Event 21 - new queue starts
... 29 seconds pass ...
→ Event 21 sent when flushInterval (30s) expires

Configure Batching Behavior​

B2MetricAnalytics.shared.start(
  apiKey: "YOUR_API_KEY",
  batchSize: 10,      // Send after 10 events
  flushInterval: 60   // Send every 60 seconds
)

User Identification - Device ID​

B2Metric automatically generates a unique Device ID for each app installation.

How it works:

  • Device ID is automatically generated on first SDK initialization
  • Format: UUID (Universally Unique Identifier)
  • The SDK uses this as the primary identifier for tracking events
  • No action required — it's handled automatically

Persistence:

  • Stored locally on the device
  • Persists across app restarts
  • Removed only when the app is uninstalled
  • Each app installation gets a new Device ID

Offline Support​

The SDK intelligently handles offline scenarios.

When offline:

  • Events are stored locally in persistent storage (b2m_events.json)
  • No network requests are attempted
  • Queue continues to grow with new events

When connection is restored:

  • SDK detects network availability
  • All queued events are sent automatically
  • No events are lost
User loses internet connection
logEvent("product_viewed")  // Stored locally
logEvent("add_to_cart")     // Stored locally
logEvent("button_clicked")  // Stored locally

... user browses offline for 10 minutes ...

User regains internet connection
→ SDK automatically detects connection
→ All stored events sent to server

Storage behavior:

  • Events persist across app restarts
  • Stored in App Support Directory
  • Events sent in chronological order

Retry Behavior​

Failed network requests are automatically retried using an exponential backoff algorithm:

  • Failed requests are queued for retry
  • Retry intervals increase exponentially (backoff)
  • Maximum retry attempts configurable (maxAttempts)
  • After max retries, events remain in local storage
  • Will retry again on next app session or network recovery
Server temporarily unavailable (500 error)
logEvent("purchase_completed")
→ Attempt 1: Failed (retry after 1s)
→ Attempt 2: Failed (retry after 2s)
→ Attempt 3: Failed (retry after 4s)
→ Stored locally, will retry later

Next flush triggers (30s later or next batch)
→ Attempt 4: Success — event delivered