Custom Cohorts

Cohorts in devgrowthlab are designed to track stable categories of users. They work best when used for data that changes occasionally, not constantly. Examples include subscription tiers, app versions, platforms, advertisement campaigns, or experiment groups. These types of values provide a reliable way to measure adoption, compare outcomes, and generate recommendations automatically.

When your app starts or when a user’s cohort value changes, such as upgrading from a free plan to a subscription, you can include this information in the event payload. The structure looks like this:

{
  "lastToken": "string or null",
  "cohorts": {
    "Example Cohort": "Example Value"
  }
}

Before sending data, make sure that “Example Cohort” is already created in your dashboard:

Go to Settings → Cohorts in your devgrowthlab dashboard. You’ll see existing cohort categories and can add new ones.

The “Example Value” can be any string that describes a version, platform, campaign, or experiment group. devgrowthlab automatically selects the most relevant and popular values for deeper analysis.

Note

Don’t include personal information as cohort values. Cohorts should not contain data that could identify a user, such as email addresses, phone numbers, IPs, or device IDs. Only use descriptive values like version names, campaign identifiers, or experiment groups. See our Data Compliance guide for more details.

Once your cohort data is being sent, retention and install performance are tracked for each group. The dashboard will highlight where one group is outperforming the others. For instance, a particular subscription plan might result in higher retention, or one advertising campaign might attract more users than another.

When something changes significantly, such as a new app version reducing engagement or an experiment group falling behind, devgrowthlab will automatically detect it during the daily analysis and send you an alert. Recommendations are also generated to help you understand what’s happening and decide what to do next.

In this way, both installs and retention are continuously monitored and compared across your custom cohorts. Whether you’re testing a new onboarding flow, experimenting with pricing, or tracking the impact of an app update, the results are always visible inside the dashboard.

Cohorts for features that change very frequently might not be the best choice for this type of analysis. If you have many fast-moving features, it can be better to group them by version, release, or experiment name rather than by feature flag. This helps keep your cohort data stable and your insights accurate.

Experiments

Experiments can be set up in your own code by assigning users to groups, or you can use an external service to do the same like firebase A/B remote config. devgrowthlab doesn’t randomize users internally. devgrowthlab can still measure outcomes from experiments setup in other frameworks, make sure to send the experiment group information as a cohort to devgrowthlab.

Measuring ad campaign performance

Many SDKs from third-parties will allow you to get ad campaign information. For example:

• Adjust, get the campaign information
• Play store referrer, get the referrer information

This information, and information from other SDKs can be sent to devgrowthlab directly in the cohort values.

Tracking app version changes

You can get the version name directly from code and send it to devgrowthlab, for Android this looks like so:

val request = IngestRequest(
    lastToken,
    mapOf(
        "App Version" to BuildConfig.VERSION_NAME
    )
)