1. 重要成功要因（成功のための必要条件）
1.1. 顧客が自身にセグメントされた情報を望むこと
1.2. 顧客がTOPに検索以外の機能を求めていること
1.3. ABテストにより、上記などの顧客の意思が測れていること
1.3.1. 顧客が望むことであるという条件がそろっている場合、本PJは必要な投資となるはず
2. 目的（Purpose）
2.1. 検索レス
2.1.1. 商品選定プロセスの短縮
2.2. TOPを再検索起点とする
2.2.1. TOPへの再訪動機付け
2.2.2. 利便性の向上
2.3. 継続利用
2.3.1. 再購入
2.3.2. 売上の増加
3. 何をするか（What）
3.1. 顧客(属性)別に要素自体を出し分ける
3.1.1. バナーの位置
3.1.2. レコメンドの位置
3.1.3. 特集の位置 etc...
3.2. 顧客(属性)別に要素内のコンテンツを出し分ける
3.2.1. おすすめシリーズ
3.2.2. おすすめカテゴリ
3.2.3. セール etc...
3.3. 顧客最適化（UI/UX）
3.3.1. 上のそれらすべて
4. どうやってやるか（How）
4.1. 出し分けの考え方
4.1.1. 1.要素内のコンテンツを出し分ける
4.1.1.1. 会員属性の業種に応じて、自動的にTOPページのコンテンツの出し分けが可能
4.1.1.2. 会員属性の業種に応じて、手動でTOPページのコンテンツの出し分けが可能
4.1.2. 2.要素自体の出る位置やON/OFFを出し分ける
4.1.2.1. 会員属性の業種に応じて、自動的にTOPページのUIUXの変更が可能
4.1.2.2. 会員属性の業種に応じて、手動でTOPページのUIUXの変更が可能
4.1.3. 3.広告LPからのランディングで出し分ける
4.1.3.1. 特定のパラメータなどにより、該当の業種TOPへ遷移することが可能
4.1.4. 4.業種個別ABテスト
4.1.4.1. 業種別TOPで個別にABテストが可能
4.1.5. 5.業種別計測
4.1.5.1. 業種別TOPの基本指標（PV、UU）の集計
4.1.5.2. 業種別TOPのコンテンツCTRの集計
4.1.5.3. 業種別TOP経由のCVRの集計
4.1.5.3.1. 商品ページ遷移率
4.1.5.3.2. 型番生成率
4.1.5.3.3. 注文完了率
4.1.5.3.4. 受注金額
4.1.6. 得意先単位での制御は不要？
4.1.7. 対顧客 業種別TOP ON/OFF
4.2. 自動
4.2.1. 最終的なあるべき的立ち位置（恒久対応）
4.2.1.1. メリット
4.2.1.1.1. フロントとデータがそれぞれあるべき立ち位置で存在する理想的なアプリケーション
4.2.1.1.2. 運用負荷面で有利
4.2.1.1.3. ランニングコスト低
4.2.1.2. デメリット
4.2.1.2.1. イニシャルコスト高
4.2.1.2.2. 開発までの時間的デメリット
4.3. 手動
4.3.1. 段階的リリースの1段階目的立ち位置（暫定対応）
4.3.1.1. メリット
4.3.1.1.1. 開発にかかる時間的メリット
4.3.1.1.2. イニシャルコスト低
4.3.1.1.3. 手動でデータ整形をするため意図したデータを出せる
4.3.1.2. デメリット
4.3.1.2.1. 恒久対応する場合に無駄なアプリとなってしまう
4.3.1.2.2. 運用負荷面で不利
4.3.1.2.3. ランニングコスト高
4.3.1.3. optimizlyでやっていることを一部アプリに寄せる案とも言える
4.3.1.3.1. optimizlyではJSで顧客IDと業種のデータセットを取ってきて描画している
4.3.1.3.2. 逆に言うとoptimyzlyで実現できていることは理論上実現できる
4.4. 自動/手動ハイブリット
4.4.1. 一部でも手動でデータメンテをしたいという要望がある場合ハイブリット案になる
4.4.2. 自動で定義ファイル・データファイルを生成
4.4.2.1. マクロ
4.4.2.2. RPA
4.4.3. 手動でそのデータをいじって任意のデータに加工する
5. リスク（Risk）
5.1. 金
5.2. 開発期間
5.3. リソース
5.3.1. MSM運用リソース
5.3.2. IMJ開発リソース