Loading
ただいま大変多くのお問い合わせをいただいており、ご連絡までにお時間を頂戴しております続きを読む

Marketing Cloud Engagement | MobilePush SDK 8系以前と9系以降における受信トレイメッセージの主な違いおよび考慮事項

公開日: Jul 9, 2026
説明

MobilePush SDK 9系以降では、受信トレイ(Inbox)メッセージの取得方式やメッセージのプロパティが8系以前から変更されています。これからSDKを8系以前から9系以降にアップデートする際は、本記事に記載の動作特性や変更点に留意してください。

解決策

1.メッセージ取得方式の変更

主な違いとして、SDK 9系以降ではメッセージの差分取得を行います。SDKは前回取得したメッセージ群に関するタイムスタンプを保持し、次回のメッセージ取得リクエスト時には、その値以降に更新されたメッセージのみを取得します。
一方、SDK 8系以前では、対象デバイスに紐づくアクティブな受信トレイメッセージをすべて再ダウンロードする方式です。
SDK 9系以降の差分取得方式により、以降のセクションで解説するパーソナライズへの影響が発生します。


2.取得方式の変更に伴うパーソナライズへの影響

受信トレイメッセージにおけるAMPScriptやパーソナライズ文字列の評価は、SDKがメッセージをダウンロードするタイミングで行われます。つまり対象デバイスでアプリを起動したタイミングや、メッセージのリフレッシュを要求 (refreshInbox/refreshMessagesの実行) したタイミングで評価・展開されます。

ここで、SDK 9系以降では差分のメッセージを取得するため、すでにダウンロード済みのメッセージに対してはAMPScript やパーソナライズ文字列が再評価されません。一度ダウンロードした後は、Marketing Cloud Engagement側でコンテンツやData Extensionのデータを更新しても、端末上では初回受信時に評価された値が表示され続けます。(※ただし下記の「タイムスタンプ境界のメッセージ再取得について」の例外動作も確認してください。)

SDK 8系以前では、受信トレイメッセージを常にすべて再ダウンロードするため、ダウンロードのたびに全てのメッセージでAMPScriptやパーソナライズ文字列が再評価されていました。よって Data Extension等のデータが更新された場合、次回ダウンロード時にすべてのメッセージの参照値が最新のデータに基づいて再度評価されます。


SDK 9系以降の差分を取得する方式では、メッセージダウンロード時点のデータを保持しやすい反面、Data ExtensionなどMCE上のデータに基づいて動的にコンテンツを変化させるユースケースでは、8系以前と異なるデータ管理が必要になる場合があります。
そのため8系以前において、この都度全メッセージが評価される挙動に基づいて行われていたパーソナライズを行っている場合は、9系への移行において、該当するユースケースが9系以降でも期待どおりに機能するかを検証・評価することを推奨します。

 

注意:タイムスタンプ境界のメッセージ再取得について

SDK 9 系では差分のみを取得しますが、具体的には端末側で保持する基準のタイムスタンプ以降のメッセージのみを取得・再評価します。

この基準タイムスタンプには「前回取得時点で最新のメッセージを基準にしたタイムスタンプ」が設定されます。そして次回以降はタイムスタンプ "以降の" メッセージが取得されます。つまり最新のメッセージ自身が毎回取得対象に含まれます。

この結果、次の挙動になります。

  1. 新着の受信トレイメッセージがない場合でも、最新の1通だけは取得のたびに毎回 AMPScript などが再評価され、その時点のデータで書き換わる。それ以前のメッセージは最後の評価時の内容のまま固定される。
  2. 新着メッセージが追加されると、「直前まで最新だった1通 + 未取得の新着分」がまとめて取得され、これらすべてが AMPScript 再評価される。
  3. その後、基準タイムスタンプは新しい最新メッセージに移動し、以降はその1通が毎回再評価される。

 

例) 下記の通り、10:45 のメッセージダウンロードを最後にメッセージ A はそれ以降ダウンロード対象にはならず、AMPScriptの再評価などもされません。

時刻イベントダウンロード対象のメッセージ
10:00メッセージ A のジョブ完了A
10:05アプリ起動/メッセージダウンロードA (AMPScript評価)
10:10アプリ起動/メッセージダウンロードA (AMPScript評価)
10:30メッセージ B のジョブ完了A, B
10:45アプリ起動/メッセージダウンロードA, B(AMPScript評価)
10:50アプリ起動/メッセージダウンロード

B (AMPScript評価)

*これ以降は Aがダウンロード対象でなくなり、Bが毎度ダウンロード対象となる。

 


3. Inbox 2.0で追加された新機能とアプリでの考慮点

SDK 9系以降で利用可能なInbox 2.0では、主に以下の3点が追加されています。
これらの変更、および Inbox 1.0 を利用する場合も踏まえて、アプリ側で実装の見直しが必要になる場合があります。
 
  • CloudPage CTAの任意化: Inbox 1.0では必須だったCloudPage CTAが必須ではなくなり、CTAなし/CloudPage/Web URL/App URLから選択可能です。
  • サブタイトル、本文などのプロパティ:件名以外にも利用できるプロパティが用意されました。
  • Push Copy to Inbox(PCTI): Push通知のコンテンツを受信トレイメッセージとしても受信できます。
 
受信トレイ機能においてSDKはデータの受け渡しのみを担当し、アプリ画面の描画・デザイン・タップ時の遷移処理はアプリ側の実装に依存します。受信したデータのどのプロパティをどのUI要素に使用するかや、タップ時の挙動はアプリ開発者側で設計・実装する必要があります。またCTA種別(Web URL、App URL、CloudPage)ごとにタップ時の遷移や挙動はアプリ側で定義します。このようにアプリ側でハンドルする点が多いため、各パターンを想定したアプリの実装とテストを行い、実装の検討をします。
 
 
参考ドキュメント:

 

よくある質問

Q1. 受信トレイメッセージや Push Copy To Inbox の件名等のデータが画面上に正しく表示されない・空白になる
A. まずアプリ側でデバッグし、SDKが受信したデータの各プロパティ値とUIへのマッピングを確認してください。SDK 9系以降はプロパティが以前と異なります。ログが出ない場合はロギングの有効化を検討してください。MCEから渡されるデータが想定と異なるなど、MCEに起因する問題が疑われる場合は詳細を添えてお問い合わせください。
参考:Troubleshoot Android / iOS
 
Q2. サンプルコードはあるか
A. サポートケース内では、あいにくコードの提供は行っておりません。Learning Appや公式ドキュメントを参考にしてください。
参考:Inbox Messaging / Learning App Android / iOS
 

Q3. 受信トレイメッセージをタップした際に、ターゲットの URL への遷移が想定した動作にならない(例:WebView やブラウザが開かない、ディープリンクが想定通り動作しない等)
A. まずはアプリをデバッグし、タップ時の遷移の処理やその際にアプリ側で遷移しようとしている URL を確認します。
これらの挙動は多くの場合アプリ側の実装に依存します。受信トレイメッセージに含まれる URL 情報をどのように処理するか(WebView で開く、外部ブラウザで開く、ディープリンクとして処理する等)はアプリ側の実装で決定されるためです。そのため、本事象が見られたらまずはアプリ開発チームへのデバッグ依頼を最初のステップとして推奨します。その上で、Marketing Cloud Engagement が送信するデータや SDK が扱うデータの内容に誤りがある、または不明瞭な点がある場合は、切り分けやデバッグ内容の詳細を添えて Salesforce サポートへお問い合わせください。

 

*上記挙動は本記事作成時点です。SDK の挙動はバージョンによって異なる場合があります。

ナレッジ記事番号

005387380

 
読み込み中
Salesforce Help | Article