Hi there! I’m new to Growthbook and looking to conduct an experiment where one website page serves as the control and another as the variant. From what I’ve gathered in the documentation, I can achieve this by checking the variants on each website and redirecting accordingly. Is that the correct approach or is there a better way to go about it?

I'm not sure what exactly you mean by "checking the variants on each website" but if you mean checking the variant on page load and then redirecting, that could cause some flickering or delay that could be problematic. However, that is a reasonable approach. In general, there are a few ways to go. Generally the following are options that you could consider, from best to worst in terms of user experience and data quality: • Conditional rendering of page A versus B using the GrowthBook SDK within backend controller logic. Fast, no bias, no awkward "jumpy" redirection. • Frontend conditional rendering of page A versus B using the GrowthBook JS SDK. Almost as good, slightly loading delay, and can be done with no bias if both A and B incur the same page load penalty. Preferably you can implement this without any flickering for users, but there will be some slight loading delay. • Frontend redirection using JS snippets in the visual editor using

window.location.href="mytarget.html"

. Problematic but likely good enough if done carefully. Incurs noticeable flickering before/after redirection. Ideally the redirection should happen from a neutral / empty-ish page for both the A and B treatments as to not introduce bias (e.g. avoiding the case where page A just loads faster due to the experiment config so people like it more).

Ok, so if my page A is in a Rails application, I can use the SDK and do a redirection in a rails middleware to page B, which is in a different Next js application? or Do the A and B pages need to exist within the same application (host)?

Do the A and B pages need to exist within the same application (host)?

I'm not sure, but I'd wonder whether sending people to another app would be the eventual production behavior or if this is a necessity of testing, in which case you could be hurting page B by making it have a longer load time/worse experience only in the test.

That’s the eventual production behavior. If the new app (page B) gets better conversions than page A then we will be doing this redirection permanently until a full migration os possible and we only use the new app, if that makes sense