バックエンドエンジニアのBoBです。
今回はiOSプッシュを最適化するためには必要不可欠な、Apple Push Notification service(以下APNs)のFeedbackサービスについて紹介したいと思います。

はじめに

iPhoneやAndroidにはプッシュ通知という仕組みがあることは皆さんもよくご存知かと思いますが、より洗練された、効果的なプッシュ通知を送るために自分たちのプロダクトが送っているプッシュ通知を分析する事はとても重要な事です。
今回はiPhoneのFeedbackサービスを利用して、プッシュ通知を送れていないユーザーを把握する事に関して
1. プッシュ通知の意義
2. Feedbackサービスの説明
という2点から紹介しようと思います。

プッシュ通知の意義

iPhoneやAndroidのプッシュ通知は、ユーザーのRetention(再訪率)を高める効果があります。
弊社グロースハックブログの
広告費０円でもDAU１０倍!? ユーザーRetention(再訪率)を最大化する施策10選
の記事にも、Retentionを上げる意義やそのためのプッシュ通知の必要性などが書いてあるのでぜひ参考にしてください。

しかし、ただ闇雲にプッシュ通知をユーザーに送っていてもプロダクトのRetentionを高める事にはつながりません。
プッシュ通知を最適化するためには、実際にプッシュ通知の様々な部分を日々工夫し、その結果どのようなプッシュ通知がユーザーのRetentionを高める効果があるかを分析しなければいけません。
その分析を行うためには様々な数値を正確に知る必要があります。
プッシュ通知改善の為に日々変更を加える部分は大きく分けて以下の2点があるかと思います。
・タイミング(プッシュ通知を送る時間)
・内容/見た目

これらを変更した際の効果を測定するためには以下のような数値を知る必要があります。
・ 何人のユーザー(何個の端末)を対象としたプッシュ通知なのか
・ 実際には何人のユーザーに送信されているのか
・ 何人のユーザーがプッシュ通知からアプリを起動したか

APNsのFeedbackサービスでは、「実際にユーザーに届ける事ができなかったプッシュ通知の情報」を取得することができます。
つまり、上記の例で言うと二つ目にある「実際に何人のユーザーに送信されているか」というデータを知るために必要不可欠な仕組みとなっています。

Feedbackサービスとは？

APNsにはFeedbackサービスという、正常に処理できなかったプッシュ通知に関する情報を返す仕組みがあります。
Feedbackサービスに接続したときに得られる情報は、前回Feedbackサービスの情報を取得した以降、配送に失敗した通知に関するものだけで、Feedbackサービスが保持しているリストは読み取り後クリアされます。

Feedbackサービスの導入方法

Feedbackサービスはプッシュ通知の仕組みを実装していれば非常に簡単に導入でき、使い方次第でサービスのグロースに絶大な効果を上げる事ができます。

1. 各種設定

Feedbackサービスを利用する際は以下のサーバー、ポートにSSL接続します。
key, certの設定はプッシュ通知を送る際と同じpemファイルを設定します。

require 'socket'
require 'openssl'
 
# 開発環境 apns-dev-key-noenc.pem, apns-dev.pem
# 本番環境 apns-prd-key-noenc.pem, pns-prd.pem
context = OpenSSL::SSL::SSLContext.new('SSLv3')
context.key = OpenSSL::PKey::RSA.new(File.read("apns-prd-key-noenc.pem")) # プッシュ通知を送る処理と同じpemファイル
context.cert = OpenSSL::X509::Certificate.new(File.read("pns-prd.pem")) # プッシュ通知を送る処理と同じpemファイル

2. 結果取得処理

ssl通信で結果を取得します。

# 開発環境: feedback.sandbox.push.apple.com
# 本番環境: feedback.push.apple.com
sock = TCPSocket.new('feedback.sandbox.push.apple.com', 2196) # Feedbackサービスのポートは2196で固定
ssl = OpenSSL::SSL::SSLSocket.new(sock, context)
ssl.sync = true
ssl.connect
 
while line = ssl.read(38)  # SSLソケットから38バイト取得する
　# feedbackで取得したデータを用いた処理をここで実装する
  p line.unpack('N1n1H140')
end
 
ssl.close
sock.close

3. レスポンス

上記の結果は以下のような形で出力されます。

[1392300474, 32, "#プッシュ対象のdevice id"]
[1392303094, 32, "#プッシュ対象のdevice id"]
[1392295196, 32, "#プッシュ対象のdevice id"]
[1392301807, 32, "#プッシュ対象のdevice id"]
........

Feedbackサービスから取得できる情報で利用できるものはプッシュ通知対象のdevice idのみですが、この各レスポンスからどのユーザーのプッシュ通知かを判断し、分析をかける事ができま
す。

まとめ

今回APNsのFeedbackサービスによる送信失敗結果の取得方法を紹介しました。しかしここで説明した内容を実装しただけではサービスのグロースには何もつながりません。
ここで取得したデータをいかにうまく使って分析していくかが重要であり、今回紹介した内容はプッシュ通知最適化の入り口でしかないのです。
現にVASILYではFeedbackサービスで取得したデータ以外にも様々なログを用いてユーザーに送るプッシュ通知を分析し、より効果的なプッシュ通知を目指して日々改善しています。

最後になりますが、VASILYでは現在エンジニアを大募集しています！
直近ですとiQONを支えているアグレッシブな技術がどのようなものか紹介する勉強会や、会社での飲み会が予定されています。

【第2回】iQONエンジニアセミナー ～進化し続けるiQONを支えるグロースハック的エンジニアリング手法とは？～

【2/21】「iQON」急成長を支えるエンジニアと話したい人、WANTED

VASILY/iQONに少しでも興味がある方はぜひご参加ください！