← Cloudflare Flagship / flagship / targeting

Procentuální rollouty

Procentuální rollouty umožňují postupně uvolňovat funkci pro část vašich uživatelů. Libovolný cílicí pravidlo může obsahovat procento rolloutu mezi 0 a 100.

Procentuální rollouty použijte, když chcete omezit rozsah dopadu, spustit experiment nebo vzorkovat požadavky bez nasazování nového kódu.

Pokud má pravidlo procentuální rollout, poskytne svou variantu jen tehdy, když odpovídají jak podmínky pravidla, tak bucket rolloutu. Kontexty, které pravidlu neodpovídají, pokračují k dalšímu pravidlu, případně dostanou výchozí variantu, pokud jim neodpovídá žádné další pravidlo.

Například pravidlo může cílit na uživatele na enterprise plánu, poté zobrazte novou zkušenost pouze 10 % z těchto uživatelů. Uživatelé mimo těchto 10 % pokračují zbytkem seznamu pravidel.

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

reason v podrobnostech vyhodnocení je SPLIT když procentuální postupné zavádění zobrazuje danou variantu.

Flagship používá konzistentní hashování na konfigurovatelném atributu, aby přiřadil uživatele do rollout bucketu. Stejný uživatel vždy dostane stejnou hodnotu flagu pro danou konfiguraci rolloutu. Díky tomu zůstává zkušenost konzistentní napříč opakovanými vyhodnoceními.

Atributem pro bucketing je ve výchozím nastavení targetingKey. Atribut použitý pro bucketing můžete nastavit při konfiguraci rolloutu v dashboardu.

Rollout buckety jsou nezávislé napříč účty a příznaky. Stejný identifikátor může u různých příznaků spadnout do jiného bucketu, což pomáhá předcházet korelovaným rolloutům mezi nesouvisejícími funkcemi.

Zvolte atribut pro bucketing podle toho, co má zůstat stabilní:

Pro většinu uvedení funkcí a experimentů použijte stabilní identifikátor uživatele nebo účtu. Hodnoty na úrovni požadavku použijte pouze tehdy, když je přijatelné, aby se mezi požadavky měnily, například u vzorkování provozu.

Začněte s malým rolloutem, sledujte svou aplikaci a poté procento zvyšujte s tím, jak roste důvěra.

1. Vytvořte příznak s rolloutem na 5 %.
2. Sledujte chyby, latenci, produktové metriky a zpětnou vazbu od uživatelů.
3. Zvyšujte na 25%, poté 50% a nakonec 100%.
4. Jakmile rollout dosáhne 100 %, odstraňte dočasná cílicí pravidla a nastavte vítěznou variantu jako výchozí.
5. Jakmile je funkce plně nasazena, odstraňte starou cestu kódu a smažte příznak.

Uvažujte o příznaku new-checkout s následujícími pravidly:

1. Pravidlo 1: plan equals "enterprise" : zobrazit variantu on.
2. Pravidlo 2: rollout 25 % na userId : zobrazit variantu on.
3. Výchozí varianta: off.

V této konfiguraci:

• Všichni uživatelé s plánem Enterprise vidí novou pokladnu.
• 25 % všech ostatních uživatelů, určených podle jejich userId, uvidí také nový pokladní proces.
• Zbývajících 75 % uživatelů mimo Enterprise vidí standardní platební proces.

Jak budete získávat jistotu, zvyšujte procento rolloutu, dokud nedosáhnete 100 %.

U jednoduchého A/B/n testu bez podmínek pro publikum nastavte podíl provozu jednotlivých variant v Cloudflare dashboardu. Kumulativní prahové hodnoty za vás vypočítá dashboard.

Pokud spravujete jednoduchý A/B/n test přímo přes API, vytvořte pro každou variantu jedno pravidlo s kumulativním procentem rolloutu. Flagship vyhodnocuje pravidla podle priority. Pokud kontext odpovídá pravidlu, ale nespadá do jeho procenta rolloutu, vyhodnocení pokračuje dalším pravidlem.

Pro rozdělení 30% / 40% / 30% mezi varianty A, B a 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" }
	}
]

V konfiguracích spravovaných přes API pokrývá první pravidlo buckety 0-30. Druhé pravidlo pokrývá buckety 31-70. Poslední pravidlo zachytí zbývající buckety až do 100. Pokud má variantu dostat každý způsobilý kontext, nastavte poslední pravidlo vždy na 100.

U všech pravidel v experimentu používejte stejný atribut pro bucketing. Pokud každé pravidlo používá jiný atribut, uživatelé nemusí zůstat v zamýšleném rozdělení.

Cílení na publikum můžete zkombinovat s rolloutem s více variantami. Můžete si například přát, aby do experimentu vstupovali pouze prémioví uživatelé, které pak rozdělíte do tří variant.

U cílených A/B/n testů opakujte stejnou podmínku pro publikum u pravidla každé varianty a použijte kumulativní prahové hodnoty rolloutu. Při použití tohoto vzoru s více pravidly nastavte kumulativní prahovou hodnotu pro každé pravidlo explicitně, ať už používáte dashboard, nebo API.

Pro rozdělení pouze mezi prémiové uživatele, kde 20% dostane variantu A, 40% variantu B a zbývajících 40% variantu C, použijte prahové hodnoty 20, 60 a 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" }
	}
]

Uživatelé, kteří neodpovídají plan equals "premium" přeskočí všechna tři pravidla a obdrží výchozí variantu příznaku, pokud se na ně nevztahuje některé pozdější pravidlo.

Procentuální rollouty můžete použít pro vzorkování na úrovni jednotlivých požadavků, a to volbou atributu pro bucketing daného požadavku. Rollout na 1 % požadavků může například zapnout podrobnější logování nebo diagnostiku jen pro malou část požadavků.

Tento vzor používejte pouze tehdy, když je přijatelné, aby stejný uživatel dostával při různých požadavcích odlišné výsledky.

Pokud stejný uživatel dostává napříč požadavky odlišné hodnoty, v kontextu vyhodnocení pravděpodobně chybí targetingKey nebo nakonfigurovaný atribut pro rozřazování do skupin.

Při každém vyhodnocení předávejte stejný stabilní identifikátor:

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

Poté nakonfigurujte rollout tak, aby řadil kontexty do bucketů podle userId.

Zkontrolujte pořadí pravidel. Záchytné pravidlo s nižším číslem priority může vrátit variantu dříve, než se spustí navazující rolloutová pravidla. Obecná záchytná pravidla řaďte až za konkrétnější pravidla.

U jednoduchých A/B/n testů spravovaných přes dashboard zadejte podíl provozu jednotlivých variant a nechte dashboard vypočítat prahové hodnoty.

U A/B/n testů spravovaných přes API nebo u cílených A/B/n testů nastavených jako více pravidel použijte kumulativní prahové hodnoty. Rozdělení 30% / 40% / 30% by mělo používat prahové hodnoty 30, 70 a 100, nikoli 30, 40 a 30.

To se může stát, když kontext splňuje podmínky pravidla, ale nespadá do procenta rolloutu, a žádné pozdější pravidlo mu neodpovídá. Pokud má každý odpovídající kontext dostávat jinou než výchozí variantu, přidejte další pravidlo, nebo použijte závěrečné pravidlo se 100 %.