購読者を失うことなくプッシュ通知プロバイダーを切り替える方法

あなたは、懸命に獲得したオプトインを1つずつ積み上げてプッシュ購読者リストを作成しました。そして、各オプトインには実際の獲得費用がかかりました。そのため、プッシュ通知プロバイダーを切り替える時期が来ると、特定の懸念が生じます。古い契約をキャンセルすると、リストも消えてしまうのではないかということです。現在のベンダーは、まさにそのように言うかもしれません。

それは真実ではなく、このガイドではブラウザレベルでその理由を示します。ウェブプッシュの購読は、ベンダーではなく、あなたのドメインに紐付けられています。仕組みを理解すれば、すべての切り替えは、2つの明確なシナリオのいずれかに解決され、現在のベンダーへの質問リスト（書面）と、チームが問題なく実行できる1週間のチェックリストが得られます。

まず正直に申し上げます。私たちを含め、すべてのベンダーの営業チームは、移行は簡単だと言うでしょう。ほとんどはそこで止まります。この記事では、代わりにその仕組みを示しますので、開発者は、私たちが最後に述べるものを含め、すべての主張を検証できます。

ウェブプッシュの購読とは何か

訪問者があなたのサイトで「許可」をクリックすると、ブラウザは3つの部分からなるウェブプッシュ購読を作成します。

1. あなたのオリジン。 許可が付与された正確なドメイン（https://yoursite.com）。許可はブラウザ内に保存され、オリジンに紐付けられます。ベンダーの名前は含まれません。
2. サービスワーカー。 通知を受信して表示する、あなたのドメインでホストされる小さなJavaScriptファイル。登録されているサービスワーカーが配信を制御します。
3. アプリケーションサーバーキー。 VAPIDキーペアの公開部分。ブラウザのプッシュサービスは、一致する秘密鍵で署名された送信のみを受け入れます。その秘密鍵を保持している人が、購読にメッセージを送信できます。（web.devのプッシュ通知の概要で、完全なプロトコルをカバーしています。）

購読レコード自体は3つの文字列です。エンドポイントURLと2つの短いキー、p256dhとauthです。それがすべての資産です。あなたのリスト全体は、それらのレコードのテーブルです。

1つのルールがすべてを決定します。ブラウザは、一致するVAPID秘密鍵の保持者からの送信のみを受け入れます。 これは、すべてのベンダー切り替えが、それらのキーがどこにあるかによって、正確に2つのシナリオのいずれかに解決されることを意味します。

シナリオA：VAPIDキーを持ち出す場合、初日からプッシュ購読者をインポートできます

シナリオAは、キーを持ち出すことができる場合に適用されます。セットアップ時に独自のVAPIDキーまたは独自のFirebaseプロジェクトを設定したか、または現在のベンダーがキーペアの引き渡しに同意した場合です。一部のチームは、初日から意図的にこれを設定しています。このアプローチは、ベンダーロックインなしでウェブプッシュを実装するガイドで説明されています。

プライベートキーがあれば、新しいプロバイダーはプッシュサブスクライバーを直接インポートできます。すべてのエンドポイント、p256dh、およびauthレコードが移行され、初日から既存のリスト全体にメッセージを送信できます。これには、数ヶ月間訪問していない休眠中のサブスクライバーも含まれます。再オプトインは不要で、誰も気づきません。

明確に述べる価値のあるニュアンスが1つあります。シナリオAでも、すべてのサブスクライバーが最終的に新しいサービスワーカーに着地する必要があるため、耐久性のある移行は再訪問を通じて完了します。インポートされたキーは、ロールオーバーがバックグラウンドで静かに発生している間、初日からリーチを確保します。

シナリオB：キーは残され、サイレント再サブスクライブが引き継がれます

シナリオBは一般的なデフォルトです。ベンダーがVAPIDキーを生成し、それを保持します。プライベートキーがないと、エクスポートされたレコードは暗号学的に無意味です。初日のリーチはゼロであり、古いベンダーの警告はあと1段落の間は真実味を帯びます。

実際に起こることは次のとおりです。次に各サブスクライバーがサイトを訪問するとき、新しいプロバイダーのサービスワーカーが引き継ぎます。古い登録を解除し、古いサブスクリプションを解除し、新しいキーの下で訪問者を再サブスクライブします。サイレントに、1回の訪問で、2回目の許可プロンプトなしで。

新しいサービスワーカーが2回目のプロンプトを必要としない理由

通知の許可は、ベンダーではなく、お客様のオリジンに付与されます。ブラウザはすでにドメインを信頼しています。既に付与された許可の下でサービスワーカーとキーを入れ替えることは、ブラウザがサイト自身の配管を整理していると見なすため、訪問者には見えません。まさにそれです。

開発者が知っておくべき2つの落とし穴

1つのオリジン、1つのサブスクリプション。ブラウザは、同じオリジンに対して2つのプッシュサブスクリプションを保持できません。古いサブスクリプションが解放されるまで、異なるキーでのサブスクライブは失敗します。したがって、「両方のベンダーを並行して実行する」はリストレベルでは機能しますが、単一のブラウザ内では機能しません。各サブスクライバーは古いベンダーまたは新しいベンダーのいずれかに属しており、すべての再訪問でさらに1人が移行されます。

ベンダーサブドメインのオプトインは移動しません。yoursite.vendor.comで収集されたサブスクリプションはベンダーのオリジンに属しており、どのプロバイダーも移行できません。そのベースはゼロから再構築されます。これは、プッシュ通知移行における最大の落とし穴であり、今回はあなたが管理するドメインにサブスクリプションを固定するための最も強力な理由です。複数のブランドまたは地域ドメインを運営している場合、同じオリジンロジックが全体のアーキテクチャを形成します。これは複数のドメインにわたるWebプッシュで説明しています。

2つのシナリオを並べて示します：

	シナリオA：キーが移動する	シナリオB：キーは残される
適用される場合	独自のVAPIDキー/独自のFirebaseプロジェクト、またはベンダーがペアをリリースする場合	ベンダーがキーを生成し、保持する場合（一般的なデフォルト）
初日のリーチ	休眠中のサブスクライバーを含む、あなたのリスト全体	訪問者が戻ってくるまでゼロ
各再訪問時	サブスクライバーは静かに新しいキーに移行します	新しいキーの下でサイレント再サブスクライブ、2回目のプロンプトなし
誰を回復するか	全員	再度訪問した全員
誰を失うか	誰も	二度と戻ってこない購読者（すでに収益が見込めない購読者）

毎日訪問するオーディエンスがプッシュ通知移行を最も早く完了する理由

シナリオBでは、テイクオーバー期間はオーディエンスの再訪頻度によって決まります。それ以外は関係ありません。eコマースの購読者は月に一度訪れるかもしれないので、テイクオーバーは数ヶ月に及びます。ベッターは毎日オッズ、ライン、結果を確認します。ニュースリーダーはヘッドラインのサイクルごとに戻ってきます。

その再訪リズムこそ、ベッティングサイトやニュースサイトがインターネット上で最も有利な垂直分野である理由です。プッシュ通知の頻度が高いほど、他のサイトでは四半期かかる移行を1〜2週間に圧縮できます。PushEngageを利用しているベッティングおよびゲーミングサイトは35億件以上の通知を送信しているため、これらのテイクオーバーメカニズムは私たちにとって理論ではなく、日々の制作の現実です。

オーディエンスの再訪パターン	典型的なアクティブベースのテイクオーバー
毎日の訪問者（ライブオッズ、速報ニュース、毎日のプロモーション）	数日から約1週間
週に数回（週末のベッター、常連客）	1〜2週間
週に1回以下（季節的な訪問者、休眠ユーザー）	数週間（旧ベンダーからの送信や大規模イベントによって加速）
休眠中（数ヶ月間訪問なし）	シナリオAでのみ回復可能

これらは毎日の訪問者に対する典型的なパターンであり、保証ではありません。あなたのカーブはトラフィックのリズムによって異なります。ダッシュボードでライブで確認できます。カーブを曲げることも可能です。メジャーな試合週末の前に移行をスケジュールすれば、イベントトラフィックがテイクオーバーを代行してくれます。試合日のプッシュシーケンスを計画しているスポーツブックは、それらの週末がいつであるかを知っています。

アプリプッシュはよりシンプルです。トークンは常にあなたのものです。

アプリプッシュも送信している場合は、一息つきましょう。この部分は構造的に簡単です。ベンダーがそれを人質に取ることはできないからです。

APNs証明書とキーはApple Developerアカウントに発行されます。FCMプロジェクトはGoogleコンソールにあります。プッシュベンダーは、あなたが所有する認証情報の上に重ねられたレイヤーです。したがって、切り替えとは、新しいレイヤーを同じ認証情報に向けることを意味します。デバイストークンは、再インストールや2回目の許可プロンプトなしで、クリーンにエクスポートおよびインポートされます。

実用的な注意点が2つあります。まず、トークンをインポートする前に、約270日間アクティブなデバイスに絞り込んでエクスポートをフィルタリングしてください。なぜなら、FCMは〜270日以上アクティブでないトークンを古いものとして扱います。5年分のトークンダンプは購読者数を膨張させ、アクティブな購読者のみを対象とする価格設定では、誰も利益を得られません。次に、SDKの完全なカバレッジは、ユーザーがアプリを更新する速度で到達します。通常、自動更新を使用する毎日のアプリでは1〜2週間です。

iOSアプリが現在Firebase経由で送信している場合、段階的なフローはそれ自体がトピックです。この投稿で即興で対応するのではなく、iOSのFirebase Cloud Messagingからの移行ガイドを参照してください。

プッシュ通知プロバイダーを切り替える前に、これらの6つの質問を書面で尋ねてください。

ベンダーのエクスポートとキーポリシーは様々であり、変更されます。ベンダーの評価表（当社が公開するものを含む）を信頼する代わりに、ベンダー自身の回答を記録として入手してください。メールでも可能ですが、サポートチケットの方がより良いでしょう。同時にデスティネーションを評価している場合、OneSignalの代替を比較する際に同じ質問が有用なスクリーニングとなります。

1. すべてのウェブプッシュサブスクリプションレコード（エンドポイントURL、および各サブスクライバーのp256dhキーとauthキー）をエクスポートできますか、それとも内部IDのみですか？内部IDはベンダーのシステム外では無意味です。
2. サブスクリプションが作成されたVAPIDキーペアをリリースしますか？この単一の回答がシナリオA対シナリオBを決定します。
3. 私のウェブプッシュは、私のFCMまたはFirebaseプロジェクトで実行されますか、それともあなたのプロジェクトで実行されますか？あなたのプロジェクトの場合、キーはすでにあなた自身のコンソールにある可能性があります。
4. セグメント、タグ、サブスクライバー属性、および抑制リストを個別にエクスポートできますか？これらはサブスクリプションレコードに自動的に付いてきません。
5. アプリプッシュデバイスのトークンをエクスポートできますか？また、どのような形式ですか？
6. ダウングレードまたはキャンセルした場合、私のデータはどうなりますか？自動削除または保持期間はありますか？一部のベンダーは、下位ティアでは非アクティブなサブスクライバーデータを削除します。常にまずエクスポートしてください。

移行ウィークのチェックリスト

このセクションを印刷してください。8つのステップ、順番通りです。

1. キャンセルまたはダウングレードする前に、すべてをエクスポートしてください。サブスクリプションレコード、アプリトークン、セグメント、タグ、属性、抑制リスト。エクスポートアクセスは契約終了とともに失われます。
2. VAPIDキーの回答を書面で入手してください。これにより、あなたのシナリオと、初日からプッシュサブスクライバーをインポートできるかどうかが決まります。
3. 抑制リストを最後にではなく、最初に移動してください。ベッティングおよびゲーミングオペレーターにとって、これは譲れません。自己除外されたプレイヤーは、単一のキャンペーンが再開される前に新しいプラットフォームで抑制される必要があり、後で調整されるわけではありません。
4. インポート前にアプリトークンを約270日アクティブなものにフィルタリングしてください。
5. 新しいSDKとサービスワーカーをインストールし、既存のサービスワーカー（PWAシェル、古いベンダーのワーカー）を上書きするのではなく、マージしてください。
6. 初日に古いベンダーのサービスワーカーファイルを削除しないでください。訪問者はまだそれに向けられた登録情報を保持しています。引き継ぎはそれらを正常に登録解除します。ファイルを早期に削除すると、移行ではなくコンソールエラーが発生します。最終的な解体時にファイルを削除してください。
7. 古いベンダーに並行ウィンドウで送信を継続させてください。直感に反しますが、非常に重要です。古いベンダーが送信するすべての通知は再訪問を促進し、すべての再訪問はさらに多くのサブスクライバーの移行を完了します。あなたの送信ベンダーはあなたの最高の移行ツールになります。
8. 引き継ぎを毎日測定し、プラトーで切り替えてください。新しいアクティブベースと古いアクティブベースを追跡します。曲線が平坦になったら、解体を完了し、古い契約をキャンセルし、エクスポートをアーカイブしてください。

PushEngageが代行する場合の切り替えコスト

PushEngageでは、移行は有料プランに含まれる無料のホワイトグローブサービスです。ヘルプセンターの記事ではなく、移行エンジニアが担当します。エクスポートマッピング、キー処理、サービスワーカーのマージ、引き継ぎ計画を処理します。これは重要なことです。なぜなら、失敗モードは静かなものだからです。ペイロード形式が一致しない生のインポートは、技術的には成功しても空白の通知を配信する可能性があります。これは、専門家が加入者よりも先に検出するサイレント障害のまさにそのクラスです。

スコープコールは約15分かかります。チャネルごとの加入者数、現在のベンダー、そして上記のキーに関する質問です。終了時には、シナリオAまたはBのどちらであるかがわかり、日付の入った計画が立てられます。

プッシュ通知プロバイダーの切り替えを検討している場合は、この記事の6つの質問から始め、現在のベンダーがどのように回答するかを確認してください。次に、セグメンテーションと収益アトリビューションを中心に構築されたウェブプッシュ通知プラットフォームが、あなたがすでに所有しているリストで何をするかを見て、現在の請求書と比較してPushEngageの価格を確認してください。すべての有料プランには14日間の返金保証が付いているため、プッシュ通知の移行自体は、意思決定の中で最もリスクの低い部分です。