Hi GrowthBook team, We’re facing a critical blocker that’s affecting our release. We are running an A/B/C experiment targeting customers who haven’t placed any orders before — and the goal is to target each customer only once. However, we’ve encountered an issue due to how attributes are synced: Experiment Setup We are using the following feature flag setup in GrowthBook: • Default:

{ "type": "none" }

• Free delivery enabled:

{ "type": "delivery", "charge": 0 }

• Express delivery enabled:

{ "type": "express-delivery", "charge": 0 }

In production, we’re manually forcing a specific type for certain users by targeting their IDs. However, some users are still receiving the default value unexpectedly. Technical Context • Customer attributes are populated from DynamoDB on app initialization. • If the app is not killed and relaunched, these attributes are not updated again. • We use the following logic to set attributes:

js

const user = useSelector(selectUser);
const attributes = useAttributes(user); // React 19 Suspense-ready async logic

useEffect(() => {
  const current = gbInstance.getAttributes();
  const incomingID = attributes?.id || attributes?.adid;

  if (current?.id === incomingID || current?.adid === incomingID) {
    return;
  }

  gbInstance.setAttributes(attributes);
}, [gbInstance, attributes?.id, attributes?.idfa]);

C*urrent Problem* • Attribute updates are not happening frequently enough, so customers are getting targeted more than once, which violates the experiment goal. • The forced values via targeting seem to be ignored, and the default is applied in some cases. Desired State We’d like GrowthBook to be updated immediately after DynamoDB is updated with new customer attributes — so that customers can be accurately targeted only once. Questions 1. What is the best practice for syncing updated user attributes mid-session or mid-app lifecycle? 2. Is there a way to "re-evaluate" the experiment exposure after updating attributes manually? 3. Have you observed any recent issues or lag in attribute sync or targeting logic? 4. Would using a unique session identifier help isolate and limit targeting to a single exposure? This is a time-sensitive issue, so your guidance will be very much appreciated.

Hey @orange-jordan-21834! I don't see anything obvious in your implementation that would cause the issue you're seeing. Whenever attributes are updated, the SDK will reevaluate experiments. What I think you should confirm is that the logic in the

useEffect

hook is actually updating as expected. Additionally, have you tried using our Dev Tools to help debug? That might provide some additional context on which attributes GrowthBook is currently seeing.

Hello, @strong-mouse-55694. Glad to meet you and hope you're well. I have a question about the A/B/C experiment Sercan mentioned in this thread and I'd love to hear your feedback from it. I can set many rules on the features level (picture below) and I'd like to confirm the sequence that Growthbook execute the them. Are the numbers 1, 2, 3 in the picture below the order of rules' execution or just the order we created the them? In our case, I need to make sure it runs the rule #1. If false, then rule #2. Else, rule #3. I really appreciate your guidance here 🙂

You're correct. The first matching rule for a user will be applied, so order matters. If there are no matching rules, the default value will be used.

Thank you for the quick reply, Ryan.