Hi team! Could you clarify the expected sticky bucketing behavior when user attributes change after the initial assignment? We have an experiment targeted by registration date. Since evaluation happens before authentication, a returning user on a fresh install can initially qualify and receive an assignment. After login, we load their actual registration date, which no longer matches the targeting condition. In the Swift SDK, once a sticky assignment is found for the current

bucketVersion

, the experiment condition is not re-evaluated, so the user remains enrolled. Is preserving enrollment after the user becomes ineligible intentional? If eligibility should be re-evaluated after authentication, what is the recommended approach: delay the initial evaluation, disable sticky bucketing for this experiment, or model the targeting differently?

Hi @late-ambulance-66508 Let us check that and we'll write you back

We’ve come to the conclusion that the only correct approach for us is to assign users to the experiment when the app launches, which is why this problem arose. The solution I see right now is to add a rule before the experiment that uses the opposite conditions and filters out users before they are assigned to the experiment, but it feels like an unnecessary increase in payload size and workload.

Hi @late-ambulance-66508! Confirming: this is intentional and not Swift-specific — it's the shared spec behaviour across all GrowthBook SDKs. Once a sticky bucket exists for the current

bucketVersion

, targeting conditions are deliberately not re-evaluated (same

if (!foundStickyBucket)

check in the JS SDK). Sticky bucketing is designed to keep enrollment stable across exactly this kind of change. The root cause is that the experiment is evaluated before the targeting attributes are available — sticky bucketing just persists that early decision. You don't need an extra rule with inverted conditions — the cleanest fix is a targeting change on the experiment itself, not a code change. Add a presence check to the experiment's own targeting, e.g.

{"registrationDate": {"$exists": true}}

. Pre-login the attribute is missing, the user doesn't qualify, and no sticky document is written at all — nothing to undo later. After login you

setAttributes(...)

, re-read the flag, and bucketing is correct. To clean up assignments already persisted in production, bump

bucketVersion

(with

minBucketVersion

to block the old ones) — note this resets enrollment, so worth checking with whoever owns the experiment's analytics. If you must bucket at app launch regardless, `disableStickyBucketing`: true re-evaluates targeting every time; trade-off is the variation can change.

Okay, thanks. Your approach doesn't work for me, but I got your point. Maybe I'll add something to the fact tables.