多数の成功事例あり。離脱ユーザーの再起をプッシュ通知で支援
一定期間アプリを起動していないユーザーに対してプッシュ通知を送ることが可能。
アプリへの再起に繋がった施策を行うことができます。
継続率や起動回数を上げたい
アプリの利益を伸ばしたい
素早く実装したい
一定期間アプリを起動していないユーザーに対してプッシュ通知を送ることが可能。
アプリへの再起に繋がった施策を行うことができます。
繰り返し配信で効率的なプッシュ通知配信や解析、業界トップの速度でクーポン付きプッシュ通知の配信が可能。
売り上げに繋がる施策を行うことができます。
SDKを入れるだけで簡単にプッシュ通知の導入が可能。
また1つのSDKで多数のプラットフォームに対応可能です。
機能の詳細や成功事例について知りたい方は
お気軽にお問い合わせください。
ユーザーがスマートフォンアプリを開いていなくても直接端末に配信されるプッシュ通知の方が少ないアクションで目的の情報を見ることができるため、プッシュ通知の開封率が高くなっています。
速報や限定セールなど緊急性の高い情報をプッシュ通知ですぐに端末に向けて知らせることができます。
ニュース・EC系のアプリでは今やプッシュ通知は運用に欠かせないものとなっています。
ユーザーがアプリを離脱する理由の一つとして「使い方がわからない」ということがあります。
そのようなユーザーを少しでも減らせるようにGrowth Pushでは「起動してから5日以内」や「登録当日」など、決められた期間内のアクションによってプッシュ通知を配信することができます。
柔軟なセグメントが作成できることにより、ユーザーの継続率向上に貢献しています。
開封率の改善や運用ノウハウを知りたい方は
お気軽にお問い合わせください。
Growth Pushはサービスの成長に合わせた価格をご提案しているため、
常に丁度いい価格で高機能のプッシュ通知サービスを使うことができます。
Growth Pushの豊富な機能をご利用になれます
プッシュ通知サービスを検討中で価格に悩まれている方は
お気軽にお問い合わせください。
デバイストークンは更新されます。
iOS8以降は、インストール・アンインストールでデバイストークンが変わります。
現在は、32byteのデバイストークンですが、2016年度中に100byteのデバイストークンに変更されます。
AndroidのレジストレーションIDは、更新されます。
1つの端末に対して複数のトークンが紐付いてしまう場合があります。
トークンが変化しても古いトークンはしばらく有効のままになり、サーバに複数のトークンを保持してしまうと多重送信となる可能性があるため、端末ごとに常に最新のレジストレーションIDに更新する必要があります。
GCMに、プッシュ通知送信リクエストをした際に、プッシュ通知を送信したレスポンスにトークンが変化した旨と、新しいトークンが返送されます。
これを元に、データベースを更新することで多重送信を防ぐことができます。
アプリインストール後、初回起動時に、1度だけ端末からデバイストークンを取得するために、ユーザーにプッシュ通知許可のダイアログが表示されます。
そこでユーザーが拒否した場合はデバイストークンを取得することができません。
端末の設定アプリからアプリ毎の、通知受信可否を変更できます。
また、アプリ側から、端末のプッシュ通知設定へ飛ばすことも可能です。
マニフェストファイルでパーミッション(C2DMメッセージの送受信)を記載することでレジストレーションIDの取得、プッシュ通知の受け取りが可能になります。
アプリダウンロード時に、プッシュ通知の権限を許諾する方式となっています。
端末設定のアプリ管理から、アプリ毎にプッシュ通知の受信可否を選択することができます。
Apple Push Notification service(APNs)という、プッシュ通知サーバーが存在します。
通信形式が、Apple独自のプロトコルとHTTP/2の通信と2つが用意されています。
独自プロトコルの接続では、1回の接続で複数のペイロードを送信することができるのですが、途中に不正なリクエストが含まれると、その次以降のペイロードが破棄されてしまうため、一括送信の制御には手間がかかります。
また、短い時間に大量のリクエストを送ったり、パケットサイズが大きくなると、APNsが、通信遮断をする可能性がございます。
HTTP/2形式での通信は、REST形式でのリクエストが可能となっており、1デバイス1接続で送信することができ、1レスポンス毎に適切な処理を行うことが可能です。
並列化を行って、複数の端末に送信することができます。
Google Cloud Messaging(GCM)は、HTTP通信で送信となっております。
リクエストヘッダーにAPIキーを添え、リクエストボディにメッセージや送信先デバイスのトークンを送信するのみとなっております。
GCMは1度のリクエストで、1,000デバイスまでの一括送信を行えます。
iOSはOSの仕組みに乗らなければいけません。
iOSのAPNSは送信するデータの形式もしっかり決まっていて、その形式にしたがって送信すれば、あとはOSが定めた方法で表示されます。
Androidは自由度が高く各自の実装にゆだねられています。
Android送信データは完全に自由で、それを受信した際にアプリがどんな動作をするかも、制限されていません。
よって受信時の表示などの処理をすべて独自で実装する必要があり、クライアントの実装の手間は数倍になります。
プッシュ通知リクエストを、OSが判断し、アプリ毎の通知表示をします。
APNsは、送信するデータの形式が決まっているため、不正な形式になるとプッシュ通知表示がされない可能があります。
iOS10からは、プッシュ受け取り時に、画像を表示したりなどリッチな表現が可能になりました。
Receverというものがあり、プッシュ通知を受け取ることのみを行えます。
プッシュ通知表示などは、データを展開するなどして、表示するための実装が必要となります。
GCMへの送信は、JSON形式になっていれば、レジストレーションIDの指定以外は、特にデータの中身の項目は決まっておりません。
表示形式や送信データに制限がないので、(ユーザーを妨げるような表現は、NGです。)受信時に、画像を表示したりなどのリッチな表現が可能となっています。
OS毎に、送信できるデータ長が違います。
iOS7 256byte
iOS8 2KB
iOS9以降 4KB (*HTTP/2の通信形式でリクエストした場合)
サウンドは18byte、バッジは11byteとなります。
タイトルとメッセージを合わせて4KB以内のデータにする必要があります。
全角3バイト、半角カナ3バイト、記号1バイト、半角英数1バイト。
全角文字340文字もしくは半角英数1024文字が目安です。
導入のご検討はお気軽にお問い合わせください。