APP PUSHメカニズムの分析

プッシュは、メッセージの送信者が受信者に情報を配信する行為として定義されます。日常のシナリオと組み合わせると、これは、SMS、プッシュ、WeChat、その他のチャネルを通じてユーザーにマーケティング メッセージや通知メッセージを送信する、会社の運用担当者またはビジネス システムの動作です。

ユーザーへの毎日のプッシュメッセージは、アクティビティへの参加、情報の閲覧、請求書の確認などをユーザーに誘導することができます。これは重要なトラフィックの入り口であり、プッシュはビジネス目標の達成を促進するための重要な手段です。

比較的完全な社内メッセージ プッシュ管理プラットフォームを構築し、社内の各事業ラインと製品ラインのメッセージ プッシュを統一的に管理および送信します。これにより、会社の運用効率が向上するだけでなく、ユーザー エクスペリエンスも保証されます。

1. APP PUSHのプッシュメカニズムを理解する

1.1 APP PUSHの定義と価値

APP PUSHとは、モバイル端末がロックされているときや操作フォアグラウンドの上部にポップアップされているときに通知バーに表示されるメッセージ通知と定義されます。クリックすると、対応するAPPを呼び出すことができ、APP内で指定されたページにジャンプすることができます。

プッシュメッセージは、ユーザーに通知し、アクティビティへの参加や商品の購入を誘導する重要な手段です。また、プッシュメッセージは、ユーザーにメッセージを確認するように誘導し、APPを刺激して日常のアクティビティを増やすことができ、重要なトラフィックソースとなります。

1.2 APPプッシュ分類

アプリケーションの機能に基づいて、それらは主に3つのカテゴリに分けられます。1番目のカテゴリはWeChat、QQなどのIMアプリです。2番目のカテゴリはWall Street Journalなどのニュースと情報アプリです。残りはAlipay、Meituanなどのツールとして一時的に分類されます。

各タイプのアプリには、PUSH に対する要件が異なります。IM アプリは、リアルタイムで安定した到達範囲を追求します。このようなアプリは通常、独自の長い接続を通じてメッセージをプッシュし、ユーザーがメッセージを受信したときにリアルタイムで受信できるようにします。さらに、一部の Android メーカーは、トップ APP のプロセスに対して特定の保護を提供し、関連するプロセスをホワイトリストに追加し、プロセスをクリーンアップするときにそれらを無視します。

ニュース・情報アプリのPUSHプッシュの仕組みは、頻度制御が異なるだけで、基本的にはツールアプリと同じです。ニュース・情報アプリはニュースや情報量が多いため、速報をタイムリーにユーザーにプッシュする必要があります。

現在はツール系アプリが大多数を占めているため、この記事では主にツール系アプリの一般的なプッシュの仕組みについて説明します。

1.3 PUSHプロセス

メッセージシステムが作成されると、PUSH メッセージは送信段階に入ります。サーバーは、ユーザーの端末情報に応じてルーティングする必要があります。IOS システムの場合は、Apple 独自のプッシュ通知サービス (APNs) を呼び出します。ユーザーの電話が Android システムの場合は、メーカーに応じて異なるメーカーの SDK が呼び出されます。

システムバージョンによって、サポートされるメッセージ表示形式が異なります。たとえば、iOS 10 以降では、アプリがフォアグラウンドにあるときに通知バーに表示するかどうかは、製品要件に応じて選択でき、サーバーは対応する通知方法の値を送信できます。ユーザーの携帯電話が 5 大メーカーのいずれでもない場合は、ユーザーが独自に構築した長距離接続を介して、またはサードパーティのサービスを使用してプッシュ通知を送信できます。

メーカーのチャネルに直接接続しない場合は、内部サーバーは複雑で面倒な開発作業をあまり行う必要がなく、Xingge、Getui などのサードパーティのメッセージ プッシュ プラットフォームに接続することでメッセージ プッシュを実装できます。ほとんどのチャネルは、メッセージがクライアント SDK に正常にプッシュされたかどうかを示す受信データを送信者にフィードバックするため、コールバック アドレスを提供する必要があります。

1.4 基礎チャネルの説明

1.4.1 プッシュ方式

チャネルの種類は、一般的に、メーカー チャネル、サードパーティ プッシュ サービス プラットフォーム、およびロング接続の 3 つのカテゴリに分類されます。

メーカーチャネルは、モバイル端末メーカーが立ち上げたプッシュサービスです。メーカーのSDKにアクセスすることで、内部サーバーは携帯電話システムのサーバーにメッセージをプッシュし、クライアント内のメーカーSDKに送信します。オペレーティングシステムはそれに応じて表示し、クリック後に対応するAPPを呼び出します。これにより、APPプロセスが強制終了された後にメッセージがユーザーに届かないのを防ぐことができるため、到達率が比較的高くなります。

サードパーティ プッシュ プラットフォームは、プッシュ サービス会社自体によって構築された関連メッセージ サービスです。さまざまな APP が同じプラットフォームのプッシュ サービスを使用する場合、クライアントは同じサードパーティ プッシュ プラットフォームの SDK と統合され、プッシュ アライアンスが形成されます。アライアンス内の 1 つの APP のメッセージ プロセスが強制終了されていない場合、他の APP もそれを使用してユーザーに通知できるため、相互の覚醒が形成され、到達率が向上します。いくつかのシナリオでテストしたところ、相互覚醒の成功率はそれほど高くないので、自分のシナリオと慎重に組み合わせて評価する必要があります。リーチ率を高めるために、サードパーティのプッシュ プラットフォームもプッシュ用の主要メーカーの SDK を統合します。

ロング接続とは、携帯電話とサーバー間のリンクを確立してメッセージデータをプッシュすることです。ロング接続を通じてAPPの状態を監視することもできますが、ロング接続を通じてメッセージを完全にプッシュし、安定した到達を確保するには、より多くの研究開発リソースが必要です。また、ロング接続プロセスがオペレーティングシステムによって強制終了されないようにする必要があります。

1.4.2 利点と欠点の比較

APPプッシュ機能の構築は、製品自身の状況と企業が投資できるリソースコストに基づいて行う必要があり、段階ごとに異なる目標を追求する必要があります。

1.5 プッシュ通知を送信する

1.5.1 プッシュアカウント

プッシュすると、クライアントの PUSH SDK はユーザーのデバイス番号に基づいて対応する TOKEN を生成します。 SDK 内で、サードパーティのプッシュ サービスを使用している場合はサードパーティ SDK に登録します。メーカーの場合はモール SDK に登録します。独自のロング接続を使用する場合は、後続のプッシュでユーザーを識別するための一意の ID として独自の SDK に登録します。

1.5.2 メッセージルーティング

メッセージ パスは、主に上記のプッシュ プロセスで説明されています。ここでは主に、さまざまなビジネス シナリオに応じて、異なるバージョンの APP のユーザーにプッシュされる可能性があることについて説明します。したがって、サーバーがチャネル機能ルーティングを実行する場合、チャネルを区別できるだけでなく、ユーザーの携帯電話に対してより洗練された差別化されたプッシュ通知を実行できる必要があります。

さらに、メッセージ チャネルは必ずしも 100% 安定しているわけではありません。ダウンストリーム チャネルに問題が発生した場合、安定したビジネス配信を確保するために、サーバーはチャネルの問題によって発生したメッセージをバックアップ チャネルにルーティングできる必要があります。

1.5.3 フルプッシュ

一般的に、製品の顧客IDは社内業務や会社関連データの基礎として使用されます。ユーザーデータシステムがメッセージシステムに接続される場合、顧客IDもよく使用されます。そのため、対象ユーザーをプッシュする操作を容易にするために、顧客IDとプッシュトークンの関係を確立する必要があります。ただし、一部のシナリオでは、ログインしていないユーザーに情報をプッシュする、つまり、フルプッシュが必要です。たとえば、最新ニュース情報、大規模なプロモーション、その他のアクティビティなどです。そのため、オペレーションシステムは、すべてのトークンに情報をプッシュするためのフルプッシュ機能を提供する必要があります。

1.6. データレポート

報告されるデータには、リーチ、クリック、クローズ、終了、登録などのデータが含まれます。

すべての種類の連絡メッセージは、連絡とクリックから切り離せません。連絡データは、メーカーの必要に応じてメーカーのコールバックを通じて報告され、クリックデータは SDK によってサーバーに報告されます。プッシュ通知が過剰に送信され、ユーザーに迷惑をかけていないかどうかを評価するために、プッシュ通知を無効にすることも検討する必要があります。シャットダウン データには 2 つの部分があります。1 つはアプリ内のシャットダウンで、SDK がサーバーに直接報告できます。もう 1 つは、ユーザーが携帯電話のオペレーティング システムで対応するアプリのプッシュを閉じたことです。アプリがフォアグラウンドにある場合、SDK はモバイル端末の関連メソッドを呼び出して、ユーザーがシステム通知を閉じたかどうかを取得し、サーバーに報告します。

登録データとは、ユーザーが初めてアプリを起動したときに、関連する SDK にアクセスしてトークンを登録することを意味します。

一般的に、ユーザーがアカウントからログアウトすると、SDK はトークンを顧客 ID からバインド解除するためにサーバーに報告する必要があります。

1.7. PUSH機能

1.7.1 痕跡を残さずに強力なリマインダー

プッシュはアプリ独自の通知チャネルであるため、運用上重要なツールとなります。ユーザーがプッシュ通知を閉じていない場合、プッシュ通知は通知バーからポップアップしてメッセージを表示することができ、一定の強力なリマインダー効果があります。ただし、ジャンプをクリックするとプッシュ通知は消え、痕跡は残りません。そのため、重要な通知メッセージについては、アプリ内にメッセージセンターを設定し、プッシュ通知と同時に通知記録を残す必要があります。

1.7.2 メッセージスタイル

各 PUSH では、一部のマーケティング メッセージに EMOJI 表現が含まれ、ユーザーのクリックを促します。サービスが合意された EMOJI コードの送信をサポートしている限り、これもユーザーのクリックを促す小さな方法です。

現在、Android システムは、画像、音声、その他の形式のプッシュを含むリッチ メディア プッシュもサポートしています。情報アプリの場合、サムネイルを追加してユーザーのクリックを促すことができます。現時点では、音声シナリオにはまだ検討すべきことがたくさんあります。

1.7.3 iOSとAndroid

APPは携帯電話のオペレーティングシステムに基づいているため、詳細と方法がわずかに異なることを除いて、IOSとAndroidのプッシュプロセスと機能は基本的に同じです。また、国内のAndroidメーカーはAndroidシステムに一定の変更を加えたため、国内のAndroidメーカーごとに異なる標準が生まれました。開発者は各メーカーと慎重に連絡を取る必要があります。

1.8 リーチの向上

リーチ率を向上させるには、メッセージの作成からユーザーへの実際の通知までの完全なプロセスを確立し、各インタラクションリンクを改良し、リーチ率に影響を与える主なボトルネックを発見し、ターゲットを絞ったソリューションや最適化計画を実行する必要があります。さらに、メーカー チャネルを使用しないメッセージでは、独自のロング接続やその他のプッシュ プラットフォーム サービスを使用して複数のメッセージを同時にプッシュしたり、クライアント SDK で同じスロット シリアル番号の重複排除を追加したりすることもできます。これにより、一部のメッセージの到達率も向上します。

2. メッセージ管理プラットフォームを0から1に構築する

2.1 プッシュシステムプロセス

一般的に、プッシュメッセージを送信する方法は 2 つあります。1 つは、スケジュールされた操作を一括して実行する方法であり、ユーザーをスクリーニングし、コピーを編集して承認後に送信するための操作を容易にするシステム機能を提供する必要があります。もう 1 つのタイプは、支払い成功通知、検証コードの取得、特定の条件を満たすことでトリガーされるマーケティング活動などの、リアルタイムでトリガーする必要があるメッセージです。これらのメッセージには高い適時性が求められ、各ユーザーが送信するメッセージの内容には差別化されたパラメータが含まれており、ビジネス アプリケーションによるリアルタイムのトリガーが必要です。トリガーされたメッセージは、特定のフィルタリングおよび傍受ルールを通過し、短期間にカバーされたユーザーをフィルタリングし、異常なメッセージや非準拠のメッセージを傍受し、設定されたチャネルに従ってプッシュする必要があります。

2.2 データの準備

メッセージプッシュシステムでは、対象ユーザーのアカウントデータを取得する必要があります。多くの場合、自社製品の顧客IDは対応するプッシュチャネルのアカウントと一致しないため、バインディング関係を取得する必要があります。たとえば、SMSには携帯電話番号が必要で、プッシュにはSDKによって報告されたトークンが必要で、WeChatにはOPEN IDの使用が必要です。関連データの収集については、各チャネルの送信メカニズムに関する記事で説明されています。

2.3 メッセージの作成

2.3.1 ターゲットオーディエンスの選択

日常業務の精度を高め、商品や機能の転換率を向上させるために、運用スタッフは北京在住のユーザー、過去 3 日間にアプリにログインしたユーザーなど、ユーザーの特性に基づいてユーザーを選別します。そのため、メッセージ配信システムを社内データ部門のラベル システムに接続し、運用スタッフに配信グループの選択肢を提供する必要があります。インターフェースによってリアルタイムでトリガーされるメッセージでは、通常、ビジネス システムがユーザーの行動を監視し、ユーザー アカウントと必要なパラメーターを MQ またはインターフェースを介してメッセージ プッシュ システムに渡して送信する必要があります。

また、ラベル システムにユーザー データを入力する時間が足りないなどの問題を回避するために、ユーザーに緊急事態をタイムリーに通知できるように、ユーザー アカウント ファイルのアップロード機能も提供する必要があります。

2.3.2 メッセージタイプとレベルの分類

メッセージの種類は、メッセージの内容の目的に応じて分類する必要があります。大きく分けて、通知、マーケティング、検証コードなどに分類できます。

たとえば、SMS 業界は、通知、マーケティング、検証コード タイプのメッセージに分かれています。このタイプの分割は、主に SMS を SP サービス プロバイダーのさまざまなチャネルにルーティングする利便性のためです。チャネルが異なれば到達率が異なります。重要な SMS の到達率を確保するには、異なる内容の SMS をさまざまなチャネルにルーティングして送信する必要があります。

私の個人的な経験から言うと、企業は実際の状況に基づいて、より細かい区分を行うことができます。たとえば、通知+マーケティングの種類を追加します。考えられるシナリオは、ユーザーが正常に支払いを済ませた後、ユーザーの支払い成功情報を記載した後、適切なシナリオに基づいて割引コピーライティングを追加し、ユーザーを他のアクティビティに変換するように誘導することです。金融貸付機関の場合、主にユーザーに返済期限の超過を通知するために、返済通知タイプを追加することもできます。その理由は、特別な期間中、返済通知テキストメッセージは特別な制御の対象となる可能性があり、それらを分離することでより適切に監視および処理できるためです。

通知メッセージもレベルに分ける必要があります。たとえば、ユーザーの支払い成功通知メッセージとクーポン到着通知メッセージは、当然同じレベルであってはなりません。支払いメッセージはユーザーの資金の変更を伴うため、通知レベルが高くなります。一方、クーポン到着メッセージはマーケティング指向が強く、通知レベルは低くなります。ユーザーにさらなる干渉を与えないようにするためには、階層的に制御し、必要に応じて下位レベルのメッセージのプッシュ頻度を減らす必要があります。

2.3.3 メッセージの内容

異なるチャネルのメッセージには異なるメッセージ コンテンツが必要です。SMS コンテンツには SMS ダイアログ ボックスのテキストのみが必要ですが、PUSH にはタイトルとコンテンツの概要を表示する必要があります。WeChat にはテンプレート メッセージがあり、テキスト、画像、音声など、複数の種類のメッセージ コンテンツがあります。製品を設計する際には、対応する配信チャネルを選択した後、対応するチャネルに必要なフィールドが表示されるので、入力する必要があります。

2.3.4 メッセージジャンプ

メッセージがユーザーに届いた後、興味を持ったユーザーはさらに詳しい情報を知る必要があります。しかし、現在さまざまなメッセージを配信しているキャリアでは、すべての情報を表示するのに十分なスペースがないため、詳細な情報を取得するにはランディングページに移動する必要があります。 SMS メッセージは、送信前に長いリンクを短いリンクに変換する必要があります。その理由の 1 つは、SMS は文字数に応じて課金されるため、コストを節約するためです。もう 1 つの理由は、ユーザー エクスペリエンスのためです。ユーザーが携帯電話で目にするのは、長くて文字化けした文字のペアであってはなりません。 PUSH では、H5 ページやネイティブ ページなど、ページごとに異なるジャンプ タイプを設定する必要があります。ジャンプ プロトコルはクライアントによって提供されます。メッセージ システムはシステム上で設定するだけで、運用担当者が選択できます。 WeChatのメッセージ内容は、一般的にH5アクティビティページへのテンプレートメッセージバーの形式になっており、グラフィックメッセージは記事の詳細にジャンプします。テキストメッセージにハイパーリンクを追加してミニプログラムにジャンプすることもできます。

2.3.5 記録すべきその他の情報

メッセージ送信部門：このデータは、その後のSMS料金精算の基礎として使用されます。社内の各業務ラインの費用は、メッセージ送信部門に応じて差し引かれます。PUSHやWeChatメッセージなどの無料リソースについては、各業務部門によるメッセージリソースの使用状況を分析することもできます。

コンバージョン行動の質: コンバージョンは一般的に、メッセージがクリックされた後のステップです。メッセージ送信の品質をより適切に測定するには、注文、実名、アクティベーション、ダウンロード、通知など、各メッセージの目的を記録し、メッセージをコンバージョン行動と照合してデータ分析を行う必要があります。

生産研究マネージャー：メッセージを送信する前に、各タスクまたはテンプレートを記録し、ビジネスラインの製品と実際の研究開発メッセージの担当者に対応する必要があります。顧客からの苦情が発生した場合、メッセージ記録クエリ機能を使用して、メッセージの生産研究マネージャーをすばやく見つけ、対応するメッセージに異常があるかどうかを緊急に確認して解決できます。

2.3.6 プッシュ時間設定

異なる形式で送信されたメッセージではプッシュ時間が異なります。作成したメッセージタスクは、スケジュールされた時間に送信されます。固定化されたマーケティングシナリオでは、定期的なタスクを設定し、初期実行時間と実行サイクルを設定し、運用コストを削減する必要があります。インターフェースのトリガー時間は通常リアルタイムであり、トリガー時間はビジネス システムによって決定されます。

2.3.7 オンラインテスト

メッセージタスクが設定された後、オンラインプッシュ事故を回避するために、メッセージ配信後の表示効果と関連するジャンプが正常かどうかを確認する必要があります。テストでは、操作によって設定された実際のコンテンツを送信する必要があり、プッシュ オブジェクトは内部メッセージ作成者です。誤ってメッセージを送信することを避けるため、テスト用に送信するテキストの前に「test」を追加するか、テスト用のホワイトリストを設定する必要があります。ホワイトリストにないアカウントはテストできません。

2.4 メッセージの確認

メッセージ タスクまたはメッセージ テンプレートを作成したら、作業エラーや悪影響を避けるために、送信する前に慎重に確認する必要があります。

監査レベルでは通常、事業ラインと企業プラットフォームまたは対応する機能部門の社内担当者によるレビューが必要です。審査のポイントは、メッセージ文面が広告法に準拠しているか、メッセージの飛び飛びは正常か、送信頻度や時間は適切か、などです。

2.5 メッセージのフィルタリングと傍受

メッセージ フィルタリングは主にマーケティング タイプのメッセージを対象としており、時間制限 (メッセージは午前 9 時から午後 8 時まで送信可能)、頻度制限 (ユーザーは 7 日間に 1 つのテキスト メッセージしか受信できません。定期的なタスクの場合、同じタスクが届いたユーザーはフィルタリング サイクルをさらに延長できます)、ブラックリスト制限 (ユーザーの登録解除) があります。

メッセージ傍受は、主に送信量を制限するためのものです。たとえば、各業務ラインは、1 日に同じユーザーに 5 件を超えるテキスト メッセージを送信できません。会社全体では、同じユーザーに 30 件を超えるテキスト メッセージを送信できません。同じユーザーからの繰り返しコンテンツは、短期間でフィルタリングされます (300 秒などの時間を設定できます)。ボリューム制御は、業務システムの障害によってユーザーに大量のメッセージが送信されることによる悪影響を回避するためだけのものです。

違法、暴力などを含む単語などのキーワード傍受

さまざまなシナリオで使用されるフィルタリング頻度は、適切に調整できます。たとえば、ユーザーの SMS メッセージに対する許容度はプッシュ メッセージに対する許容度よりも低いため、SMS の頻度はより厳しくする必要があります。

2.6 メッセージの送信

さまざまな論理処理を経て、メッセージは最終的に送信段階に到達します。送信段階の主なバックグラウンド ロジックは、メッセージ送信のパフォーマンスの最適化、メッセージ送信の安定性の向上、ビジネス損失の回避に重点を置く必要があります。送信プロセスでは、異常を検出し、問題を適時に特定するために、監視を追加し、ログを適切に印刷する必要があります。

2.7 メッセージルーティング

SMS と Android プッシュはどちらも複数のチャネルにアクセスして配信クラスターを構築できます。ビジネス ロジックに応じて送信するチャネルを指定したり、ダウンストリーム チャネルの状態に応じて自動的にルーティングしたりできます。

2.8 データ分析

リーチシステムでは、一般的に、送信されたメッセージ数 - 到達したメッセージ数 - クリック数 - コンバージョンデータなど、メッセージのプロセス全体に応じてデータ分析が行われます。

メッセージを使用してトラフィックを APP に転送し、APP アクティビティを増やす場合は、各メッセージが APP を呼び出す回数をカウントできる可能性があります。

SMS の場合、SMS 料金がかかり、チャネルと成功したリーチ数に基づいて課金を行う必要があり、調整ダッシュボードを設計する必要があります。

その後のリーチ戦略を調整するには、SMS の登録解除や PUSH の終了などのユーザー行動データも分析する必要があります。

2.9 舞台裏の管理

2.9.1 チャネルルーティング構成

SMS メッセージには、署名とチャネルが関係します。ビジネス シナリオによって必要な SMS 署名は異なり、特定のアカウントやテンプレートのメッセージは固定チャネルにルーティングする必要があります。ダウンストリーム チャネルのパフォーマンスやステータスに基づいて、システムが自動的にメッセージをルーティングする必要性。

2.9.2 クエリメッセージ送信記録

最近送信された関連メッセージについては、確認コードメッセージが届かない、操作を何も行わずにメッセージが届くなど、ユーザーが関連するメッセージの問題について問い合わせることができるように、カスタマーサービス側または操作側で特定のクエリ機能を提供する必要があります。

2.9.3 ブラックリスト

ブラックリスト機能は主にメッセージのフィルタリングに使用されます。ユーザーが苦情を申し立てたり、登録を解除したりすると、そのユーザーにメッセージが送信されなくなります。ブロックの粒度はメッセージの種類に基づいている必要があり、社内業務に応じて適切に分割できます。

2.9.4 フィルタリングと傍受ルールの設定

1. 業務システムの異常によりユーザーに大量のメッセージが集中することを避けるため、同じユーザーに対してメッセージ送信制限を設定する必要があります。
2. 重複したコンテンツをブロックするには、同じコンテンツが繰り返し送信されないように、一定の期間を定めてそのコンテンツをブロックする必要があります。
3. キーワード傍受では、運用上の事故を回避するために、違法なキーワードや不法なキーワードをターゲットにする必要があります。
4. マーケティング メッセージの場合、ユーザーに迷惑をかけたり、ブランドに対する嫌悪感を与えたりしないように、さまざまな連絡方法に応じて連絡頻度を制御する必要があります。

2.9.5 アップリンク管理

アップリンク管理は主に SMS メッセージで使用され、ユーザーは登録解除やビジネス処理のためにキーワードを返信します。オペレータから送信者へのアップリンク プロセスでは、ユーザーがどのメッセージに返信しているかを正確に判断できないため (ユーザーが特定の番号にテキスト メッセージを積極的に送信する場合もあります)、異なるシナリオが互いに影響を及ぼさないようにするために、アップリンク キーワードは一意である必要があります。

著者: Zhuobiemu

出典: Zhuobeimu