sales-in-app-messaging

アプリ内メッセージとコンテンツカード

アプリ内メッセージの活用を支援します。戦略やメッセージタイプの選定から、トリガーの設計、コンテンツカード、オンボーディングフロー、分析まで対応します。このスキルは特定のツールに依存しませんが、Braze、Iterable、Intercom、Pendo、Appcues、Customer.io、MoEngage、Whatfix、Chameleon 向けのプラットフォーム別のガイダンスも含まれています。

ステップ 1 — コンテキストを把握する

references/learnings.md が存在する場合は、蓄積された知識を確認するため、まず読んでください。

ユーザーに質問します。

1. どのようなサポートが必要ですか？

   • A) 戦略 — アプリ内メッセージプログラムの計画
   • B) オンボーディング — 新規ユーザー向けのウォークスルー、ツールチップ、機能ツアー
   • C) 機能のお知らせ — 既存ユーザーへの新機能の紹介
   • D) プロモーション — アプリ内オファー、アップセル、アップグレードの案内
   • E) アンケート／フィードバック — アプリ内でのユーザー意見の収集
   • F) コンテンツカード／受信トレイ — 常設コンテンツフィードの設計
   • G) ツールの選定 — アプリ内メッセージングプラットフォームの選択
   • H) トリガー — アプリ内メッセージを表示するタイミングと方法
   • I) 分析 — アプリ内メッセージの効果測定
   • J) その他 — 内容を説明してください

2. アプリの種類は何ですか？

   • A) モバイルアプリ（iOS／Android）
   • B) ウェブアプリ（SaaS）
   • C) モバイルとウェブの両方
   • D) E コマースアプリ
   • E) ゲーム

3. 使用している（または検討している）ツールは何ですか？

   • A) Braze
   • B) Iterable
   • C) Intercom
   • D) Pendo
   • E) Appcues
   • F) Customer.io
   • G) MoEngage
   • H) Whatfix
   • I) Chameleon
   • J) まだ決めていない
   • K) その他

ユーザーの依頼にこれらの情報の大半がすでに含まれている場合は、該当するステップに直接進んでください。 妥当な前提を明示したうえで、最善を尽くした回答を最初に提示し、最後に最も重要な確認質問を 1〜2 件だけ尋ねてください。

ステップ 2 — 戦略とアプローチ

アプリ内メッセージの種類

種類	最適な用途	表示方法	表示期間
モーダル	重要なお知らせ、権限のリクエスト、プロモーション	画面中央に表示し、操作をブロックします	閉じられるまで
スライドアップ／バナー	軽い通知、操作完了の確認	画面上部または下部に表示し、操作をブロックしません	自動的に閉じるか、スワイプするまで
全画面	重要なお知らせ、オンボーディングのステップ、アンケート	画面全体を覆います	閉じられるまで
ツールチップ／ホットスポット	機能の発見、状況に応じたヘルプ	特定の UI 要素を示します	閉じられるまで、または一定時間経過後
カルーセル／ツアー	複数ステップのオンボーディング、機能のウォークスルー	画面／モーダルを順番に表示します	完了するまで
コンテンツカード	常設のプロモーション、通知の受信トレイ、おすすめ	アプリ内の専用フィード／セクションに表示します	期限切れになるか、閉じられるまで
カスタム HTML	複雑なインタラクティブ体験、ミニゲーム、埋め込みフォーム	任意の場所に表示します	カスタム
アンケート	NPS、CSAT、機能リクエスト、フィードバック	モーダルまたは全画面で表示します	送信されるまで

アプリ内メッセージと他のチャネルの使い分け

シナリオ	最適なチャネル	理由
ユーザーが今まさにアプリを利用している	アプリ内メッセージ	即時性があり、状況に即していて、許可も不要です
ユーザーが数日間アプリを開いていない	プッシュ通知	アプリに戻るよう促せます
長文コンテンツやチュートリアル	メール	多くの情報を掲載でき、ユーザーは自分のペースで読めます
アクティブでないユーザーへの時間的制約のあるアラート	プッシュ通知 + SMS	アプリの外にいるユーザーにも届きます
ユーザーが後から再確認できる常設コンテンツ	コンテンツカード	ユーザーが反応するまでフィードに表示され続けます
ウェブ SaaS の機能のお知らせ	アプリ内メッセージ + メール	アクティブユーザーにはアプリ内で、その他のユーザーにはメールで届けられます

トリガー設計の原則

1. 時間ではなくコンテキストを基準にトリガーする — 単に「5秒後」ではなく、ユーザーが関連する画面や機能を利用しているときにメッセージを表示します
2. イベントベースのトリガー：セッション開始、特定画面の表示、カスタムイベント（購入の完了、機能の利用回数がX回に到達など）、マイルストーンへの到達
3. 行動条件：まだ機能Xを利用していないユーザー、無料プランのユーザー、登録から7日以上経過したユーザーにのみ表示します
4. 表示回数の制限：セッションごとに1回、生涯で1回、週に1回などに設定し、メッセージ疲れを防ぎます
5. 優先度とキュー：複数のメッセージが同時にトリガーされる可能性がある場合は、優先順位（オンボーディング > プロモーション > アンケート）を定義します

オンボーディングのベストプラクティス

1. 段階的な情報開示 — 初回セッションですべてを見せないでください。ユーザーが機能にたどり着いたときに紹介します。
2. ウォークスルーよりコンテキストに応じたツールチップ — 実際に使ってほしいUI要素を示すほうが、ユーザーがスキップする5画面のチュートリアルより効果的です。
3. 時間ではなくアクションをトリガーにする — 前のステップを完了したときに、次のオンボーディングステップを表示します。
4. スキップできるようにする — 常に閉じる／スキップする選択肢を用意します。強制的なウォークスルーは不満を招きます。
5. 完了状況を測定する — 「メッセージを見たか」だけでなく、各オンボーディングステップを完了したユーザー数を追跡します。
6. 空の状態 — 機能にまだデータがない場合は、空の状態をアプリ内メッセージとして活用し、次に行うことを説明します。

ステップ 3 — プラットフォーム固有のガイダンス

プラットフォーム固有のアプリ内メッセージングのガイダンス（Braze、Iterable、Intercom、Pendo、Appcues、Customer.io、MoEngage、Whatfix、Chameleon）については、references/platforms.md を読んでください。ユーザーが利用するツールに該当するセクションのみを使って回答してください。

ステップ 4 — 実行可能なガイダンス

実装チェックリスト

1. ユースケースを定義する — アプリ内メッセージングが価値をもたらすシナリオ（オンボーディング、機能の利用促進、プロモーション、アンケート）をすべて列挙します
2. メッセージの種類を選ぶ — 各ユースケースに適した形式（モーダル、ツールチップ、コンテンツカードなど）を割り当てます
3. トリガーを設計する — 各メッセージについて、表示するイベントや条件を定義します
4. 表示回数を制限する — 各メッセージの表示頻度（一度限り、セッションごとに1回など）を決めます
5. テンプレートを作成する — ツールのエディターで再利用可能なデザインを作成します
6. 優先度を定義する — 複数のメッセージがトリガーされる可能性がある場合、どのメッセージを優先するか決めます
7. テストする — 対象となるすべてのデバイス（iOS、Android、Web、ダークモード）でプレビューします
8. 小規模なセグメントで公開する — まずユーザーの10%に展開し、指標を確認します
9. 測定する — インプレッション率、クリック率、閉じる率、目標達成率を測定します
10. 改善を繰り返す — メッセージ、タイミング、デザインをA/Bテストします

主要指標

指標	ベンチマーク	分かること
インプレッション率	対象ユーザーの30-60%	トリガー設計の有効性
クリック／アクション率	15-30%	メッセージの関連性とCTAの品質
閉じる率	20-40%	メッセージの価値と煩わしさの度合い
オンボーディング完了率	40-70%	フロー設計とユーザーの動機
機能の利用率（メッセージ表示後）	10-25%増加	機能告知の効果
アンケート回答率	15-30%	アンケートの設計とタイミング

注意点

1. アプリの起動時にモーダルを表示しない — アプリを開いた瞬間に全画面モーダルが表示されると、強引な印象を与えます。意味のあるきっかけ（画面へのアクセス、アクションの完了、セッション数など）があるまで待ちましょう。例外：重要なお知らせ（利用規約の変更、必須アップデート）。
2. 複数のメッセージを重ねて表示しない — ユーザーがアプリ内メッセージを3つ同時に呼び出した場合は、最も優先度の高いものだけを表示します。ほとんどのツールにはキューや優先度の設定があるので、活用しましょう。複数のポップアップを同時に表示すると、すぐに閉じられてしまいます。
3. コンテンツカードはプッシュ通知ではありません — コンテンツカードはフィード内に受動的に表示されます。ユーザーがフィードを開かなければ、カードを見ることはありません。ユーザーの操作を中断する必要がある、時間制約のあるメッセージにはコンテンツカードを使わないでください。緊急性がある場合は、プッシュ通知またはアプリ内モーダルを使いましょう。
4. アプリ内メッセージはアプリが開いている必要があります — プッシュ通知やメールとは異なり、アプリ内メッセージが届くのは、すでにアプリを利用しているユーザーだけです。利用を休止しているユーザーには、アプリ内メッセージは役に立ちません。プッシュ通知で呼び戻してから、アプリ内メッセージでエンゲージメントを促しましょう。
5. Web SaaS のツールチップは UI の変更で機能しなくなります — 特定のボタンにツールチップを配置した後でページを再設計すると、ツールチップは何もない場所を指してしまいます。UI の変更を自動検出するビジュアルエディターを備えたツール（Pendo、Appcues など）を使うか、安定した CSS セレクターにツールチップを紐づけましょう。

• 自己改善：ここに記載されていないことを見つけた場合は、今日の日付を付けて references/learnings.md に追記してください。

特定のプラットフォームスキルを推奨する前に

このスキルは、複数のプラットフォームにまたがる戦略領域を扱います。特定のプラットフォームスキル（## Related skills に記載されている /sales-{platform}、例：/sales-mailshake、/sales-klaviyo、/sales-apollo）をユーザーに案内する前に、そのプラットフォームスキルの実際の SKILL.md を必ず読んでください。## Related skills の1行の説明は候補を特定するには十分ですが、それを確定することや、適切なプロンプトを書くことには不十分です。

読み方：

• ~/.claude/skills/{skill-name}/SKILL.md がローカルに存在する場合は、それを Read してください。
• sales-* スキルの場合は、このリポジトリから直接 WebFetch してください：https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md — 例：sales-mailshake の場合は、https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md。
• sales-* 以外のスキル（サードパーティ製）の場合は、インストールされていれば ~/.claude/skills/sales-do/references/skill-sources.md で {org}/{repo} を調べ、そのリポジトリ内の同じ skills/{skill-name}/SKILL.md パスから取得してください。

読んだ後は、 SKILL.md の具体的な内容（対象範囲、サブフロー、argument-hint の形式、「使用しないでください」という否定的な条件など）に基づいて推奨してください。生成する呼び出しは、プラットフォームスキルの argument-hint に合わせてください。プラットフォームスキルがユーザーの状況に合わない場合は、別のスキルに切り替えるか、不適切なものを推奨するのではなく、ここで直接質問に対応してください。

関連スキル

• /sales-chameleon — Chameleon プラットフォームのヘルプ（プロダクトツアー、ツールチップ、マイクロサーベイ、ランチャー、HelpBar、A/B テスト、AI）。インストール：npx skills add sales-skills/sales --skill sales-chameleon
• /sales-whatfix — Whatfix プラットフォームのヘルプ（エンタープライズ DAP、Flows、Smart Tips、Product Analytics、Mirror サンドボックス）。インストール：npx skills add sales-skills/sales --skill sales-whatfix
• /sales-pendo — Pendo プラットフォームのヘルプ（分析、ガイド、セッションリプレイ、NPS、API）。インストール：npx skills add sales-skills/sales --skill sales-pendo
• /sales-iterable — Iterable プラットフォームのヘルプ（アプリ内メッセージ、Mobile Inbox、Embedded Messages、Studio ジャーニー）
• /sales-braze — Braze プラットフォームのヘルプ（アプリ内メッセージ、Content Cards、Canvas 連携）
• /sales-customerio — Customer.io プラットフォームのヘルプ（Journeys 内のアプリ内メッセージ）
• /sales-push-notification — プッシュ通知の戦略（補完的なチャネル）
• /sales-email-marketing — メールマーケティングの戦略（アプリ内施策との連携）
• /sales-live-chat — ライブチャットとチャットボット（Intercom は両方を組み合わせています）
• /sales-do — どのスキルを使うべきかわからない場合は、ルーターがあらゆる営業目標に適したスキルを選びます。インストール：npx skills add sales-skills/sales --skill sales-do

例

例 1：SaaS のオンボーディングフローを設計する

ユーザーの発言：「当社は B2B SaaS アプリを提供していますが、アクティベーション率が低いです。新規ユーザーを案内するために、アプリ内メッセージをどのように活用すればよいですか？」 スキルの動作：段階的なオンボーディングフローを設計します。ステップ 1（初回ログイン）→ 3 ステップの概要を示すウェルカムモーダル。ステップ 2（ダッシュボードに到達）→ 主要機能を指し示すツールチップ。ステップ 3（初めて機能を使用）→ 成功を知らせるスライドアップと次のステップのツールチップ。完了状況を追跡できる、5 つのセットアップタスクを表示するチェックリストウィジェット。トリガー設計、表示ルール、完了指標も含まれます。 結果：状況に応じたツールチップ、チェックリスト、アクティベーション指標の追跡を備えたオンボーディングフロー

例 2：モバイルアプリ内でアップグレードを促進する

ユーザーの発言：「利用上限に達した無料ユーザーに、アップグレードの案内を表示するにはどうすればよいですか？」 スキルの動作：煩わしくないアップグレードフローを設計します。ユーザーが上限に達したときにトリガーし、有料プランで利用できる機能を説明するモーダルを表示します。アクションボタン（「アップグレード」は決済画面へのディープリンク、「後で」はモーダルを閉じる）。表示ルール：週に最大 1 回表示。A/B テスト：機能重視の文面と料金重視の文面を比較。代替案：3 回閉じられた後は、モーダルの代わりに控えめなバナーに切り替えます。 結果：A/B テスト、表示頻度の上限、段階的な対応方針を備えたアップグレード案内キャンペーン

例 3：Content Card の通知センターを構築する

ユーザーの発言：「Braze Content Cards を使って、アプリに通知受信箱を追加したいと考えています」 スキルの動作：Braze で Content Card キャンペーンを作成する手順を説明します。カードの種類（テキスト更新にはクラシック、プロモーションにはキャプション付き画像、お知らせにはバナー）、有効期限の設定、重要なカードのピン留め、セグメントのターゲティング、アプリ内にカスタム Content Card フィード UI を構築する方法を取り上げます。カードを既読または非表示にするための API 連携も含まれます。 結果：Braze Content Cards を活用した、カスタム UI 付きのブランド化された通知センター

トラブルシューティング

アプリ内メッセージが表示されない

症状：メッセージを設定したのに、ユーザーに表示されない 原因：トリガーイベントが発生していない、表示上限に達している、セグメントのターゲティングが狭すぎる、または SDK が初期化されていない 解決策：1）トリガーイベントが実際に発生していることを確認します（ツールのイベントログを確認してください）。2）表示上限を確認します。このユーザーにはすでにメッセージが表示されている可能性があります。3）ユーザーがターゲットセグメントに該当することを確認します。4）SDK が正しく初期化され、ユーザーが識別されていることを確認します。5）ご自身のデバイスでデバッグ／プレビューモードを使ってテストします。

アプリ内メッセージのクリック率が低い

症状：ユーザーはメッセージを見ても、CTA をタップしません。 原因：CTA の訴求力が弱い、メッセージが状況に合っていない、または CTA ボタンが十分に目立たない。 解決策：1) CTA を具体的で行動を促す内容にします（「詳細を見る」ではなく「無料トライアルを始める」）。2) メッセージが状況に合ったタイミングで表示されるようにします。3) ボタンを視覚的に目立たせます（コントラスト、サイズ）。4) コピー、ボタンのテキスト、メッセージのデザインを A/B テストします。5) コンテンツが軽めの場合は、モーダルではなくスライドアップを検討します。

ユーザーがメッセージをすぐに閉じる

症状：アプリ内メッセージの閉じる率が高い（>50%）。 原因：メッセージの表示タイミングが適切でない、押しつけがましい、または表示頻度が高すぎる。 解決策：1) トリガーのタイミングを見直します。メッセージがタスクを中断していませんか？ 2) より押しつけがましくない形式（スライドアップと全画面表示など）を検討します。3) 表示頻度を下げます。4) メッセージに価値があるか確認します。ユーザーの役に立っていますか、それとも何かを宣伝しているだけですか？ 5) 閉じるだけでなく、「後で通知する」オプションを追加します。