アプリの運用においてプッシュ通知は必須の存在ですが、mBaaSのようなサービスを使わなくとも自分たちで開発、運用ができないこともありません。しかし多くの手間がかかるのも確かです。
今回は自分たちでプッシュ通知を実装した際によくある面倒ごとについて紹介します。
外部に公開されたサーバを立てないといけない
当たり前ではありますが、アプリでプッシュ通知を許可した場合にはデバイストークンと呼ばれる一意の識別子が生成されます。これをサーバに保存しておかなければなりません。スマートフォンはどこでも使われますので、そのデータを保存できる外部に公開されたサーバの存在が必須になります。
サーバを立てる場合はその費用、受け口となる部分のAPIの開発、サーバのメンテナンス費用が発生します。特にセキュリティ周りは注意しておく必要がありますし、一度サーバを立てて終わるというものではありません。
運用の細かいニーズに応える必要がある
プッシュ通知を単に全デバイスに対してブロードキャストするだけであれば良いのですが、多くの場合運用側から細かいニーズが出てきます。例えば3日間アプリを立ち上げていない人だけ、ある商品の購入経験がある人だけといった具合です。こうした細かいニーズに応えられる汎用的なシステムを作るのは難しく、多くの場合エンジニアに依頼がきます。
その結果、データベースを直接変更したり、送り先のリストを作ったりするような作業に駆られます。さらに配信日時が決定していると処理をスクリプトにしてCronで呼べるようにしたりする手間が発生します。
アプリのリリース直後にはアプリ本体の機能開発が優先されるので、運用時の機能は後回しにされがちです。しかし新しい機能を追加してもアップデートしてくれなかったら適用されません。そのため運用時のフローも踏まえた上での初期リリースからの機能実装が必要になります。
開封チェックが大変
せっかく送ったプッシュ通知も単に無視されているのでは意味がありません。まずそのトラッキングをして、効果的であったかどうかを判断しなければならないでしょう。そこでプッシュ通知にPayloadを仕込み、開封通知をサーバ側に配信します。
そういった仕組みの作り込み、検証も意外と面倒なものです。そして大抵データを蓄積すると言うことは、そのビジュアル化（グラフ出力）も求められるようになるでしょう。
iOSとAndroidで配信する仕組みが違う
iOSではAPNs、AndroidではFCMという仕組みによってプッシュ通知を配信します。それぞれ異なる仕組みになっていますので、実装も分けて行う必要があります。かといって運用担当者としてはユーザの状態によってプッシュ通知を分けたいと考えることもあるでしょう。
つまり運用フローとしては共通な仕組みが必要で、システム側でiOS/Androidによってやり方を分ける必要があります。さらにこの仕組みも年々変わってきており、それに追従したシステム更新も必要です。
デバイストークンのメンテナンスが必要
デバイストークンは一度取得すれば永久に使えるというものではありません。ユーザがプッシュ通知をオフにしたり、アプリをアンインストールした時には届かなくなってしまいます。その結果、リストを更新しないとノイズ（送信失敗）が増えていってしまいます。
幸い、プッシュ通知の結果は取得できます。それに合わせてデータを自動的にメンテナンスする仕組みを開発しなければなりません。
プッシュ通知を自前で運用する場合の最大の難点は初期開発コストになるでしょう。すでに既存のシステムがあればそこに組み込む形で作られますが、担当者が自分で配信設定ができる画面を作ったり、その取り消しもできるようにするといった機能も開発しなければなりません。
もちろん自前で作った場合はmBaaSでは難しい自社システムとの連携であったり、とても細かいニーズに応えるといったことも実現できるでしょう。しかしREST APIを使ったり、運用フローを工夫することもできます。
ニフティクラウド mobile backendでは月200万通までプッシュ通知が無料で配信できます。mBaaSを使って素早くプッシュ通知機能を実装してください。