Hey, a question. When we instantiate an SDK instance, send the user attributes, and call the .load_features() method, what exactly does the client receive? Is there any chance that the Growthbook SDK is propagating, for example, the list of users from a Saved Group to the client side? Thank you!

It's the list of all feature definitions and visual experiments. This includes the feature rules -- if a rule references a saved group, then that saved group gets included in the payload. If you want to obfuscate this, you can use encryption and/or secure attribute hashing (configurable in your SDK Connection). If you require complete privacy/security, you should do your feature flag evaluation on your webserver instead of the front-end. Note: We are actively developing a turnkey version of server side evaluation for front-end SDKs.

@happy-autumn-40938 Oh right, that makes sense. my concern is, for example, given this use case: On the client side I have a playerId and some attributes. There is a saveGroup with a million playerIds. Then, from the client side, I run a .load_features() for that user to check if he should activate or not a feature flag. So, from these two scenarios: • 1: Growthbook evaluates if this playerId should activate a feature flag or not, since it is inside a saved group, and then sends that processed information down to the client. • 2: The entire features definition + saved groups list of users will be sent to the client side, and then the client will be responsible for evaluating if the playerId should activate the feature flag or not based on this extensive list of playerIds (saved group). Which one is the correct expected behavior?

If you are using client side evaluation, then scenario 2 is correct. You could shift the burden to server side evaluation and only ship down the flag results if preferred. Another option is to keep the player list lookup outside of GrowthBook entirely as a separate API call (either backend or frontend-triggered), and then use that to set some arbitrary user attribute such as

inUserGroup: boolean

@happy-autumn-40938 gotcha, thanks for the quick response. We’re still architecting the best approach for this, but it looks like the server side has its advantages.

Also worth considering, if using a savedGroup with a million playerIds, you may end up maxing out on the payload size. I think it's around 2MB or so for the entire SDK payload. Probably best to use an external lookup (or wait for first-class support in GrowthBook possibly in Q4).

Hey @happy-autumn-40938, that makes complete sense. Thank you very much for the explanations. Yesterday, I started sketching a diagram for a possible solution using the server-side SDK, but some questions arose: • On the server side, do we send anything to Growthbook, like a list of attributes? That was my initial thought, but I believe I might be mistaken, considering that validation is done locally in the SDK, so I’d like to confirm this. • What are the downsides of this approach when not using the SDK on the client side? What functionalities would the SDK provide on the client side that could be lost when used on the server side? Thanks in advance!

It's a bit tricky to assess this without better understanding what your end goal is - ie: what sort of functionality would you be gating via purchase? It seems to me that you could probably summarize everything with a

customerType: "vip" | "paid" | "battle pass"

sort of variable and do away with the saved group entirely. Unless you need to do specific targeting based on user id that isn't captured by this (in which case you might introduce a new variable summarizing which custom group they're in). Also when you say "send fresh attributes to GB" do you mean updating the user attributes at the GB SDK level? There isn't any sort of round trip to GB servers that happens here; instead features should be loaded from the GB server and cached in the SDK - typically after the SDK is constructed. Then any user attribute changes causes a local on-the-fly re-evaluation of the user's features / experiments. This happens within the SDK rather than on a GB server.