1 サマリー
マーケティングデータから、プロダクト改善の明確な機会が見えています。
APP CVR
1.22%
View Home → Complete Booking
WEB CVR
0.18%
View Tour Detail → Complete Booking
Key Insight
7倍のCVR差は、マーケティングの問題ではなくプロダクトUXの問題。
Webを経由してTOMOGO!を理解してからインストールしたユーザーは、アプリ内で5-7倍高いCVRを示す。「知っている状態」で入ってくるかどうかが、全てを決めている。
2 APP: オンボーディングが最大のボトルネック
データ
| 指標 |
Direct Install |
WEB Conv → Install |
差 |
| AppContentView / Install |
96-127% |
568-760% |
5-7x |
| AppSearch / Install |
56-60% |
239-320% |
4-5x |
Insight
広告から直接インストールしたユーザーは、TOMOGO!が何を提供するのか理解していない。
最小限の閲覧(インストール1件あたりツアー表示1回)で離脱する。
一方、Webサイト経由のユーザーはバリュープロポジションを理解しており、
意図的にインストールし、積極的にブラウジング(インストール1件あたりツアー表示6-8回)する。
ユーザーフローの比較
Direct Install(現状の大多数):
広告クリック
→
Install
→
「何これ?」
→
離脱
WEB Conv → Install(理想フロー):
広告クリック
→
Web閲覧
→
価値理解
→
Install
→
積極利用
Recommendation
- アプリのオンボーディングフローで、Webサイトが果たしている役割を再現する:TOMOGO!のユニークな価値(ローカルガイド、穴場スポット、カスタマイズ可能なツアー)を紹介
- 初回起動時の体験に含めるべき要素:人気ツアー、ツアーリーダーのプロフィール、レビュー/口コミ
- 46-51%のユーザーがアカウント作成後0-1日以内に予約 → 初回セッションが全て
- 新規インストールから24時間以内に、パーソナライズされたツアー推薦のプッシュ通知を送信
3 APP: Tour Leader選択ループの解消
データ
r = -0.82
Meta CartAdd と予約数の相関
Problem
確認画面到達数が多い期間ほど、実際の予約が少ない(相関 r = -0.82)。
原因:ユーザーが確認画面 → Tour Leader選択 → TL詳細ページ → 戻る → 別のTLを試す → 繰り返し…という決定麻痺ループに陥っている。
現在のフロー(問題)
ツアー詳細
→
Book Now
→
確認画面
TL選択あり
→
TL比較ループ
→
離脱
改善後のフロー(提案)
ツアー詳細
TLプロフ表示
→
TL決定済
→
Book Now
→
確認画面
TL確定表示のみ
→
予約完了
Recommendation(開発チーム既存計画と整合)
- Tour Leader選択/プレビューをチェックアウトフローの前に移動(確認画面内ではなく)
- ツアー詳細ページにTLプロフィールを表示し、「Book Now」クリック前にTLを決定できるようにする
- 確認画面では、割り当て済みTLの簡易プロフィールのみ表示(選択UIは不要)
4 WEB: ファネル91%離脱の改善
Webファネルデータ(Amplitude 4/10-4/26)
541 UU
View Tour Detail Page
48 UU
Complete Checkout Date Time
91.1% drop
1 UU
Complete Booking
CVR 0.18%
APP vs WEB ファネル比較
APP
1.22%
1,807 UU → 22 Booking
WEB
0.18%
541 UU → 1 Booking
セッションリプレイから判明した行動パターン
| 行動 |
割合 |
示唆 |
| 別のツアー詳細に遷移(比較疲れ) |
58.6% |
関連ツアー提案がない |
| 外部トラフィック(ブラウズに戻れない) |
37% |
回遊導線の欠如 |
| Auth Dialog 完了率 |
10% |
認証が大きな障壁 |
Recommendation(優先度順)
- ツアー詳細ページに「関連ツアー」セクション(同エリア3-5件)を追加 — 開発チーム分析でも最優先事項
- ゲストチェックアウトの実装(4/27MTGで確認済み)— Auth Dialogの完了率10%が致命的
- リピーター向け「最近見たツアー」セクションの追加
- カレンダー読み込み速度の改善(機能的な問題)
- アプリダウンロードバナーをセッション内で1回非表示にしたら以降抑制
5 WEB: WEB経由Installの価値を最大化
データ
685%
WEB Conv → Install の AppCV率
96%
Direct Install の AppCV率
4.6件/日
WEB Purchase発生日の平均予約数
Insight
Webサイトは「教育レイヤー」として機能している。
Webサイトを閲覧してからインストールするユーザーは、事前に価値を理解しており、圧倒的に高いCVRを示す。サイトの役割は直接コンバージョンだけではなく、
高品質なアプリユーザーの創出にある。
Recommendation
- 全ツアー詳細ページに「アプリをダウンロード」CTAを目立つ位置に配置(ただし非表示操作後は抑制)
- 「このツアーを保存」機能の検討 — Webからアプリへのディープリンク(特定ツアーに直接遷移)
- Web → Install → Booking の一連のジャーニーを重要ファネル指標として追跡
- Webのツアー詳細ページは「チェックアウト完了」ではなく「価値理解」に最適化 — 真のコンバージョンはアプリで起きる
6 コンテンツ: 回遊性改善の設計指針
コンテンツパフォーマンスデータ
| ツアー / カテゴリ |
特徴 |
プロダクトへの示唆 |
| Secret Tokyo |
閲覧数・予約数ともに1位 |
アンカーコンテンツとして全面に配置 |
| Omakase(カスタマイズ) |
高需要期に最もスケール |
パーソナライゼーション機能の拡充 |
| Asakusa |
全月で安定的にパフォーマンス |
エバーグリーンコンテンツとして常時表示 |
| Bar Hopping |
男性エンゲージメント・既存ユーザー再活性化が高い |
リテンション施策のフック |
WEB・APP共通のコンテンツ優先順位
- Secret Tokyo / Omakaseをトップに目立つ形で配置
- Tour Leaderプロフィールの露出を強化 — TL前面のコンテンツはCVRが高い(例: Yanaka Ad 74%女性、Rin 2 Ad 63.8%女性)
- エリアベースのブラウジング(同エリアの関連ツアー表示)— ユーザー行動(58.6%が別ツアーへ遷移)と一致
- 「ローカルインサイダー」テーマのコンテンツ — SNS分析で7-14日後の予約に寄与
6b クーポンUX改善 — First Bookingの75.7%がクーポン未利用
First Bookingの75.7%(305/403件)がクーポンなしで予約。ebr20クーポンはアプリ内チャット(Admin→Guestメッセージ)で配布されるが、ユーザーがチャットboxを開かない限り存在に気づかない。
クーポン配布チャネルの現状と課題
| チャネル | 配布方法 | 利用率 | 課題 |
| ebr20 | Install時にアプリ内チャット(Adminメッセージ)で自動送信 | First BKの9.2% | チャットを開く動機がない。見落とし率90%超 |
| WEL20 | CA後のWELCOMEメールで配信 | First BKの2.5% | CA導線変更でメール配信数82%減 |
改善提案
| # | 改善ポイント | 現状 | 推奨 |
| 1 | クーポンの可視性向上 | チャットbox内にのみ存在 | プロフィール/マイページに「未使用クーポン」セクション常時表示。ホーム画面にバッジ表示 |
| 2 | 予約フロー内の自動適用 | クーポンコード手入力が必要 | 未使用クーポンがある場合、チェックアウト画面に「20%OFFを適用する」ワンタップボタンを表示 |
| 3 | LP/WEBサイトでのクーポン訴求 | WEBサイトにクーポン情報なし | ツアー詳細ページに「アプリで初回20%OFF」バナー。Install促進とクーポン認知を両立 |
| 4 | Push通知でのリマインド | MoEngageではクーポン訴求なし | 「初回クーポンのお知らせ」Push(CVR 14.3%)の配信対象を拡大。Install後3日/7日にリマインド |
| 5 | カート放棄Pushの強化 | 月4件配信。CVR 25.0% | 配信条件を緩和してボリューム拡大。最高効率のPush施策 |
MoEngage Push通知はCVR 2.5倍(9.1% vs 全体3.6%)と効果的だが、月5件のBookingとボリュームが不足。行動トリガー型Push(カート放棄CVR 25%、初回クーポン通知CVR 14.3%)の配信条件緩和が最もROIの高い改善施策。MoEngageはリエンゲージメント専用でクーポン配布には使われていないが、クーポンリマインドをPush通知に追加する余地がある。
7 データ計測の改善提案
現在のギャップ
| 課題 |
影響 |
ステータス |
| UTMトラッキングが1/16以降壊れている |
AppsFlyerOneLink × Amplitudeマッピング不完全 |
対応中(大型案件) |
| Wix LP → メインサイトのトラフィック未追跡 |
Web流入の全体像が見えない |
未着手 |
| Amplitudeにアプリユーザーの性別データなし |
「女性が発見→男性が予約」仮説の検証不可 |
未着手 |
| Webファネルデータは4/10以降のみ |
信頼性のある分析には30日以上必要 |
データ蓄積中 |
改善優先順位
- UTMマッピングの修正(宮西チーム — 大型プロジェクト、進行中)
- Amplitudeユーザープロフィールに性別プロパティを追加
- クロスプラットフォームジャーニー追跡の実装(Webセッション → App Install → App Booking)
- 週次自動ファネルレポートの設定(Web + App 並列表示)