[&] Notification UX

■ Notification UX：最適なプッシュ通知のための UX 観点

iPhone,Android のネイティブアプリの特権であるプッシュ通知／Notification。
ユーザーの行動を喚起するために、便利に使えるサービスでありながら、
通知の送り方を一度間違えてしまうと、ユーザーに嫌われてしまいます。

そうすると、サービス事業者は失敗を恐れるあまり、
通知を送って失敗するよりも、送らないで済まそうと考えるようになってしまいます。
最悪、通知の方法を失敗すると、
それほど日常的に使っていないアプリの場合「ウザイ」とアプリを削除されてしまいます。
たいてい設定で通知モードを変えられますが、実際はそこまでしません。
Androidの場合OFFの設定が無いアプリがあったり、
iOSではアプリを最初に起動した時に許可を求めますので、
その段階で拒否されてしまう場合もあります。

それでは、プッシュ通知の最適化を考えたとき、どうすれば良いのでしょうか？

■ 時間帯と定番の通知の仕方

スマホを使っている時間帯に通知すると、少なくとも見てもらえます。
（読んでもらったり、アプリを起動してもらえるかは、また別な要素です）。
それらの時間帯は朝の起床時、通勤時、昼休み時間、帰宅時、帰宅後、就寝前。
アプリの開発やデザインに関わる人であれば、いつでも必要な時間スマートフォンを使えますが、
日中、自由にスマートフォンを見たり使えたりするのは、実はごくわずかな職種だけかもしれません。

●個人的なことで
●その人の状況に合った時に
●その人の時間に合った時に
●即時性のあるものを優先的に
●前回送った時から、適切な時間間隔をあける
●情報コンテンツの生成時間が予測できないもの（占いとか天気予報とかはあまり該当しない）
●適切な量、適切な文言で（できるだけ少なく、一瞬で読める量で）
●アプリを起動せずプッシュの文言だけで完結できるとなお良い
●送信対象のユーザーをセグメンテーションしておき、適切なカテゴリに送る

あからさまに一斉通知みたいなメッセージは良くないです。
ゲーム系、毎日使う系のアプリであれば、
アプリを数日間使わなくなったユーザーを再び呼び戻す時に通知を使うのも良い方法。
一方、アプリの起動数と、通知の数は一般的に無関係。
ユーザー全員に送らず、一部に送ることで A/B テストするのもあり。
通知メッセージを送るかどうかの判断は、電子メールで充分か？電子メールによるお知らせでよりも
緊急性があって通知した方が効果が高いか？　というあたり。メールでいいことはメールで。

■ 通知の量と回数

通知の開封率を計測して、送る頻度を調整できると思うのですが、
だいだい一日 1件〜3件ぐらいが適切な量。
メッセージ系アプリ、ゲーム系のアプリはもっと多くても大丈夫。
回数が多い場合は、前回送った時から、適切な時間間隔をあける。

■ コンテキストアウェアネス

Activity Recognition と呼ばれる、スマートフォンを持っている人が今何をしているのか、
どのような状態なのかを知ることで、最適な通知ができるかもしれません。
ジオフェンシングのような位置情報や、ビーコンをトリガーにしたものや、
歩いているのか、乗り物に乗っているのかなど。

●あなた向けの新しい情報が公開された
●何かの事側を忘れないように通知してあげる（リマインダ的な通知）
●ユーザー固有の情報を通知する
●時間が来たこと、日付が来たことを通知する
●セールの時間が来た、タイムセールがあと?分とか「今」の情報
●メッセージ系が着信したことやカウント数が増えたことなどを通知する
●順番待ちのあるもの、ターン性のゲームの番がきたタイミングなど


基本的には、通知メッセージをもらったことで、何かその後に行動を起こすような事柄が良い。

■ Tips

●通知はチラ見ですむように
スマートフォンの場合は1行から2行、多くとも3行。
（iOS 256byte, Android 4096byte 送れるけど、できるだけ少なく済ます）
漢字は多すぎず、適度にひらがなに開いて表記。字幕と同じ要領で。
コピーライティングは、1ピクセルにこだわるのと同じくらい大切です。
腕時計端末の場合は 2語ぐらい、文として読まないで済むぐらいが適切。

●アプリを起動せずプッシュの文言だけで完結できるのが体験としてはベスト
通知からアプリへ誘導できた数を KPIとして計測しがちですが、
本当に良い通知は、プッシュの文言を読むだけで完結し、アプリを開かなくて済むものです。
（メッセージの送信元と最初の数十文字だけ表示されて、だいたい意味が解るとか）

●時差を考慮、言語設定を考慮
もちろん日本以外に展開しているアプリであれば、いっせい送信せず、時差も考慮する必要があります。

●アプリ起動中
意外に忘れがちなのですが、該当のアプリそのものの画面を開いて使っている時に、
そのアプリのプッシュを送ってはいけません。アプリ側でアプリ内画面で見せる工夫をしておきましょう。
（Twitter の公式アプリが良い例）

●ローカル通知とリモート通知を上手く使い分ける

●通知音
デフォルト音ではなく、音を差し替えることもできる。
マナーモードで聞いてもらえないかもしれないけど、うるさくなく、かつ気付くような、充分に吟味した音を使う。
単音ではなく複数の周波数の音が混ざった音の方がうるさいところでも聞きやすい。

●iOSは機種変更した場合は、トークンが変わるので、少なくともアプリを一回は起動してもらわないといけない。

●Androidは OS側で個別アプリの通知を設定できない？ので、アプリの中で設定解除できるように作り込む。

●iOSの通知許諾率は 35%〜60% くらい
リマインダーアプリのように明確に通知が来ることがアプリの本質の場合は無条件に許可するが、
そうで無い場合は、通知許可を止めてしまう場合が多い。
許可率を上げるには、許可を求める前に最初に何が通知されるのかを伝えると良い。
また、アプリ固有の設定画面の中に、通知 ON/OFF を用意しておくと良い。
（単に全体の ON/OFFだけでなく、通知内容や種類を設定できると良い場合もあり）
許諾 ON のユーザーの方がもちろんアプリの継続利用率が高く、アプリの起動頻度も多い。

●アプリのブランディングにもよるが、文字だけではなく、絵文字や記号などをうまく組み合わせて
目立つような通知を送るのも良いかも。

●通知メッセージからアプリを開いた場合、適切なページが最初にすぐ表示されること

●APNs Feedback をチェックして、配信できなかったユーザーをチェックしよう。

■ ノーティフィケーション関連サービス各種

Parse PUSH https://parse.com/products/push
Amazon Simple Notification Service
Growth Push http://growthpush.com/
swrve https://www.swrve.com/
Urban Airship http://urbanairship.com/
popinfo https://popinfo.iridge.jp/
Appvisor push http://app-visor.com/
Pusna-RS (非公開：Recruit Tech)
PushMaker http://pushmaker.com/
CORE http://core-asp.com/
Samurai Notification http://www.conit.jp/product/service2.html
OneSpeak http://isana.net/products/onespeak/
Nifty mobile backend http://mb.cloud.nifty.com/doc/fnguide/push.html
Oracle Push Cloud Service http://responsys.com/marketing-cloud/products/push-IO




■ プラットフォーム依存

iOS はアプリを最初に起動した時に許可するかしないかを決める。
Android はアプリをインストールする時に、決めるので、ほとんどの場合、通知ONの状態。
Apple の場合 Push 通知文に広告を送ると、リジェクト要因になる。

PC Web とスマートフォンなど、複数デバイスを同時に使っているような場合は、
アプリが起動中で無いかぎり、全部のデバイスに通知を送りつけるのが良いと思う。
どれを先に見るのか、送信側からは解らないから。
そして、通知を見てアクションが起こされたら、他デバイスから消えるとベター。
時間差で送信するのが一番いいのかもしれないけれど、まだ充分な検証は出来ていない。
重要な通知であれば、通知が二重になる方が、通知を見逃すよりもマシかもしれない。

■ ヒント

「できる秘書の共通点」みたいな本に、以下のような事柄が書かれていました。
実はそれは最適な通知の仕方と全く同じ要素ではないかと気付きました。
通知の体験をより素晴らしいものにしようと考える人は、
秘書の本を読むと良いかもしれません（秘書検定の本ではありません）。

●相手のことを考える。
●タイミングを読む。
●先読みする。
●感情に寄り添う。
●マネジメントしてもコントロールはしない。
●話しの要点が解りやすい。
●余計なプレッシャーを与えない。

追記■ 通知のカテゴリ ( via. aoki )
●アラーム
●アラート
●リマインド
●レコメンド

■ 追記
●Androidの場合、通知を契機にアプリを起動したかどうか、標準では解らないため、アプリに実装する必要あり。
●プッシュの文言で完結する場合、KPI 取れないのが「勝ち！」だと思うのですが、そうも言ってられない。
通知を ON にしてくれているユーザー数や、プッシュを何本か送っても、通知を OFF に切り替えないで
使い続けてくれているユーザー数で計測。
または、八割のユーザーには開封が必要ない通知を送り、
二割のユーザーには開封が必要な通知を送って、
二割のユーザーの開封率と同じだけの割合で、
八割のユーザーの方も読んでいると考える。
この場合、開封するしないの差は多少あれど、誤差の範囲だと思います。

以上。雑多な考えをまとめたものなので、間違いや、不足点がまだまだあると思います。
追加情報等をお寄せ頂けるとうれしいです！ @yukio_andoh