MobilePushの連絡先を別 MID/EID へ移設する際の注意点を解説します。このデータ移行には標準機能はありません。基本的に新環境へ移行後は旧環境のデータは利用できません。
もし万が一アプリを新環境に移設せねばならない場合は、アプリ修正や属性値の再設定が必須であるなど、考慮事項が多数あります。本記事では移行時に失敗しないための技術的制約と代表的な考慮事項をまとめました。
*別環境への移行に伴う必要なアクションはそれぞれ状況によって異なり、またSDKのバージョンによっても細部の挙動は異なることがあるため、もしBUの移動を検討する際は事前の検証を入念に行うことが重要です。
MCE にはアプリを新規環境に移行する標準機能はありません。移行が避けられない場合は、本記事を参考に様々な状況を想定して事前にテストし移行を計画します。
なおこの考慮点は多岐にわたり、アプリケーションの要件や状況によって判断が異なるため、Salesforceサポートではプロジェクト全体に関する包括的なアドバイスは提供できかねます。あらかじめご了承ください。
1. アプリのアップデートが必須
MobilePush SDK は、初期化時に接続先の MID に存在する Application ID 等の情報を指定します。そのため、移設先の新しい MID に接続するには、新しい MID にて発行した Application ID を指定してSDKを再初期化するよう、モバイルアプリ自体を修正してストアに提供し、ユーザーにアップデートを促す必要があります。
*なお、SDKは複数の Application ID に同時に接続することはできません。
2. 移行期間の運用を検討する
アプリのアップデートはユーザーの実施するタイミングに依存し、新旧のアプリを利用するユーザーが混在する状態が、ある程度続くことになります。
旧アプリを利用し続けるユーザーは、旧MIDとの通信を継続します。このため、移行期間中は旧MIDに対して連絡先の情報更新やInbox/In-Appメッセージの取得、開封等の情報送付が行われることになります。新旧双方の MID にこれらが分散されることを想定して運用することを検討します。
3. インポートにより旧 MID/EID から新 MID/EID への反映を検討する
上記の通り旧 MID とやり取りするユーザーが一定数発生します。そのユーザーの購読者情報更新も旧 MID に届くことになります。一部のデータが新 MID へ反映されていない場合にはインポート機能の利用を検討します。
しかしながらインポートは MID/EID 間のデータ移行をすることを前提として、整合性を保ってシームレスにインポートする機能はありません。そのため、様々なテストデータやシナリオを用いて、意図した通りに移行し動作するかを事前に入念に検証する必要があります。
なお MobilePushの連絡先リストにインポートするには、最低限以下の4つの情報が必須です。これらのデータが揃っていない場合、インポートはできません。
連絡先キー
DeviceID
プラットフォーム
システムトークン
4. 新アプリにおいて連絡先の属性値は継承されないことに留意する
ユーザーがアプリをアップデートし、SDK の接続先が新 MID に切り替わると、種々の情報が新環境向けの情報となり、旧環境の属性値は利用できなくなります。引き継ぐ機能などもありません。この問題を回避するには、例えば以下のような対応が必要です。
- アプリケーション側で、あらかじめ SDK 以外のストレージ(ローカル DB やバックエンド DB)に各種属性値を保持しておく。
- アプリのアップデート後、新 MID への接続が確立した後に、保持しておいたデータを取得し `setProfileID()` や `setAttribute()` などの SDK メソッドを用いて明示的に新環境へ登録する。
5. 受信トレイ・アプリ内メッセージなどのメッセージは移行されない
旧環境で配信された受信トレイメッセージやアプリ内メッセージを新環境に引き継ぐ機能は無く、アプリのアップデート後はユーザーのデバイスから閲覧できなくなります。
特に受信トレイメッセージはお知らせ機能などで利用している場合があり、ユーザーがアプリのアップデート後も利用できることを期待しているケースがあります。よって事前にユーザーへメッセージが消失する旨を通知したり、すべてのメッセージの有効期限が切れた後に移行を実施したりするなど、計画的な移行が必要です。
6. 解析情報も新旧 MID で分断される
プッシュ通知や受信トレイメッセージの開封状況など、レポートで利用される解析情報も旧環境から引き継ぐことはできません。移行を境にデータが分断されるため、レポートや分析の運用方法についても再検討が必要です。
1.デバイスの属性値を一括で取得する方法はありますか?
A.いいえ、すべての属性値を一括で取得する標準機能はありません。フィルター済みリストをエクスポートすることで多くの属性値を取得できますが、System Token のような一部の情報は含まれません。System Token は、アプリから直接バックエンドデータベースに送信・保管するなどの実装を推奨します。
2._PushAddress データビューから System Token を取得できますか?
A.このデータビューは、記事作成時点において公式にはサポートされていないデータビューです。そのため、このデータビューの詳細やデータ取得に関するご質問には、Salesforceサポートから回答することができません。
3.Marketing Cloud Engagementに保存された属性値をアプリ側で取得できますか?
A. いいえ、できません。MobilePushの連絡先データは、アプリ(デバイス)が持つデータが正であり、そのデータがMCE に送信・反映されるという一方向のデータフローが基本です。MCE 側からアプリ方向に連絡先のデータを取得はできません。もしサーバーサイドからアプリにデータを取得する方式を検討するならば、別途バックエンドデータベースを構築し、そちらを参照する方式を検討してください。
4.アプリをアップデートしていないユーザーに対し、新 MID から Push 通知を送信したところ、正常に受信しました。理由はなぜですか。
A. Push 通知は 各種プロビジョニングやアプリの実装が正しく行われ、かつ対象デバイスの Token が正しいものであれば、どの環境からでも (MCE外であっても) 各デバイスに送信することが可能です。これは、プッシュ通知がプッシュ通知サービス (APNs, FCM) が発行した Token を基に、通知の配信リクエストを行う仕組みであるためです。
5. SDKを複数のビジネスユニット (BU) に同時に接続できますか
A. いいえ、できません。1つのビジネスユニットにのみ接続できます。初期化時に設定する Application ID, AccessToken, Endpoint などの情報を変更すれば、別のBUに接続することはできますが、これまで接続されていたBUとは全く通信が行われなくなります。それに伴う考慮事項は上述の通りであり、あらゆる情報が新規BUにしか送信されなくなり、情報の分断が発生します。
005131359

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.