商品ローンチのチェックリスト
ローンチの失敗は悪い商品より忘れられた細部から来ます：計測なしで出たページ、下書き URL に繋いだ配信、1 か月遅れの metadata。チェックリストが薬で、自動化は自走するチェックリストです。
どのローンチも同じ 20 のステップを同じ依存順で踏み、急いだローンチはそのうち 3 つをランダムに飛ばします。この playbook はステップを 3 フェーズに固定します——前の準備、最中の順序、後の測定——20 回目のローンチがチェックリストと同じだけ完全で、どのローンチも誰かの記憶に依存しないように。エージェントが常設プログラムとして回すものの手動版です。
フェーズ 1：誰の目にも触れる前に準備
ローンチ前は徹底が安い局面です。ページの完成：ローンチの位置づけに答えるコピー、並んだ画像、構造化されたバリエーション、価格と在庫の投入。測定の配線：テスト購入での商品イベント発火の確認、配信 UTM の割り当て。検索層の用意：書かれた metadata、有効な構造化データ、関連コレクションとコンテンツからの内部リンクをページと同時に公開できる状態に。
ローンチブリーフに照らして完成・レビュー済みのページ——コピー、画像、バリエーション、価格
テンプレ任せでなく実際のテスト取引で検証された計測
metadata・構造化データ・待機中の内部リンクが一括公開できる状態
ローンチメールは起草・セグメント・予約済み。サポートには商品の周知
フェーズ 2：依存順にローンチ
ローンチ当日は順序です：ページ公開と検証が先（実際の人が読み込み、カートに入れ、イベントを確認）、次に内部リンクとサイトマップ ping、それから高親和セグメントへの告知、その後に広いチャネル。ページ公開と最初の配信の間の余白が安全マージンです——余白内で見つかる問題は数分の損、配信後に見つかる問題はキャンペーンの損。
フェーズ 3：第 1 週が第 2 週を決める
初期データは 3 つの異なる問いに答え、どれが失敗かで対応が変わります：トラフィック（人は来ているか——配信の問題）、転換（来た人は買っているか——ページの問題）、増幅（買った人はレビューし再来するか——商品のシグナル）。別々に、最初の 1 週間は毎日読み、感覚でローンチ全体を回すのでなく、所有する層へ修正を回します。
動作の流れ
準備リストを完了
ページ、計測、検索層、配信を配置——それぞれ検証、想定でなく。
当日を順序立てる
どの配信よりも先に公開と検証。広いチャネルより先に高親和セグメント。
3 シグナルを毎日読む
トラフィック・転換・増幅を別々に追跡、修正は正しい層へ。
得られるもの
1 か月のパッチ当てでなく初日に完全なローンチ
計測がトラフィックに先行したため信頼できる第 1 週データ
数日内に所有する層まで診断される問題
もはや記憶に依存しない再現可能な手順
よくある質問
チェックリストはどれくらい前から？
商品データと画像が揃えば、デジタル側の準備は週でなく日の単位です。長い柱はたいてい素材の質——それが着地すれば下流は並列で走れます。
新商品は全リストに告知すべき？
稀にしか。高親和セグメントが先：転換が良く、早期レビューがつき、広い露出の前のページの実地テストになります。ページが証明されてから広い配信を——順序は一斉配信に勝ります。
第 1 週が不発だったら？
何かを変える前に、3 シグナルのどれが失敗したか診断を。トラフィック弱く転換強いなら配信の修正、逆ならページの修正。全部一度に回すと、ローンチが対価を払って得た情報を壊します。
どのエージェントが実行？
1 つのブリーフからフルチームで：Builder がページ、Analyst が計測と第 1 週の解読、Visibility が検索層、Retention が順序立った配信。依存順は共有ワークフローが強制します——チェックリストが自走する理由です。