## Charging by monthly active application

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 application (MAA) more accurately reflects the
value that Capture provides. To ease adoption, MAA limits are soft (see below) and plan allowances
are generous.

## Monthly active application definition

Monthly Active Application refers to an application with the bitdrift SDK installed that has
connected at least once that month to the bitdrift control plane. Each unique application and
device would count as one, regardless of connecting once vs many times that month. Inactive
applications would not be charged.

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 application (MAA). Multiple connections for the same UUID only count as 1 MAA. Note that app
reinstalls / cache clears will count as a new MAA as a new UUID will be generated. Additionally,
the UUID is solely used for anonymized device bucketing and connection 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](../sdk/features/session-management.md) 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](../product/workflows/overview.md) 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 applications: 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
MAA 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](https://bitdrift.io/pricing) are too small, please contact
us at [info@bitdrift.io](mailto:info@bitdrift.io) to discuss options for larger scale usage.

## Support / Ask questions

See [support](../support/contact.md).

## Capture on server

Not yet, but coming soon. Contact us at [info@bitdrift.io](mailto: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](mailto: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](mailto:info@bitdrift.io) if you would like to explore this use case.