トラフィックに敬意を払う A/B テスト
多くのストア実験は小さすぎて何も結論できず、多くの「勝者」は翌月回帰するノイズです。上手くテストするとは、少なくテストすることです。
EC の A/B テストには不都合な秘密があります：相当なトラフィック量を下回ると、ページ変更が現実に生む効果量を大半のテストは検出できません。誠実なワークフローは、明白な問題は直接直し、実験は十分な流量のあるページの本当に不確実な意思決定に取っておき、結論が実際に可能なサイズに設計することです。エージェントが強制するのはまさにその規律です。
何がテストに値し、何が値しないか
壊れたモバイルレイアウトに実験は要りません。修正が要ります。テストは、理性的な人々の意見が割れ、データが決着をつけられる意思決定のためのものです。
直接修正：明白な欠陥、速度問題、欠落情報、壊れたフロー
テスト：価格の見せ方、オファーの框組み、実トレードオフのある構造選択
Analyst が事前に、妥当な効果量を検出できる流量か計算
結論の出ないテストは開始しない——その流量は他へ
仮説はスワイプファイルでなくファネルから
良いテストは自社の離脱データから来ます：特定のページ、特定のセグメント、特定のためらい。Analyst はファネルが実際に漏れている場所から仮説を生成し、記事から借りたアイデアより少なく良い実験を生みます。
「差なし」を含む正直な結論
効果なしを示すテストも情報です——その意思決定は重要でないから悩むのをやめよ、という意味。エージェントは不確実性を保ったまま結果を報告し、覗き見は覗き見と呼び、すべての結果を共有メモリに記録して、同じ議論が翌四半期に蒸し返されないようにします。
動作の流れ
バックログを選別
明白な欠陥は Builder へ直接修正でルーティング。本物の不確実性だけがテスト候補に。
開始前にサイズ計算
Analyst が妥当な効果を検出できる流量か計算——検出力不足のテストは走らせません。
実行・結論・記録
ヌル結果を含め正直に報告し、保存して意思決定を確定状態に保ちます。
得られるもの
実際に結論へ到達できるテストに使われるトラフィック
実験の後ろに並ばず即座に直される明白な問題
自社ファネルデータに根ざした仮説
ヌル結果も含む記録された結果の履歴
担当するエージェント
よくある質問
A/B テストに必要なトラフィックは？
検出したい効果量次第です——小さな効果は非常に大きなサンプルを要します。エージェントは開始前にテストごとに計算します。まさに大半のチームが飛ばすステップです。
低トラフィックのストアは代わりに何を？
欠陥を直接直し、見えるほど効果の大きい大胆な変更をし、正直な注釈つきの前後比較に頼ること。実験ごっこは最悪の選択肢です。
勝ったテストがなぜ勝ち続けない？
たいてい元の結果がノイズだったか、覗き見されて早期に止められたから。適切なサイズ設計と固定の停止ルールで大半は防げます——エージェントが強制するのはそれです。
メールもテストできますか？
できます。メールは統計条件がしばしば良い——サンプルが大きく、帰属がきれい。同じサイズ設計の規律が Retention エージェント経由で適用されます。