I also have a few additional questions: 1. There are a number of past tests we have run which only wants to include users conditional on the user e.g. performing a search under specific conditions. As covered in your documentation, it's best to assign audience to an experiment as close to the test as possible. a. It seems like from e.g. the React SDK documentation that we'd load all the features from GrowthBook, which we'd expect to do when a user first begins their session. I'd expect to want to refresh features when an attribute changes, e.g. when a user logs in - are there any other instances where I'd want to do that? Would refreshing features on a specific page load assign the user to the experiment any differently, if the page load does not affect any of the user attributes sent? b. An alternative way to do this is activation metrics, where e.g. the activation metric is if the user made a specific search. However, if the bucketing is done before the user reaches the page, the number of users who visit that page from each bucket might not match the specified ratio - is that correct? c. Another way is to add a user attribute for the specific criteria e.g.

madeSpecificSearch

- Are there limitations or downsides to doing it this way? I expect this would necessarily mean the features need to be refreshed when this attribute updates, and possibly a longer load time if we were to wait for the features to load on a page. d. Are there any other ways to do this that I should consider/you recommend? 2. In your Fair Use policy, it’s stated that there’s a soft limit on API requests per month, but that we should get in touch if we expect to use beyond this amount. a. It states: “Where possible, we'll reach out to you ahead of any action we take to address unreasonable usage and work with you to correct it.” i. In the case that usage is looking to go above this 10M limit, what would be the possible next steps to happen? ii. If we are in the process of taking action to address usage, would there be a risk of GrowthBook no longer serving feature flags or A/B tests to users? b. On the Pro license, would there be an option to increase the usage limit (like there is in the Enterprise plan)? 3. As mentioned above looking to also support using the Visual Editor a. I just noticed a warning in the docs saying:

The Visual Editor may not work optimally on client-side rendered apps (e.g. React.js, Vue.js). Consider using Feature Flags instead for smoother integration.

Not sure if I missed it on earlier reads, could you elaborate on why? Is it related to client-side apps rerendering and causing repeated flickering? b. More generally, does GrowthBook support anything like a "component library" of blocks editors that can be pasted into the visual editor 4. For users who have rejected to cookies or have something to block cookies on the website, we'd like to make sure that we can still roll out features to all users, at least at 100% rollout. I understand it's suggested to use a

cookieId

for sticky bucketing purposes, and in the case where users consent to cookies that would be fine to implement, and when they don't we wouldn't be able to collect data to use for experiment analysis anyway. However, for the purposes of feature rollout, if a user has an empty attribute that the rollout is targeting, can I confirm that the user would still receive the feature flagged property when rollout is at 100%? If the rollout is not at 100%, how would an empty attribute be treated by the rollout rules? Would it skew the rollout numbers i.e. at 10% it's actually rolled out to a bit less or a bit more, depending on which side of the rollout users with a blank attribute are assigned to?