← Cloudflare Flagship / flagship / targeting

Процентные развёртывания

Процентные развёртывания позволяют постепенно раскатывать функцию на часть пользователей. Любой правило таргетинга может включать процент постепенного релиза от 0 до 100.

Используйте процентное развертывание, если нужно ограничить область влияния, провести эксперимент или выбрать часть запросов без развертывания нового кода.

Если у правила задано процентное развертывание, оно выдает свой вариант только тогда, когда совпадают и условия правила, и группа развертывания. Контексты, не подходящие под правило, переходят к следующему правилу или получают вариант по умолчанию, если ни одно из последующих правил не подошло.

Например, правило может нацеливаться на пользователей с тарифом enterprise тарифный план, то показывайте новый интерфейс только 10% таких пользователей. Пользователи, которые не попали в эти 10%, продолжают проходить по остальным правилам списка.

{
	"priority": 1,
	"conditions": [
		{ "attribute": "plan", "operator": "equals", "value": "enterprise" }
	],
	"serve_variation": "on",
	"rollout": {
		"percentage": 10,
		"attribute": "userId"
	}
}

reason в деталях оценки: SPLIT когда процентное развёртывание предоставляет вариант.

Flagship использует консистентное хеширование по настраиваемому атрибуту, чтобы распределять пользователей по бакетам развёртывания. Один и тот же пользователь всегда получает одно и то же значение флага при заданной конфигурации развёртывания. Это обеспечивает единообразный результат при повторных оценках.

По умолчанию атрибут распределения: targetingKey. Вы можете настроить, какой атрибут использовать для бакетирования, при настройке развёртывания в панели управления.

Бакеты развёртывания независимы для разных аккаунтов и флагов. Один и тот же идентификатор может попадать в разные бакеты для разных флагов, что помогает избежать взаимосвязанных развёртываний между несвязанными функциями.

Выбирайте атрибут распределения исходя из того, что должно оставаться стабильным:

Для большинства релизов функций и экспериментов используйте стабильный идентификатор пользователя или аккаунта. Значения уровня запроса используйте только тогда, когда изменение между запросами допустимо, например при выборке трафика.

Начните с небольшого развёртывания, следите за приложением, а затем увеличивайте процент по мере роста уверенности.

1. Создайте флаг с развёртыванием на 5%.
2. Отслеживайте ошибки, задержки, продуктовые метрики и отзывы пользователей.
3. Увеличивайте до 25%, затем до 50%, затем до 100%.
4. Когда развёртывание достигнет 100%, удалите временные правила таргетинга и сделайте победивший вариант значением по умолчанию.
5. После полного развёртывания функции удалите старый путь кода и сам флаг.

Считайте флаг new-checkout со следующими правилами:

1. Правило 1: plan equals "enterprise" : предоставить вариант on.
2. Правило 2: развёртывание на 25% для userId : предоставить вариант on.
3. Вариант по умолчанию: off.

В этой конфигурации:

• Все корпоративные пользователи видят новое оформление заказа.
• 25% всех остальных пользователей, определяемых по их userId, также см. новое оформление заказа.
• Остальные 75% пользователей без плана Enterprise видят стандартный процесс оформления заказа.

По мере роста уверенности увеличивайте процент развёртывания, пока не достигнете 100%.

Для простого A/B/n-теста без условий аудитории задайте долю трафика для каждого варианта в панели управления Cloudflare. Панель управления сама рассчитает накопительные пороги.

Если вы управляете простым A/B/n-тестом напрямую через API, создайте по одному правилу для каждого варианта с накопительными процентами развёртывания. Flagship оценивает правила в порядке приоритета. Если контекст соответствует правилу, но не попадает в процент развёртывания этого правила, оценка переходит к следующему правилу.

При разделении 30% / 40% / 30% между вариантами A, B и C:

[
	{
		"priority": 1,
		"conditions": [],
		"serve_variation": "variant-a",
		"rollout": { "percentage": 30, "attribute": "targetingKey" }
	},
	{
		"priority": 2,
		"conditions": [],
		"serve_variation": "variant-b",
		"rollout": { "percentage": 70, "attribute": "targetingKey" }
	},
	{
		"priority": 3,
		"conditions": [],
		"serve_variation": "variant-c",
		"rollout": { "percentage": 100, "attribute": "targetingKey" }
	}
]

В конфигурациях, управляемых через API, первое правило охватывает бакеты 0-30. Второе правило охватывает бакеты 31-70. Последнее правило принимает оставшиеся бакеты вплоть до 100. Если каждый подходящий контекст должен получить вариант, всегда задавайте для последнего правила значение 100.

Используйте один и тот же атрибут группировки во всех правилах эксперимента. Если в каждом правиле используется свой атрибут, пользователи могут не остаться в предполагаемой группе.

Таргетинг аудитории можно сочетать с многовариантным развёртыванием. Например, вы можете сделать так, чтобы в эксперимент попадали только премиум-пользователи, а затем разделить их между тремя вариантами.

Для таргетированных A/B/n-тестов повторите одно и то же условие аудитории в правиле для каждого варианта и используйте накопительные пороги развёртывания. При использовании такой схемы с несколькими правилами задавайте накопительный порог для каждого правила явно, независимо от того, работаете вы через панель управления или через API.

Для распределения только среди премиум-пользователей, где 20% получают вариант A, 40% получают вариант B, а оставшиеся 40% получают вариант C, используйте пороги 20, 60 и 100:

[
	{
		"priority": 1,
		"conditions": [
			{ "attribute": "plan", "operator": "equals", "value": "premium" }
		],
		"serve_variation": "variant-a",
		"rollout": { "percentage": 20, "attribute": "targetingKey" }
	},
	{
		"priority": 2,
		"conditions": [
			{ "attribute": "plan", "operator": "equals", "value": "premium" }
		],
		"serve_variation": "variant-b",
		"rollout": { "percentage": 60, "attribute": "targetingKey" }
	},
	{
		"priority": 3,
		"conditions": [
			{ "attribute": "plan", "operator": "equals", "value": "premium" }
		],
		"serve_variation": "variant-c",
		"rollout": { "percentage": 100, "attribute": "targetingKey" }
	}
]

Пользователи, которые не соответствуют plan equals "premium" пропускают все три правила и получают вариант флага по умолчанию, если только одно из последующих правил не совпадёт с ними.

Процентное развёртывание можно использовать для выборки на уровне запросов, выбрав атрибут распределения по бакетам для каждого запроса. Например, развёртывание на 1% позволяет включить расширенное логирование или диагностику для небольшой доли запросов.

Используйте этот шаблон только тогда, когда допустимо, чтобы один и тот же пользователь получал разные результаты при разных запросах.

Если один и тот же пользователь получает разные значения при разных запросах, в контексте оценки, вероятно, отсутствует targetingKey или настроенный атрибут bucketing.

Передавайте один и тот же стабильный идентификатор при каждой оценке:

const enabled = await env.FLAGS.getBooleanValue("gradual-rollout", false, {
	userId: session.user.id,
});

Затем настройте постепенное развертывание на группировку по userId.

Проверьте порядок правил. Универсальное правило с меньшим номером приоритета может вернуть вариант раньше, чем сработают последующие правила развёртывания. Располагайте общие универсальные правила после более специфичных.

Для простых A/B/n-тестов, управляемых через панель управления, укажите долю трафика для каждого варианта, а пороги панель управления рассчитает сама.

Для A/B/n-тестов, управляемых через API, а также для таргетированных A/B/n-тестов, настроенных как несколько правил, используйте накопительные пороги. При разделении 30% / 40% / 30% нужно задать пороги 30, 70 и 100, а не 30, 40 и 30.

Такое происходит, если контекст соответствует условиям правила, но не попадает в процент постепенного развертывания, а ни одно из последующих правил тоже не совпадает. Добавьте более позднее правило или используйте финальное правило со 100%, если каждый подходящий контекст должен получать не значение по умолчанию, а другой вариант.