Push通知・お知らせ・メールの
コミュニケーション戦略
マーケットプレイスのコミュニケーションは「送れば売れる」ではなく、需給のズレを小さくし、取引の不安を減らし、次の行動を自然に作るためのプロダクト機能として設計する。
対象: Growth PM / CRM / Product Marketing / Marketplace Ops
更新: 2026-05-21
0. 戦略の前提：コミュニケーションは「第3のマッチングエンジン」
マーケットプレイスのマッチングは、検索・推薦・価格だけで決まらない。ユーザーがアプリを開いていない時間に、どの情報を、どの順番で、どのチャネルで届けるかによって流動性は大きく変わる。
Demand側
探索の再開、価格・在庫変化、未完了予約、レビュー依頼、類似商品の発見を支援する。
Supply側
需要の発生、在庫・稼働の最適化、品質改善、売上報告、Champion維持を支援する。
Liquidity側
需給ギャップを検知し、片面だけでなく両面を同時に動かす。通知は価格・露出・在庫の補助線。
Trust側
取引確認、遅延、キャンセル、本人確認、規約変更など、不安を減らすコミュニケーションを優先する。
1. 通知分類：まず「送信理由」を5種類に分ける
| 分類 | 目的 | 主チャネル | 例 | 成功指標 |
|---|---|---|---|---|
| Transactional | 取引状態の伝達 | Push / メール / SMS | 予約確定、購入完了、発送、キャンセル | 未読率、問い合わせ削減、取引完了率 |
| Action Required | 次の必須行動を促す | Push / In-App | 本人確認、支払い失敗、承認待ち、レビュー依頼 | 期限内完了率、再通知率 |
| Opportunity | 需給チャンスを伝える | Push / メール | 需要急増、価格下落、お気に入り再入荷 | クリック後CVR、GMV増分 |
| Lifecycle | 状態遷移を作る | メール / In-App / Push | 初回出品、初回購入、休眠復帰、Champion化 | Activation率、Retention率 |
| Editorial | 学習・関係性を作る | メール / お知らせ | 売上Tips、季節需要、事例紹介、規約解説 | 開封、再訪、長期継続率 |
2. Push通知：即時性は「希少資源」として扱う
Pushは最も強いチャネルだが、最も壊れやすい。通知許諾を失うと復帰は難しいため、Pushは今すぐ見る価値があるものに限定する。
Push設計チェックリスト
- ユーザーがこの通知を受け取る理由を1文で説明できる
- 通知文だけで「何が起きたか」「次に何をするか」が分かる
- クリック先は通知文の約束と完全に一致している
- 同じ内容をメール・お知らせでも同日に重複配信していない
- 送信除外条件（購入済み、解決済み、在庫切れ、夜間、頻度超過）が定義されている
- Push許諾率・通知OFF率・アンインストール率を施策単位で見ている
3. お知らせ / In-App：ユーザーが「読む準備がある瞬間」に出す
お知らせとIn-Appは、Pushより弱いが文脈を合わせやすい。アプリ起動時・取引完了後・検索結果0件・出品完了前など、画面文脈に合わせることで自然に行動を促せる。
| 形式 | 向いている用途 | 避ける用途 | 設計ポイント |
|---|---|---|---|
| お知らせ一覧 | 規約変更、取引通知の履歴、キャンペーン詳細 | 即時対応が必要な通知 | カテゴリ、既読、重要ラベル、検索を用意 |
| 上部バナー | 軽いキャンペーン、障害告知、季節需要 | 個別性が高い取引通知 | 閉じられる、頻度制限、画面と関連させる |
| モーダル | 必須確認、重大変更、取引直後のレビュー依頼 | 一般告知、広告、連続表示 | ユーザーのタスクを遮る価値がある場合のみ |
| ツールチップ | 新機能、初回操作、Supply出品ガイド | 長文説明 | 一度見たら出さない。行動完了で消す |
お知らせテンプレート：規約/手数料変更
タイトル: 2026年X月X日から手数料体系を一部変更します
本文:
いつもご利用ありがとうございます。
対象カテゴリの取引手数料を X% から Y% に変更します。
対象: {対象ユーザー/カテゴリ}
変更日: {日付}
理由: {品質改善・決済コスト・サポート強化など、ユーザー便益に接続}
必要な対応: {必要なら明記。不要なら「対応は不要です」}
詳しく見る → {詳細ページ}4. メール：長文・教育・記録性を担う
メールはPushの代替ではない。メールは、ユーザーが後から読み返す価値のある情報、意思決定に説明が必要な情報、ライフサイクル育成に向いている。
メール件名の型
Supply:
- {カテゴリ} の需要が増えています。今週追加すると見られやすいです
- 先週の閲覧数は {views} 件。成約率を上げる3つの改善
- {item} に問い合わせが来ています。返信期限は本日中です
Demand:
- 保存した {item} が値下げされました
- {area/date} の空きが出ました
- 先週見ていた条件に近い新着が {count} 件あります5. オーケストレーション：チャネルを重ねず、順番を設計する
よくある失敗は「Push + メール + お知らせ + LINE」を同時に打つこと。短期のクリックは増えても、ユーザー単位の疲弊が蓄積する。基本は1メッセージ = 1主チャネル、反応がない場合だけ段階的にエスカレーションする。
| シナリオ | Day 0 | Day 1-2 | Day 3-7 | 停止条件 |
|---|---|---|---|---|
| 初回出品未完了 | In-Appガイド | メールで成功事例 | Pushで下書き再開 | 出品完了 / 退会 / 通知拒否 |
| 購入未完了 | Pushで在庫/期限 | メールで比較情報 | クーポンは最後 | 購入 / 在庫切れ / 価格変化なし |
| 需給ギャップ | SupplyへPush | Demandへ待ち時間説明 | 価格/露出調整 | マッチ率回復 / 供給充足 |
| 休眠復帰 | メール | 反応者のみPush | 最後に特典 | 再訪 / 配信停止 / 無反応継続 |
6. コピー設計：マーケットプレイス通知の文法
良い通知文は、短く、具体的で、次の行動が明確。抽象的な「おすすめがあります」ではなく、なぜ今見るべきかを入れる。
| 悪い例 | 改善例 | 理由 |
|---|---|---|
| おすすめ商品があります | 保存した条件に近い新着が3件あります | 個別性と件数がある |
| キャンペーン実施中 | 今日中の出品で手数料が半額になります | 期限と行動が明確 |
| ログインしてください | 下書き中の出品があと1分で公開できます | 復帰理由がある |
| 需要が増えています | 渋谷エリアで今夜の依頼が通常の1.8倍です | 場所・時間・根拠がある |
7. KPI / 実験：CTRだけで判断しない
通知施策はCTRが高く見えやすい。だが、マーケットプレイスでは「クリックしたか」より「取引品質が上がったか」「両面バランスが改善したか」を見る。
Primary
GMV増分初回取引率マッチ率再購入/再出品率
Channel
OpenCTRClick-to-CVRTime to action
Guardrail
通知OFFUnsubscribeUninstall問い合わせ増
Marketplace
Supply稼働率Demand充足率キャンセル率NPS
A/Bテスト設計
- 単位: 原則ユーザー単位でランダム化。取引単位だと同一ユーザーに複数条件が混ざる。
- 期間: 利用周期を最低1周分含める。フリマなら週末、宿泊なら曜日/季節性を考慮。
- 除外: トランザクショナル通知は安全上の理由で完全停止しない。文面・タイミング・チャネルだけ実験する。
- Holdout: CRM全体の純増効果を見るため、常時1〜5%の非配信ホールドアウトを置く。
8. 運用体制：誰が送れるかを制御する
通知基盤は、権限設計を間違えるとすぐにスパム製造機になる。Growth・CS・Ops・Marketing がそれぞれ送りたいものを持つため、ガバナンスが必要。
| レイヤー | 責任者 | ルール |
|---|---|---|
| Transactional | Product / Engineering | プロダクトイベントに紐づける。停止不可。文言レビュー必須。 |
| Lifecycle | Growth PM / CRM | シナリオ単位で承認。週次で成果と疲弊指標を確認。 |
| Campaign | Marketing | 頻度枠を予約制にする。全体カレンダーで衝突防止。 |
| Emergency | Ops / Trust & Safety | 障害・安全・規制のみ。送信後レビューを必須化。 |
9. 30日実装プレイブック
- Day 1-3: 既存通知を棚卸し。送信理由、対象、チャネル、頻度、KPI、停止条件を表にする。
- Day 4-7: Transactional / Action Required / Opportunity / Lifecycle / Editorial に分類し、不要なPushを停止。
- Day 8-12: ユーザー単位のフリークエンシーキャップと除外条件を実装。
- Day 13-17: Supply / Demand それぞれで最重要ライフサイクルシナリオを1本ずつ作る。
- Day 18-22: KPIダッシュボードを作る。CTRだけでなくGMV増分・通知OFF・Uninstallを並べる。
- Day 23-27: Holdout付きで初回A/Bテストを実施。文面ではなく「送信理由」単位で比較する。
- Day 28-30: 通知カレンダー・承認フロー・テンプレート集を整備し、運用を属人化から外す。