Ron Kohavi в книге Trustworthy Online Controlled Experiments перечисляет типы архитектуры при вызове API методов платформы для A/B экспериментов.
1 решение. Очевидное.
variant = getVariant(userID)
if(variant==Treatment) then
buttonColor = red
else
buttonColor = blue
2 решение. Параметрическое.
variant = getVariant(userID)
if(variant==Treatment) then
buttonColor = variant.getParam(“buttonColor”)
else
buttonColor = blue
В этом решении вы уже больше “доверяете” платформе. Ваш “клиент” не знает всех значений параметра, и на своей клиентской части оставляете только дефолтное значение параметра.
3 решение. Полный переход на платформу A/B-тестирования.
buttonColor = config.getParam(“buttonColor”)
В этом решении метод getParam уже содержит в себе:
1. Выдачу всех возможных значений.
2. Регистрацию пользователя в эксперименте.
3. Дефолтные значения параметров.
Какую архитектуру выбрать? Зависит от объема кода, завязанного на эксперименты, и от того, насколько вы (как программист) привыкли работать в условиях непрерывного AB-тестирования.
1 решение. Очевидное.
variant = getVariant(userID)
if(variant==Treatment) then
buttonColor = red
else
buttonColor = blue
2 решение. Параметрическое.
variant = getVariant(userID)
if(variant==Treatment) then
buttonColor = variant.getParam(“buttonColor”)
else
buttonColor = blue
В этом решении вы уже больше “доверяете” платформе. Ваш “клиент” не знает всех значений параметра, и на своей клиентской части оставляете только дефолтное значение параметра.
3 решение. Полный переход на платформу A/B-тестирования.
buttonColor = config.getParam(“buttonColor”)
В этом решении метод getParam уже содержит в себе:
1. Выдачу всех возможных значений.
2. Регистрацию пользователя в эксперименте.
3. Дефолтные значения параметров.
Какую архитектуру выбрать? Зависит от объема кода, завязанного на эксперименты, и от того, насколько вы (как программист) привыкли работать в условиях непрерывного AB-тестирования.