Skip to main content

I’m wondering what is the correct approach of forcing a variant and tracking an exposure event for it.

Let’s say I added a feature flag with two variants - “control” (default one) and “new-onboarding”.

On the app’s launch we call fetch with a small timeout in order not to block users for a long time before showing an onboarding screen as the first thing new user sees in the app.

When fetch fails (no internet connection/timeout) we’d like to fallback to the control variant while keeping the exposure consistent and not end up in the situation where we show the variant for “control” but on the fetch retry user is bucketed in the “new-onboarding” one.

 

so the flow is like that:

  1. user launches the app
  2. `fetch` is called
  3. `fetch` fails
  4. we access the variant which is nil so we use fallback to “control”
  5. after that user is bucketed in “new-onboarding” on the retry/when they open the app again (if I understand correctly)
  6. we end up with showing “control” but user might actually end up being exposed to “new-onboarding”. At this point we’d like to make sure that Amplitude knows that “control” variant was actually used so that there is no divergence in the analytics.

I tried calling the `exposure` method but seems like it expects using custom `exposureTrackingProvider`.

Hello,

Your understanding of the flow is correct. When the `fetch` method fails due to no internet connection or a timeout, and you access the variant which results in `nil`, the fallback to the 'off' variant is used. However, when the user is bucketed in the 'on' variant on retry or when they open the app again, it could indeed result in a situation where the 'off' variant is shown but the user might actually end up being exposed to the 'on' variant.

To avoid this, you could consider implementing a mechanism to ensure that the variant shown to the user remains consistent even if the fetch request fails initially. One way to do this could be to store the variant locally on the device after it's fetched successfully, and then use this stored variant as the fallback if the fetch request fails in the future. This way, the user will see the same variant that they were last assigned to, ensuring a consistent user experience.

Regarding the `exposure` method, it's used to manually track exposure events when automatic exposure tracking is disabled. If you're using a custom `exposureTrackingProvider`, you would need to implement the `track` method in your custom provider to handle how exposure events are tracked.

Here's an example of how you might implement a custom `exposureTrackingProvider` in the iOS SDK:

class CustomExposureTrackingProvider: ExposureTrackingProvider { func track(exposure: Exposure) { // Your custom logic for tracking exposure events goes here }}

And here's how you might configure the Experiment SDK to use your custom provider:

let config = ExperimentConfigBuilder() .exposureTrackingProvider(CustomExposureTrackingProvider()) .build()let experiment = Experiment.initialize(apiKey: '', config: config)


I hope this helps! Please let me know if you have any further questions.

Best,
Yosimy


P.S. Checkout upcoming events and user meetups on our events page.

Reply


Terms & ConditionsCookie settings