Hi all, If attaching Growthbook to a CMS - setting the experiment id and variation id via fields for the editor. Do I need to set up a feature in Growthbook to attach to an experiment or can I just create an experiement directly?

⭐ Our official support hours are 6:30am - 5pm Pacific Time, Monday through Friday. You may occasionally hear from us outside of these hours. Your support request has been logged in our system. Our support team will get back to you very soon!

you can load an experiment inline, but if you want to use our API call for the payload, that has to be defined as a feature rule.

So by doing "Inline Experiemnts" will Growthbook still control the rollout/assign variation from the interface and who is targeted? What am I primarily missing by not also setting a feature?

Using GrowthBook with a CMS is a little tedious at the moment, but we're working on making the process smoother. Can you share what CMS you're using and describe your use case a little more? Want to make sure we're covering all the bases with the improvements we have planned

Thank you for reaching out Jeremy. The use case is for an editor to create different versions on a page by using the splittests setup from Growthbook. We are using Umbraco this time. A user creates a content block for splittest. Inside this content block they can put in new blocks for each variant. Each variant block can then contain as much content and other blocks as the editor needs. The main block is given the feature key and each variant block is given the variation key for each variant. By using the blocks allready defined in the CMS for splittesting the risk of breaking something in a test is very low and the ability to set up beautiful content that works in all breakpoints is very high. However it is a bit confusing for the editor to need to set up first a feature and the an experiment in Growthbook and on top of that understand what keys for experiement/feature and variant that goes where in the CMS. Also it seems to them like they need to do the samething twice. Can you explain to me the need for having to include the feature setup first? (so I can explain it to the editors) Or describe a way for us to code it so we only need to set up an experiment. And still be able to control the roll our split on the fly - together with rules for hold outs.

Hi Kasper, Creating a feature before an experiment is a common workflow because feature flags are often used to control the rollout of new features and to run experiments (Feature Flag Experiments).

Thank you for this @brief-honey-45610 Can I still control the roll out in Growthbook? Only getting in 10% of users, only to users with specific attribute, adjust so variation 1 gets 80%, etc? In other words what am I missing by not using the feature part?

Inline experiments are ones that are configured entirely in code. You specify the targeting rules, traffic split, etc. all entirely in code and not in the GrowthBook UI. If you want to make a change to an inline experiment, you need to change and deploy your code. They can't be controlled from within the UI.