Automatic Behavior

Beyond the events you explicitly log, the SDK handles a number of standard analytics concerns on its own. Understanding what is automatic is important: it tells you what you do not need to build yourself, and what data will appear in the B2Metric project without any additional code.

9.1 Lifecycle Events

Three events are emitted automatically over the lifetime of an installation:

• first_open — sent exactly once, the first time the SDK is initialized on a given installation. Use this in funnels to measure activation.
• session_start — sent at the start of every new session. A session begins when the app comes to the foreground after being inactive longer than sessionTimeoutMinutes, or on first launch.
• session_end — sent when the app is backgrounded or the session times out. Carries the session duration as a property.

These events do not need to be requested; they appear in every B2Metric account by default and use the same property schema across all platforms.

9.2 Device Metadata

Every event is automatically enriched with a fixed set of device and app properties. You do not need to attach any of these manually:

Property	Example value	Source
app_name	MyApp	From the app bundle metadata
app_package_name	com.myapp	Bundle identifier (iOS) / package name (Android)
app_version	1.2.0	From the app bundle metadata
device_hardware	arm64-v8a	CPU architecture of the device
device_model	Pixel 7	Device marketing or hardware name
device_id	a1b2c3d4-...	Per-install UUID generated by the SDK; persists across launches
os_version	14	OS version number
platform	ios / android	Resolved at runtime
screen_resolution	1080x2400	Physical screen dimensions in pixels
language	en	Primary language from the system locale
country_code	US	Country from the system locale
timezone	America/New_York	IANA timezone identifier

9.3 Reliability Features

The SDK is designed to keep working under poor network conditions and to never lose events because of a transient failure:

• Offline queuing. Events are written to disk as soon as they are logged. If the device is offline, they remain in the persistent queue and are sent automatically when connectivity is restored.
• Network awareness. The SDK observes the device's connectivity state and triggers a flush as soon as the network comes back, without waiting for the next scheduled interval.
• Retries with backoff. If a request fails with a retryable error (server 5xx, timeout, network drop), the SDK retries with exponential backoff up to maxRetries times before giving up on the batch.
• Queue overflow protection. If event production outpaces delivery for an extended period — say, several days fully offline — the queue is capped at maxQueueSize. When the cap is reached, the oldest events are evicted so the queue cannot grow without bound.