I have a question about experiment attribute targeting and sticky bucket cache invalidation. Assume I have an experiment that is targeted at ("shoe_size"=7). I check for the feature value with the attribute ("shoe_size"=7) and cache the result; maybe the user is included in the experiment, maybe they get the A or B feature value. Later the user changes their shoe size to 7.5. In my application code, I know this is an attribute I'm passing to growthbook but I haven't hardcoded a copy of the experiment config. This attribute changing might mean that the feature value I have cached is no longer appropriate, or it might not. Is there an SDK or API call I can make that will tell me if the current set of attributes invalidates the cached previous response? or, please let me know if I'm thinking about this the wrong way.

I'm not sure I understand your overall goal. Are you primarily using sticky bucketing for caching, so that fewer requests are made for features? In your example, if the user's shoe size changes, are you interested in them staying in the same variation or switching? Thanks!

Hey @strong-mouse-55694 thanks for the reply. Yes, we're intending to cache the reply locally so that we make fewer calls. So we're trying to implement cache invalidation on top of sticky bucketing. I know growthbook uses deterministic hashing of attributes so that the same call should always get the same response. Is that hash limited to the attributes that are relevant to that specific experiment? We may be passing in a number of attributes all the time, but a specific experiment may refer to any subset of those. If an irrelevant attribute changes, or an attribute changes in an irrelevant way, will an API call return the same response or will the response change (will the hash change)? For example if the targeting is ("shoe_size" <=7), and the shoe size goes from 7 to 6.5, the hash would presumably change and the assignment would change. We really only want to know if they pass the targeting restriction, and if so, we don't want to move them. They're still in the target group. We'd like the ability to get a pass/fail on targeting without changing the response. We considered that we could call the API and potentially know that they were included in the experiment or not, and that would tell us what we needed to know. But if the experiment is set up to only include 50% of traffic, I don't know if we can reliably tell that they passed the targeting filter or not. They may be excluded because they are now in the other 50% of traffic.

@acceptable-arm-167 Thanks for the reply. I can answer part of this question and will follow up on the rest. With user attributes, deterministic hashing depends on the Assignment Attribute you choose when setting up the experiment. Generally, this is some kind of user ID. No other user attributes factor in here. The other element in deterministic hashing is the experiment key. Also, because experiment assignments are deterministic, they don't require an API call for evaluation. They can happen within the SDK. What are you using for the experiment's assignment ID? And how are you implementing sticky bucketing?

Thank you @strong-mouse-55694. If the experiment has attribute based targeting, is that also applied on the client side at the SDK? I think what you're saying is that we can always use the SDK method, if the attributes still qualify for targeting then you'll always get the same response because the response is strictly based on the assignment attribute.

Yes, that's what I was saying. You might not need sticky bucketing. GrowthBook also implements some caching automatically (e.g., here are the options available if you're using the JS SDK). The next step up from that is using a proxy or our Edge SDK. Let me know, though, if you still have questions about Sticky Bucketing/caching and/or assignment. Happy to help.