SDKs

See which SDKs and versions your data comes from, and change what they do without shipping a release. Covers SDK and version adoption, SDK-to-server traffic, health telemetry, and remote behavior settings for one project.

What the SDKs section is

Every Countly SDK reports on itself. It stamps its own name and version on the sessions it sends, and it reports how it is behaving: the requests it sent, the ones it dropped, and its own health checks. The SDKs section collects all of that for one project, and adds the one thing that runs the other way, the behavior settings your SDKs read back from the server.

It sits under Manage, and it opens on four tabs. Stats answers which SDKs and versions your sessions come from. Requests and Health report SDK-to-server traffic and SDK-side health telemetry. Behavior settings is where you change what the SDKs do.

Everything here is scoped to one project, picked in the scope bar under the tabs. The three reporting tabs also take a date range. Behavior settings does not, because it describes how your SDKs are configured now rather than what they did over a period.

How a setting reaches your SDKs

A behavior setting has a value and a state. The value is what you set. The state is whether your SDKs are being told about it, and every row shows it as a chip.

Not applied means your SDKs never hear about the setting and keep whatever the developer set in code. Applied means the value is being delivered, and it overrides the developer-set behavior in every SDK of the project. Modified means you have changed the value on this page but have not saved it yet.

Saving a changed setting also applies it, so a value you save is a value your SDKs will get. Going the other way is a separate action. Remove from SDKs stops delivering a setting without discarding it, so your SDKs revert to their default or developer-set behavior and the value is kept for you to apply again later.

Nothing reaches a device the moment you save. SDKs re-fetch these settings on their own schedule, so a change lands on their next behavior-settings poll. That schedule is itself a setting, Behavior update interval, and it is 4 hours by default.

Use Cases

See which SDK versions are still in use

You shipped a fix in a new SDK version and you want to know how much of your traffic still comes from the old one.

1. Open the Stats tab and set the date range in the scope bar to the period since the release.
2. Read Top SDK and Top version in the KPI strip. Top SDK carries the share of sessions it accounts for, and Top version is the most used version of that SDK.
3. In Version adoption, pick the SDK you released from the dropdown in the card title. The chart breaks its sessions down by version, day by day.
4. Switch the card to % to read each version as a share of that day, or to # to read the session counts behind it.
5. Read the Versions table below. It lists the versions of the SDK picked in the chart, sorted by sessions, with profiles and new profiles beside them.

Turn off a tracking feature everywhere

You need to stop collecting something across a project now, without waiting for an app release.

1. Open the Behavior settings tab and check that the scope bar names the project you mean.
2. Search for the setting by name. The search also matches a setting's description and its key, so "location" finds Location tracking under Features.
3. Switch it off. The row's chip changes to Modified, and a bar appears at the bottom of the page with the number of settings you have changed.
4. Choose Review & apply. The dialog itemizes every change as its old value and its new one, and lets you revert any of them before you commit.
5. Apply. The row's chip changes to Applied, and the setting is delivered to every SDK of the project from their next poll.

To undo it later, use Remove from SDKs on that row rather than switching it back on. Switching it back on and applying delivers "on" to your SDKs and keeps overriding them. Removing it stops the override, and each SDK returns to what its developer set.

Reduce how much your SDKs send

Your SDKs are making more requests than you need them to, and you want to batch more and retry more gently.

1. Open the Behavior settings tab and jump to the Settings group from the section list on the left.
2. Raise Session update interval, which is 60 seconds by default. It is how often a session update is sent while a session is open.
3. Raise Event queue size, which is 100 events by default. Events are held until the queue fills, so a larger queue means fewer and bigger requests.
4. Jump to the Backoff group and pick the Aggressive preset. It fills the four backoff values so SDKs slow down sooner when the server is answering slowly, and it turns Enable backoff on for you. Editing any of the four values afterward switches the preset to Custom.
5. Choose Review & apply and commit the set in one go.

Check whether your data is arriving

Your numbers look lower than they should, and you need to know whether that is your users or your SDKs.

1. Open the Requests tab and set the date range to cover the drop.
2. Read the KPI strip. Requests received falling while Requests queued rises is the signature of SDKs that are collecting data and cannot deliver it, because a request goes to the queue when the SDK cannot reach the server.
3. Check Requests over time for the day the lines separated, and Request delay for whether what does arrive is arriving late.
4. Read Cancelled by reason for what the SDKs themselves blamed.
5. Move to the Health tab. SDK error logs rising alongside the drop points at the SDK rather than the network, and Issues to address names what it hit.

FAQs

Why has my change not reached the app yet?

SDKs re-fetch behavior settings on their own schedule, so a change lands on their next poll rather than immediately. Behavior update interval sets that schedule, and it is 4 hours by default.

What is the difference between switching a setting off and removing it?

Switching a switch off and applying it delivers "off" to your SDKs, which is still an override. Remove from SDKs stops delivering the setting at all, so each SDK falls back to its default or developer-set behavior. Either way the value you saved is kept, so you can apply it again later.

Does Allow tracking off stop everything?

It stops data gathering. While it is off, your SDKs gather no data. Allow networking is the separate one: it stops networking calls except the one that fetches these settings, and it does not affect gathering.

What does Reset all do?

It returns every changed setting to its default value and applies those defaults to your SDKs. That is not the same as removing settings, which stops delivering them entirely.

Why does the Behavior settings tab have no date range?

It is configuration, not history. It describes what your SDKs are being told to do now, so a period would not mean anything on it.

Related Resources