アプリ内メッセージはどう機能しますか？
仕事をするのはプロダクトに組み込んだSDKです。メッセージはトリガー条件（特定のイベント、ページの閲覧、セグメントへの所属）と照合され、条件を満たすとインターフェースに直接表示されます。配信はすでに動いているコードに乗るため、許可を求めるプロンプトも購読もありません。プロダクトを利用中の人なら誰にでも表示できます。Brazeのようなツールは、セッション開始時に対象となるメッセージを端末に同期し、実際に何を表示するかは配信ルールとフリークエンシーキャップで決めます。
アプリ内メッセージとWebプッシュの違いは？
Webプッシュ通知は、ブラウザーの通知機能を通じて、サイトの外にいるユーザーにも届きます。ただし、明示的な許可が必要で、多くのユーザーはそれを拒否します。アプリ内メッセージはその鏡像です。許可は不要ですが、ユーザーが離れると届きません。2つのチャネルは互いの死角を補います。Webプッシュは人を呼び戻し、アプリ内メッセージは戻ってきた人を案内します。両者を1つの施策として運用する方法は、Webプッシュとアプリ内メッセージのガイドで解説しています。
アプリ内メッセージはいつ使うべきですか？
届けたい相手がすでにプロダクトの中にいるときです。オンボーディングのチェックリスト、新機能のお知らせ、アップグレードの案内、文脈に沿ったヒント、短いアンケートなど。アプリ内メッセージは、より広いカスタマージャーニーのステップとしてもよく機能します。たとえば、ダッシュボードまで来たのにプロジェクトを一度も作成していないユーザーにだけ表示するツールチップです。肝心なのはターゲティングです。全員に表示されるメッセージは、ただのUIにすぎません。
アプリ内メッセージの限界は？
- 到達範囲がセッションに縛られる：解約したユーザーや休眠中のユーザーの目には決して触れません。掘り起こしはメール、SMS、プッシュ通知の役目です。
- 注意を奪うコスト：間の悪いモーダルは実際の作業を妨げます。基本はバナーとツールチップにし、メッセージにそれだけの価値があるときだけ強い形式にします。
- 表示のリスク：コンテンツが稼働中のページに挿入されるため、プラットフォームはメッセージのHTMLをサニタイズする必要があります。XSS対策を施した表示は、機能ではなく必須要件です。
- アーカイブがない：閉じたメッセージは消えます。ユーザーがあとで必要としそうな内容は、メールやドキュメントにも載せておくべきです。