Good afternoon, GrowthBook team. Hope you’re all doing well. We’re encountering an issue related to our recent A/B test, and I’d appreciate your guidance. CONTEXT We ran an A/B test from April 30 to May 26, splitting new signups 50/50 into two groups: • Group A: saw Promotion X • Group B: saw Promotion Y Group B outperformed Group A, so on May 26, we: • Moved 100% of traffic to Group B to ensure the new signups from that date forward would correctly see Promotion Y • Deactivated Promotion X in our system PROBLEM After ending the test, we received complaints from users who couldn’t apply Promotion X even though they could still see it in the UI. These users were originally part of Group A (the control group) during the A/B test period. To resolve this, we used the “Start a New Phase” feature on June 10, expecting that users previously in Group A would now follow the logic of Group B. However, that transition did not occur, and users are still facing the issue. QUESTION How can we ensure that users from a previous test group (e.g., Group A) are migrated to the winning group (e.g., Group B) when an experiment ends? What are we missing in this case? Thanks in advance for your support. Let me know if you need any additional details 🙏

Generally, the best procedure here is to remove the flag, so that all traffic directed to the new promotion. Until you're able to do that, though, you can use the Temporary Rollout feature to direct all traffic to the winning variation.

I’ll do it and share my findings in this thread. Thank you for the support 🙂

Hey @strong-mouse-55694 , I am from Washmen working closely with @purple-breakfast-88896 . Two follow up question: 1. I think your proposal is best way to handle concluded experiments. So we will remove the flags for the next upcoming release. We remove the code and point the winner only. My understanding is correct right? 2. But for the old customers who do not upgrade , we want them to see winner version. As per my understanding "Start a New Phase" would not respect old assignment and assign the customer according to the new traffic %age. Is this how it works? If this is the case it is not working for us. Can you please guide us?

Yes on 1. You remove the flag and just use the winning code. So this:

const useNewCheckout = gb.isOn('new-checkout')

if (useNewCheckout) {
  return <NewCheckout />
} else {
  <OldCheckout />
}

becomes:

<NewCheckout />

2. When you stop the experiment, you can choose your winner and then enable the temporary rollout. This will direct all traffic to the winning variation. This is the easiest way to do it. If you can reach a point where all users have upgraded, then you could delete the experiment altogether. "Start new phase" is intended for starting a new experimentation phase (if you need to change the experiment), so it's not the right choice here.

Hey @strong-mouse-55694 we did temporary rollout feature. But it didn't work for some customers. Could you please help ? Experiment: https://app.growthbook.io/experiment/exp_19g621m9l73o8t But still I see the other variant

I'm not able to see the experiment. Can you share a screenshot?

Screenshot 2025-06-25 at 3.24.16 PM.png

Is this still the experiment where you started a new phase? And the expectation is that all users will now receive the "Washmen65" variant? Final question, how did you implement this experiment (React/NextJS/HTML/etc.)

Yes then , we changed it to temporary rollout. React

Hmm. It should be deploying to the winning variant. Are you able to share the page where this is happening for further debugging?

Do you mean the code of the page?

I meant the page where the experiment is/was live

• It is within the app, • This is the experiment link https://app.growthbook.io/experiment/exp_19g621m9l73o8t

Sorry for the confusion, but I'm not talking about the experiment in GrowthBook (I'm not able to access your experiment). Is the experiment live on a page on the web? It'd be helpful to see that page if so

Ryan I told two times it is within app , I shared the screenshot in previous message.

Sorry, I didn't understand what you meant "within app." I thought you were referring to within the GrowthBook app. There are two things you can do to debug. 1. In your React code, how are you refreshing the features? Are you confident that the new feature rules are being served in the app? 2. If you go to your React Native SDK connection, what's the output from the SDK endpoint? It'll look like this: https://cdn.growthbook.io/api/features/sdk-RnJBx5daWiRjyb0x

1. Streaming enabled in our sdks, feature updates are delivered to apps via SSEs. - this is vital point for backend app, because it is initialized once and runs for a long time period. It is tested on customer backend sdk. 2. I'm not sure what are they referring to output from sdk connection. SDK connection outputs following. Maybe they are talking about API call gb sdk makes.

export interface InitResponse {
  // If a payload was set
  success: boolean;
  // Where the payload came from, if set
  source: "init" | "cache" | "network" | "error" | "timeout";
  // If the payload could not be set (success = false), this will hold the fetch error
  error?: Error;
}

our gb context have features in similar schema as they shared. which is populated from api call from gb sdk.

So, my concern with these questions is this: • I've seen devs get tripped up on React Native, where they think feature values are updating with SSE but they really aren't, which could cause stale values to be served to users. It sounds like that's covered, but it's something you verify. • I was asking about the SDK endpoint payload. For example, for one of my apps, that endpoint is https://cdn.growthbook.io/api/features/sdk-RnJBx5daWiRjyb0x. This is found in the SDK Connection page in GrowthBook. You can inspect that payload to ensure that the right rules are being served from GrowthBook. If they are, then you know it's something happening at the app level, not within GrowthBook itself.

Hi @strong-mouse-55694 thanks for your help, here is our setup; 1. In first picture you can see Streaming Updates is enabled for our SDK. 2. And in the second picture, you can see that gb instance is initiated using streaming: true flag What do we miss here 👀

For the SDK, default caching should work. What we don't know here is whether the app is actually serving the new values. Are you able to verify that? And share the payload from the SDK endpoint?

hi ryan here you can find our sdk response. I took it from

<https://cdn.growthbook.io/api/features/sdk-XXXXXXX>

as you suggested. Feature key is

first-order-promo

I also attached feature rules.

Awesome. So you can see that the temp rollout is there, in that a user who meets those conditions will get the specified value (and there's no splitting among users) Since that's not happening, it's something to on the app side of things: • The updated payload isn't being received, processed correctly, or something similar

"first-order-promo": {
      "defaultValue": "uspPromocodeText50",
      "rules": [
        {
          "condition": {
            "total_completed_orders": 0,
            "signup_date": {
              "$gt": "2025-05-02T00:00"
            }
          },
          "coverage": 1,
          "hashAttribute": "id",
          "seed": "773e74c3-f235-46f1-85de-f7877e75f03d",
          "hashVersion": 2,
          "force": "uspPromocode65Exp"
        }
      ]
    },