Skip to content

General

Charging by monthly active device

The primary value proposition of Capture is that by default all telemetry processing happens local to the device and nothing is sent to bitdrift. As such, charging by telemetry volume a) does not accurately describe the value Capture provides and b) is at odds with bitdrift's goal of allowing local emission of as much data as possible and only remote capturing the data that is highly likely to be used. We feel that by default monthly active devices (MAD) more accurately reflects the value that Capture provides. To ease adoption, MAD limits are soft (see below) and plan allowances are generous.

Monthly active device definition

At app installation time, a UUID is generated within the SDK. The UUID is sent to the bitdrift control plane during stream negotiation. A connection on behalf of a given UUID counts as a monthly active device (MAD). Note that app reinstalls / cache clears will count as a new MAD as a new UUID will be generated. Additionally, the UUID is solely used for anonymized device bucketing and targeting. It is never tied to any underlying PII/telemetry data.

Sessions versus Captures

Events emitted by the SDK are grouped within sessions that are defined using session identifiers. Session identifiers are rotated using one of the SDK session strategies and can be used to retrieve events from any given captured session.

A session is considered to have a Capture in it (be captured) if there was a deployed Workflow that instructed the SDK to upload collected logs during the lifetime of the session. A single session can have multiple captures associated with it.

Exceeding plan limits

Exceeding plan limits will never have a detrimental impact on the app. The following actions are currently taken for each limit:

  • Monthly active devices: this is a soft limit. Clients will continue to connect and process configurations normally. We will contact you to discuss options for continued usage at an elevated MAD level.
  • Concurrently deployed workflows: this is a hard limit enforced in the UI.
  • Daily captures per workflow: this is a hard limit enforced by the system. The SaaS coordinates with clients to not exceed this limit without any interruption at the app level.
  • Captured sessions: this is a soft limit. We will retain sessions older than 30 days, but they will become unavailable to view. Sessions older than 180 days will be permanently deleted.
  • Data look back: this is a soft limit. We will retain data for charts for 30 days, after that time that data will no longer be available.

Limit increases

If the free tier limits are too small, please contact us at info@bitdrift.io to discuss options for larger scale usage.

Support / Ask questions

See support.

Capture on server

Not yet, but coming soon. Contact us at info@bitdrift.io to learn more about the server roadmap and how bitdrift can help you vastly reduce your logging/metrics observability bills while at the same time increasing overall value.

Capture on Internet of Things (IoT) / System on Chip (SoC)

While we don't currently officially support IoT/SoC, if you have an interesting Android/Linux IoT/SoC use case which would benefit from Capture we would love to hear from you at info@bitdrift.io.

Capture embedded in other mobile SDKs

Having developed a complex mobile SDK, we understand how difficult it can be to debug SDKs in the wild! Embedding Capture in other SDKs provides a unique opportunity to send no telemetry off device unless explicitly instructed which is typically a requirement for an SDK. Please contact us at info@bitdrift.io if you would like to explore this use case.