Skip to main content

A/B testing

Measure the impact of the community on your app by giving access to only part of your audience.

Before you begin​

  • Complete the Quickstart: the SDK is initialized.
  • Choose who runs the test: Octopus (an Octopus-run A/B test), or your own A/B testing tool.

How it works​

An A/B test splits your audience into two cohorts:

  • Test group: a part of your users (for example 30%) with full access to the community.
  • Control group: the other users (for example 70%), without access.

Octopus Analytics then compares the two cohorts on app session volume and retention.

There are two ways to run the test:

Octopus-run A/B testYour own A/B test
Who assigns the cohortOctopusYour app
What the control group seesA screen saying the community is not available yet for themWhatever your app decides: usually no community entry point
What your app doesReads the user's access (step 1), and optionally overrides it (step 2)Reports the user's cohort to Octopus (step 3)
Effect on the SDKAccess is enforced by the SDKAnalytics only: the SDK behaves the same for both cohorts

1. Read whether the user has access​

Android availableiOS availableFlutter availableReact Native availableUnity ≥ 1.12.6

With an Octopus-run test, read whether the current user is in the test group, for example to show or hide your community entry point. The value is updated as soon as the user's cohort changes.

  • OctopusSDK.hasAccessToCommunity: Flow<Boolean> — emits the current access, then every change.
OctopusSDK.hasAccessToCommunity.collect { hasAccessToCommunity ->
// Show or hide your community entry point
}

2. Override the user's access​

Android availableiOS availableFlutter availableReact Native availableUnity ≥ 1.12.6

Override the cohort Octopus assigned to the current user: to check what each cohort sees during your tests, or to grant or remove access for given users. The override takes precedence over the Octopus-run test and over the cohort you report in step 3. Once it is applied, the access of step 1 emits the new value.

  • hasAccess: Boolean — true to grant access, false to remove it.
  • Returns OctopusResult<Unit, OverrideCommunityAccessError>; the function is suspend.
scope.launch {
when (val result = OctopusSDK.overrideCommunityAccess(hasAccess = canAccessCommunity)) {
is OctopusResult.Success -> {
// Override applied: hasAccessToCommunity emits the new value
}
is OctopusResult.Failure -> {
// No network, user not connected, override refused…
}
}
}

3. Report your own A/B test cohort​

When your app runs its own A/B test, tell the SDK whether the current user is in the community-enabled group or in the control group, so that Octopus Analytics can compare them. This only feeds analytics: it does not change what the SDK shows.

The value is reset at each SDK launch: report it every time, as soon as possible after the SDK is initialized.

  • hasAccess: Boolean? — true for the community-enabled group, false for the control group.
OctopusSDK.trackAccessToCommunity(hasAccess = canAccessCommunity)

See it in the samples​

Behavior and limits​

  • An override (step 2) takes precedence over both the Octopus-run test and the cohort you report (step 3).
  • The reported cohort is reset at each SDK launch: report it again after every initialization.
  • The reported cohort is used for analytics only. To actually hide the community from the control group of your own test, hide your entry point.

Next steps​