Marketing Cloud Engagement (MCE) MobilePush の受信トレイ メッセージ (Inbox Messages) とプッシュ通知の技術的な差異について解説します。メッセージ配信の仕組み、DeviceID との関連性など、実装や分析時に重要となるポイントをまとめています。
受信トレイメッセージは、一般的なプッシュ通知 (アラート (Alert)) とは異なり、モバイルアプリ側から MCE に問い合わせてメッセージをダウンロードする仕組みです。そのため、ユーザーがOSの通知を許可していなくてもメッセージを届けることが可能です。このほかにも挙動が異なる点がいくつかあり、利用に際してはその挙動について把握することが重要です。
プッシュ通知
MCE からメッセージプロバイダー (FCM/APNs) に対し、リモート通知をリクエストする。(各OSが持つ通知の仕組みを使います)
ユーザーがアプリの通知を許可していない場合、デバイスには表示されない。
受信トレイメッセージ
アプリがフォアグラウンドで起動した際や、明示的にメッセージの更新を行う SDK の提供するメソッドを実行した際などに、アプリから MCE に対してメッセージを要求し、ダウンロードする。
MCE からデバイスへ「送信」はせず、メッセージをダウンロード可能な状態にする。各デバイスはアプリ起動時や明示的に要求するメソッドを実行した際に時デバイスにダウンロード可能なメッセージを取得する。
各OSが持つ通知の仕組みを利用しないため、ユーザーの通知許諾設定に左右されない。(つまりオプトアウトのデバイスでもダウンロードされる)
アラート + 受信トレイメッセージ
プッシュ通知を送信し、同時に受信トレイメッセージをダウンロード可能な状態にする。(非同期)
通知を許可していないデバイスにはプッシュ通知は送信されず、受信トレイメッセージのみが対象となる。
"プッシュメッセージの詳細(抽出)レポート (MobilePush Detail Extract Report)"では、メッセージタイプによってレコードが記録される内容や、レコードが出現するタイミングが異なります。下記の点に注意してください。
受信トレイメッセージのみの場合
対象デバイスがメッセージをダウンロードした時点で、初めてレポートにレコードとして記録される。
例えば、10デバイスを対象とし、3デバイスがダウンロードした場合、レポートには3レコードのみが出力される。
プッシュ通知関連の項目(例: Status)は空白となる。
アラート + 受信トレイメッセージの場合
通知を許可しているデバイス: プッシュ通知が送信された時点でプッシュ通知関連のレコードが記録される。
通知を許可していないデバイス: 受信トレイメッセージがダウンロードされた時点でレコードが記録される。(受信トレイメッセージのみの場合と同様)
特に後者の "アラート + 受信トレイメッセージ" については、2 つの異なる仕組みのメッセージで 1 レコードが構成されるため、レコードのデータも上記 2 つの特徴が混在しており、特に DetaTimeSendの項目については注意が必要です。詳細は下記をご参照ください。
MobilePush Detail Extract Report (MobilePush 詳細抽出レポート) の DateTimeSend について
Q1. アプリを再インストールして DeviceID が変わった場合、以前の受信トレイメッセージは表示されますか。
いいえ、表示されません。受信トレイメッセージは DeviceID に紐づくため、DeviceID が変更されると以前のメッセージの取得対象外となります。
Q2.アプリで別アカウント (別の連絡先キー) を設定したり、ログアウト状態に戻しても、受信トレイのメッセージ一覧が変わりません。
想定される動作です。受信トレイメッセージは DeviceID に紐づくため、連絡先キーに関係なく常に同一のメッセージが表示されます。
また、SDK や MCE の機能ではログインユーザーの切り替えを考慮したメッセージの切り替えは本記事記載時点では対応しておりません。
モバイルアプリケーションでメッセージをハンドリングする等独自の実装が必要になります。
例:
============
・ContactKey=001 でログインする
・(MCE) ContactKey001 に対してメッセージAを配信
・ContactKey=999 でログイン
・(MCE) ContactKey999 に対してメッセージBを配信
・(MCE) ContactKey001 に対してメッセージ C をDL可能な状態にする
・ContactKey=001 で再ログイン
・ログアウトしアノニマスになる
============
上記例のデバイスでは、どの連絡先キーでログインしても、あるいはログアウトしてアノニマスに戻っても、常にメッセージ A,B がダウンロードされます。
メッセージCはダウンロード対象にはなりません。理由はメッセージ C 配信時に、当該デバイスの Contactkey が 999 であったため、メッセージCの対象にならなかったためです。この点がEmailなどとは異なる点であり、誤解を招きやすい点のためご留意ください。
Q3.カスタムキーに連絡先キーのパーソナライズ文字列 %%_subscriberkey%% を設定すれば、連絡先キーに基づいたメッセージの出し分けは可能ですか。
いいえ、できません。メッセージ配信時の値が保持されないためです。
受信トレイメッセージは、ダウンロード時に都度パーソナライズ文字列やAMPscript/SSJS がレンダリングされます。そのため %%_subscriberkey%% も都度 "現在の連絡先キー" が設定されます。このため返す値は全メッセージですべて同じ連絡先キーになります。
連絡先キーに基づいた出し分けは、要件に応じたAMPscript/SSJSならびにアプリ側でのフィルタリングなどを組み合わせて検討・検証する必要があり、高度なカスタマイズが必要となるため、サポートケースではこの実装サンプルなどはお伝えしておりません。
Q4.「受信トレイ + プッシュ通知」を送信後、通知をタップしてすぐにアプリを開くと、最新の受信トレイメッセージが表示されていませんでした。
プッシュ通知の送信と、受信トレイメッセージのMCE上での準備は、それぞれ非同期で処理されます。
そのため、通知が届いたタイミングで、アプリが受信トレイメッセージをダウンロード可能になっていない場合があります。
また仮にダウンロード可能な状態となっていたとしても、特に通知をタップした遷移先としてアプリの受信トレイメッセージ一覧画面が設定されていると、アプリ側で当該画面の描画時点で、最新メッセージがまだダウンロードされていない状態になり、このような状況に陥る場合があります。
なお、この事象はテスト時など、ユーザーが通知到着直後すぐに操作した場合に発生する可能性が高くなります。通常の利用では、通知の確認・起動に自然な時間差が生じるため、受信トレイメッセージの準備を完了する十分な時間を確保でき、大多数においては問題となりません。
Q5.アプリ上での受信トレイメッセージの表示やデザインなどのご質問について
アプリ上での表示、たとえば下記などは SDK の提供する API ではなく、当該モバイルアプリのプログラム上で制御します。よってこれらはアプリ開発者とご相談ください。
・各項目のデザインや表示形式
・メッセージの表示ソート表示順序の指定 など
Q6. JourneyBuilder やAutomation Studioで受信トレイメッセージを送信したいが、メッセージをどこで作成すればいいですか
これらで送信するメッセージはMobile Studio の画面で、それぞれの種別でのメッセージを作成します。具体的には以下の通りです。
[手順]
1. `Mobile Studio` > `MobilePush` に移動し、「メッセージを作成」をクリックします。
2. テンプレート選択画面で「受信トレイ」テンプレートを選択します。
3. 「送信方法」で JourneyBuilderなら「インタラクション」、Automation Studioなら 「Inbox - Automation」 を選択して作成します。
Q7. Inbox のリフレッシュを繰り返すと、最新のメッセージが取得できない場合があります
パフォーマンスの観点から、Inbox のリフレッシュは 1 分間に 1 度までに制限されています。
時間をおいて再度お試しください。
Q8. Inboxメッセージごとにダウンロードが可能な対象デバイスの一覧を確認する方法はありますか
デバイスあるいは連絡先単位で対象者を見ることはできません。
ダウンロードの対象の"デバイス数"は、以下より確認ができます(API/Journey Builderは覗く)
・MobilePushの管理画面に遷移します
・送信 (Sends) タブをクリックし、該当のジョブの日付をカレンダーから選択します
・[View Details] ボタンをクリックし、送信可能オーディエンス [SENDABLE AUDIENCE]の数を確認します。
この数字が、対象のジョブにおけるダウンロードが可能な対象デバイス数を指します(Push通知のジョブの場合はPush通知の送信デバイス数)
005132588

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.