MobilePush 利用にあたり、よくお問い合わせいただくポイントについて整理します。
本記事は主に Push 通知に着眼していますが、受信トレイメッセージ(Inbox Message) に関しては下記の関連記事をご参照ください。
アウトバウンドの プッシュ通知 (Push Notification) を送信するとき、指定したリストまたはデータエクステンション上の連絡先に紐づく「送信対象アプリの全オプトインデバイス」へ送信が試みられます。
そのため、送信件数はリストやデータエクステンション上の連絡先の件数を上回るもしくは下回ることがほとんどです。送信タブなどから確認した送信件数とリスト上の件数が合致しない旨の問い合わせをいただくことが多いため、この点に注意してください。
1 つの連絡先が複数のデバイスを利用することは珍しくなく、その場合にはリスト件数を上回る送信数が記録されます。一方で、オプトアウト済みデバイスが多い場合や、当該の連絡先が送信対象アプリのものでない場合、これらのデバイスには送信されないためリスト件数を下回ることがあります。
参考情報: プッシュ通知の受信者
個別のデバイスへの送信結果の確認には、データ抽出アクティビティ: MobilePush Detail Extract レポートの利用を推奨します。
またこの点について詳細を補足した記事がありますので、送信結果を精査する必要がある場合は、下記も併せてご参照ください。
参考情報 : MobilePush Detail Extract Report (MobilePush 詳細抽出レポート) を活用したプッシュ通知送信結果の切り分け方法について
下記参考情報の URL のとおりに連絡先キーを明示的に指定するメソッド (setProfileID/sfmc_setcontactKey) ※ を実装します。このとき指定する連絡先キーを Email Studio など既存のチャネルの連絡先キーの体系と合わせることで、MobilePush の連絡先を既存チャネルの連絡先と統合することができます。
例えば、Email Studio で会員番号を連絡先キーに利用されている場合、アプリ側からも (ログイン時などに上記メソッドを通して) 会員番号を入力してもらい、連絡先キーとして Marketing Cloud 側に送信することで、Email の連絡先と MobilePush の連絡先が紐づきます。
連絡先キーが統合できれば、当該ユーザーに対して複数チャネルからのメッセージ送信や開封などのデータを統合可能となりますので、One to One のマーケティングに近づけることができます。
なお、上記メソッドの代表的な実行タイミングがログイン時であるため、ログイン有無による挙動の違いを問い合わせいただくことがありますが、Marketing Cloud および MobilePush SDK には連絡先のログイン/ログアウトの概念がなく、挙動の違いはありません。またアプリのログイン処理にあわせて SDK が自動で上記メソッドなどを実行することはなく 、明示的に実装する必要があります。このため、ログイン有無による挙動を変更したい場合には要件に応じて個別の実装を行う必要があります。
参考情報:
※ setProfileID/sfmc_setcontactKey を呼称として setContactkey と呼ぶ場合があります。
アプリ側で連絡先キーを送信しない場合、デフォルトの SDK の挙動では、初期化後に Marketing Cloud Engagement に GUID 形式の連絡先キーが登録されます (連絡先とデバイス) 。 そのため、後日連絡先キーがモバイルアプリから Marketing Cloud に送信されてきた場合、初期時に作成された GUID 形式の連絡先キーはどのチャネルにも紐づかない連絡先として残ることになります。
このような GUID 形式の連絡先キーを保有することを避けたい場合、「チャネルアドレスを持たない連絡先」のデータ抽出で対象者を抽出して定期的に削除するか、あるいは Delay Registration が利用できます。Delay Registration を用いれば、モバイルアプリ側からログインなどの後に setContactKey で連絡先キーが送信されない限り、連絡先として登録されません。しかし同時に setContactKey で連絡先キーが送信されない限りメッセージを送信できないことも意味します。ゆえに匿名デバイスにもメッセージを送信したい場合には採用はできません。
参考情報:
Delay Registrationについては下記をご参考ください
Contact Dissociation
また連絡先キー体系の検討については下記が有益となりますので、併せてこちらをご参考ください。
Register Contacts with Marketing Cloud Engagement
setContactKey は指定した連絡先キーがすでに存在した場合は当該の連絡先に紐づき、存在しなければ新規の連絡先として生成されます。連絡先キーの「更新」を行うものではないことにご注意ください。例えば 1 デバイスから setContactKey をそれぞれ別の新規連絡先キーにて 10 回行った場合、10 の新規連絡先が生成されることになります。
1 つの連絡先に対して紐づけるデバイス数に上限はありませんが、不特定多数のデバイスを 1 つの連絡先に登録する実装は推奨されません。お問い合わせでは、ユーザーが特定できていないアノニマスな状態のデバイスを、1 つの連絡先キーに登録するケースが見受けられます。これを行うと、Contact Builder などでアノニマスな連絡先の情報が閲覧できない、トラッキング情報が追跡しづらくなる等のさまざまな問題が発生しえます。アノニマスな連絡先の取り扱いとして、これらを連絡先として登録したくない場合は上述の Delay Registration を利用し、登録したい場合はデフォルトの GUID 形式の連絡先として登録してください。
参考情報 : Registration Updates Via Contact Key, Attributes, and Tags
*引用 : Don't set the contact key to a generic, non-unique value
各チャネルのアドレス情報を持たなくなり、不要となった連絡先を削除する対象を抽出するときは、必ず "チャネルアドレスを持たない連絡先" を利用して削除対象を抽出してください。フィルター済みリスト等を利用して抽出すると、誤った条件で抽出することで、モバイルチャネルのアドレスを持つ有効な連絡先を削除してしまう場合があります。
特にモバイルチャネルは、メールチャネルと異なってチャネルアドレスが各 BU にて管理されますため、これを考慮せず子 BU の有効な連絡先を削除してしまうことがあります。
その場合、下記に記載の通り、削除してしまった連絡先がもつデバイスに対する Push 通知はじめ、あらゆるMobilePushの機能が利用できなくなります。機能を復帰するためにはエンドユーザーにアプリの再インストールを実施いただく必要があります。
https://help.salesforce.com/s/articleView?id=sf.mc_cab_contact_deletion.htm&type=5
Contact Builder での連絡先の削除 > MobileConnect および MobilePush の連絡先の削除
=====
MobilePush 連絡先のすべての削除は、GDPR または他の法的規制に基づくコンプライアンス削除に関連付けられるとみなされます。この連絡先の指定モバイルデバイスからの今後のプッシュ通知登録は MobilePush SDK およびプラットフォームにより制限されます。連絡先として再確立するには、連絡先はデバイスのモバイルアプリケーションを削除して再インストールする必要があります。
=====
またサポートケースでは上記に則り、再インストール以外の方法をお伝えしておりません。
削除後の SDK の内部挙動を解析し、再インストール以外の方法で回復を試みることを目的とした実装に関するお問い合わせいただくことがあります。このような内部挙動に依存した実装はお問い合わせでの対応や動作保証ができかね、お客様環境にて十分に検証を行ったうえで実装いただく必要がございます。
上記のような状況に陥らないためにも、必ず "チャネルアドレスを持たない連絡先" を利用して連絡先の削除対象を抽出してください。
やむを得ずチャネルアドレスを持つ連絡先を削除する場合は、上記の点を考慮し、不要な連絡先を事前に入念にチェックのうえ削除してください。
受信トレイメッセージは、以下の通り Push 通知とは異なる特徴を持ちます。
プッシュ通知 :
Marketing Cloud から メッセージプロバイダー (FCM/APNs) にリモート通知のリクエストを行います。ユーザーが当該アプリの通知を許可していなければ、通知を送信することはできません。
受信トレイ :
アプリがフォアグラウンドになった際に、アプリからMarketing Cloudに対して、自身のデバイスが対象となるメッセージを都度ダウンロードします。通知の仕組みを利用しないため、当該アプリの通知を許可していなくとも、メッセージをダウンロードできます。つまりオプトアウトデバイスに対しても送信対象となります。
また、Marketing Cloud からデバイスに対してはアプローチしないことにご注意ください。受信トレイメッセージで「配信」や「送信」といったワードが便宜的に使われることがありますが、実際にはデバイスに対して Marketing Cloud から自発的に何か送信しているのではなく、当該の受信トレイメッセージをダウンロード可能な状態にすることを指します。
プッシュ通知 + 受信トレイ:
プッシュ通知を送信し、かつ受信トレイメッセージも同時にダウンロード可能な状態にします。通知を許可していないデバイスに対してはプッシュ通知は送信されず、受信トレイメッセージのみが配信可能な状態になります。
Q) デバイスをアンインストールもしくは通知を無効にしてから、オプトアウトになるタイミングはいつですか?アンインストールしてみたものの、オプトインのままで、送信ステータスも OK になります。
A)いずれもメッセージプロバイダーの挙動に依存するため明確なタイミングは不明です。アンインストール後すぐさまオプトアウトになったり、送信時に送信ステータスが NG になるとは限りません。
Q) デバイスをアンインストールしたタイミングを知りたい
A) Marketing Cloud SDK を経由してデバイスでアプリがアンインストールされたことを受け取ることはできません。イベント通知サービス (ENS) を個別に実装する必要があります。これにはMarketing Cloud Engagementからイベントを受信するためのサーバー等の用意が必要となります。
Q) プッシュ通知 (Alert) をアプリ内に Inbox メッセージのように永続的に残す機能はあるか
A) いいえ、残念ながら弊社 SDK には当該の機能はありません。個別のカスタマイズが必要になります。
ただし、SDK 9 系以降が組み込まれているアプリであれば、 "Push Copy to Inbox " のオプションを利用すれば、Inbox メッセージとして、通知と同等の内容を Inbox として取得できるようになります。
Q) MobilePush の SDK 以外に他社の Push 通知関連の SDK を導入しているが、通知を受け取ることはできるか
A) 技術的には可能ですが、複数の SDK が通知の制御が競合しあうため、下記の記事の通り結果を保証することができません。
そのためサンプルのコードや対処方法のご案内はサポートケースではお伝えしておらず、アプリ側でカスタマイズした実装を行い、制御を行う必要があります点をあらかじめご了承ください。
Use Multiple Providers for Push Notifications
Q) MobilePush の SDK をアプリに組み込み、デバイスにアプリをインストールしましたが、Marketing Cloud に連絡先としてなかなか反映しません
A) 連絡先のMarketing Cloudへの反映はリアルタイムでは反映しないため数分程度待機してください。
もし仮に十分な時間 (1 時間など) をおいても連絡先が反映されない場合は、Learning App を用いて状況が改善しないか切り分けを行ってください。
この時、 Learninrg App で速やかに連絡先が反映される場合は、組み込んだアプリの初期化などアプリ固有の実装に問題がある可能性が高まります。このため、起動時に正しくアプリの初期化ができているかなどをログから確認します。
一方で、Learninrg App でも連絡先が反映されない場合は、Learninrg App に設定する設定値の誤りや、デバイスの通信状況、当該 MID の何らかの問題など様々な要因が疑われます。
Q) MobilePushのスーパーメッセージの消費契機について
A) 下記の記事を参照してください
Marketing Cloud Engagement | MobilePush に関連する Super Message の消費に関して
Q)_PushAddress データビューの項目について質問したい
A) 本データビューは記載時点では残念ながら公式にサポートしているものではないため、サポートケースでは関連するご質問へ回答が出来兼ねます。この点をご了承のうえ、利用を検討してください。
Q)Contact Builderで閲覧できる [MobilePush Demographics] や [MobilePush Subscriptions] の情報を SQL Query Activity などで参照したい。これらはどこに格納されているか。
A) これらの情報はデータビューとして提供されておらず、 SQL Query Activity では利用できません。Contact Builder やフィルター済みリスト、判断分岐などで利用できます。もし各デバイスの属性値 (City, FirstName などのデフォルトの属性や独自で追加した属性など) をデータとして抽出したい場合、フィルター済みリストをエクスポートすることを推奨します。
000388835

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.