ネイティブアプリ

Chrome Dev Summit 2016 が開催、いよいよPWAの活用が本格するかも!?

スクリーンショット 2016-11-16 23.58.02

先週、Chrome Dev Summitがさりげなく開催されていました。日本だとあまり話題になっていない感じですが毎年やっているやつですね。去年の今頃だとこんな記事を書いたりしました。去年はWebプッシュ通知やService Workerなど一つ一つのトピックが細かい印象でしたが、今年はProgressive Web Apps(PWA)ワードで一括りになって前面に出ていました。個別の技術だとCredential ManagementPaymentなど新しめのAPIの紹介がありました。

日本において、スマホでブラウジングしている限りはPWAはおろか、Webプッシュですら普及はまだまだこれからかな。。という感じですが、Chromeはどんどん先に進んでいますね。

ところで先日、Publickeyさんの記事でGartner Predicts 2017の「2019年までに、ブランド保有企業の20%は自社のモバイル・アプリを放棄する。」という気になる項目を見つけました。

以前ブログでも触れましたが、アプリとWebにおける利用時間や頻度には大きな差があるということをふまえるとなるほどと思いました。たいていのブランド保有企業では、ネット上で高頻度かつ長時間過ごすほどの体験を提供し続けられません。となるとアプリとして存在する価値を保持するのは難しく、結果として主要プラットフォームを通じて(広告出稿のかたちで)消費者と接触するしかないということなのかもしれません。ブランド側からするとプラットフォーム依存が深まってしまうわけですが、そこに対する対抗策の一つが、Webとネイティブアプリのいいとこ取りができるPWA化なのかもしれないですね。

Webプッシュ3大ワードからリテンション施策を比較する(Google Developers Summit Tokyo 2016 から)

4月26日に開催された「Google Developers Summit Tokyo 2016」の2日目。その中で「Hey, look at me, I’m Notification」という、Webプッシュ関連の発表がありました。個人的に注目なのが、

  • Timely (タイミング):今送るべき通知なのか?
  • Precise (正確性) :正確に、何についての通知なのかパッと見て理解できるように。
  • Relevant (関連性/具体性):そのユーザーならではの情報を通知する。

の3つのキーワードです。文脈的には今までGoogleがWebプッシュ通知の配信におけるマナーとして伝えてきた内容がベースになっていますが、あらためてワード化されることで、より重視し浸透させたいという姿勢を感じました。

続きを読む

2016年 Webプッシュで起きそうな3つの予測

スクリーンショット 2016-01-13 0.21.39

あけましておめでとうございます。
1月もすでに10日以上経ってしまいましたね。。いかがお過ごしでしょうか。

さて、2015年3月のChrome 42から可能になったService WorkerによるブラウザからのWebプッシュ通知配信、それから1年近く経ちChromeはバージョン47となりました。ここまで大きな変化はまだありませんが、バージョンアップごとに確実に何かが追加されています。
しかしまだ1年たっていないのが個人的にはちょっと驚きです。

Chromium Projectsのページを見てみると2016年はバージョン56までいく予定のようです。そして現行の次となる48、49あたりではカスタムボタンやペイロードによるデータの扱いなど今までなかったタイプの仕様追加が予定されています。56になる頃にはどうなっているのか想像もつかないですが、最近の傾向を見ていると、一方通行的なメッセージではなくWebサイトの機能やユーザー体験の一部を担うような仕組みとして成長していくのではないかなということ。メッセージとして考えれば配信数や到達率、開封率といった指標がメインですが、もう少しエンゲージメント寄りの指標(再来訪率とかプッシュ許諾率など)がベースになってくるのかも。

というわけで今日はせっかくなので2016年中に起きるんじゃないかという予想を3つほどピックアップしてみたいと思います。

続きを読む

ウェブ to アプリ のエンゲージメント強化における、Webプッシュ通知の活用方法

Mobile-phone-apps

先日こちらの記事にも書きましたが、Webとアプリにおけるトラフィックの量と内訳の違いの話が個人的にホットです。両者の利用状況から見ると、Webは接触回数を稼ぎ、アプリは長時間そこで過ごす場になっているというもの。サービス提供者は、アプリ上で過ごしてもらうことで広告などから発生するLTVに対してWeb経由のトラフィック獲得コストが合うかどうかで投資を決定することになります。

続きを読む

Chrome OSのAndroid統合のニュースから考えるWebプッシュ配信のこれから

chrome

個人的には大ニュースだと思うのですが、Chrome OSがAndroidに統合されるというニュースがありました。

グーグル、「Chrome OS」を「Android」に統合する計画か

Googleは「Chromebook」ノートPCに主に搭載されるいわゆる「Chrome OS」ソフトウェアをスマートフォンおよびタブレット向けOSの「Android」と統合する予定だという。

 同報道によると、Googleは、この新しい統合ソフトウェアを2017年にリリースする計画で、2016年に初披露する予定だという。

このニュースを知った後だと、先日あったChromeの通知センター廃止のニュースがより現実的に感じられます。プッシュ受け取り状態のコントロールをChromeに持たなくなりますが、代わりにそれを司るのは個々のサービス側でなく、OS(Android)に集約されていくのかもしれません。とはいってもChromeが動く、特にデスクトップでの環境はまだまだ他社OSの比率が高いので、これからしばらく(デスクトップでのAndroid利用がポピュラーになるまで)は中間的な期間となりそうです。

これらトピックを総合すると、Googleは、プッシュ通知はアプリ/Web問わずOSレベルで管理すべきとGoogleは考えているのでは、と考えました。確かにその方がUXとしても一貫するとは思いますし、メールアプリからメッセンジャーアプリへの移行のトレンドに乗れなかったGoogleとしてはこの場の支配力を高めることでなんらかの復権を考えていそうです。Now on Tapやマイクロモーメントなどのコンセプトを実現する場としても重要ですし。

ただ、個人的にはWebプッシュのような標準的な技術で動く仕組みにおいて管理機能をOS側に寄せすぎるのはそれはそれでちょっと違和感も感じます。アプリに比べると若干緩い制限の中でユーザーに支持されるのはどれか?という視点で発展していくのが結果的にいいのではという気がします。

Facebookの事例から考える、Webアプリにおけるプッシュ通知の許可タイミング

fbpush

先日この記事でも紹介しましたが、Webアプリ版のFacebook(Android版Chrome向け)においてもプッシュ通知が始まりました。使ってみるとわかるのですが、トップページでなく、ログインした瞬間にプッシュ通知許可画面が表示されるようになっています。

ネイティブアプリだと、起動直後に許可画面が表示されることが多いです。最近だと、プッシュで何を送ってくるか(お知らせやコンテンツの更新、イベント開催など)を見せてから通知許可するケースも出てきていますが、とにかく利用の初期段階で許可を取るのがスタンダードです。
※実はFacebookのネイティブアプリはそうでないので、上記の比較には適していないのですが・・

この違いは、先日の記事でもすこし触れましたが、Webとネイティブアプリの利用する時点におけるユーザーとのエンゲージメントの度合いが違うということが一因だと考えました。

続きを読む

Webプッシュと、アプリ向けプッシュ通知のメリット/デメリットを比較してみました

pnc

まだまだこれからのWebプッシュ。その概念やUXはアプリのプッシュ通知がベースになっているのは言うまでもありません。私も人に話すときには「アプリだとプッシュ通知来ますよね、あれをWebサイトでもやれるやつです」なんて言ったりしていますし。そしてアプリのプッシュ通知はポピュラーになってからも数年が経過しており、だいぶこなれてきました。もちろんメリットだけでなく、出し方によっては煩わしかったりとデメリットもあったりします。

そこで今回は、新参のWebプッシュとアプリのプッシュ、どこが一緒でどこが違うんだっけ?という違いをあらためてまとめてみました。アプリプッシュという先人の経験?を踏まえることでWebにおいてもより洗練されたプッシュ通知ができればと思います。

■アプリのプッシュ通知
メリット:
・スマホの機能としてはポピュラーなので説明をしなくてもどんな機能か理解してもらいやすい。
・スマホ画面の中で最もいい位置やタイミングで表示されることが多く、圧倒的に目に触れやすい。
・通知のON/OFFがOSの機能として用意されていて、共通のUIで管理できる

デメリット:
・どのアプリも基本はプッシュを送りまくろうとするので、その経験からそもそも邪魔なものと思われやすい。プッシュする内容もアプリによってまちまちであり、ユーザーが自分にとってどんな情報であるかを認識しづらい。
・メールほどアーカイブ性がないので大量に通知した場合にちゃんと見られない可能性がある。
・あくまで通知なので長めのコンテンツを送るのには向いていない

特性を考えるとメッセージアプリやメールなど、パーソナルな情報や何かの結果を通知するのに向いています。言い換えれば、その人にとっては重要な情報ということですね。

■Webでのプッシュ通知
メリット:
・通知タップ時のアクションをURLベースで指定できるので、アクションの幅を広げやすい。アプリのように他のアプリがインストールされているかを気にする必要もなく他のWebサイトに遷移させることもできる。
・JavascriptをWebサイトに貼るだけでプッシュ通知できる。ネイティブアプリ開発が不要。

デメリット:
・そもそもWebでプッシュ通知しているという認識がほとんどないので、何なのか理解してもらいにくい。
・現在Service Workerに対応しているのがchromeのみ(iOSを除く)なので、通知を受け取れるユーザーが限られてしまう。
・現段階で通知することはできるけど、購読管理の手順など、アプリほど決まってない点がある
・メールほどアーカイブ性がないので大量になった場合にちゃんと見られない可能性がある。(アプリと同じ)
・あくまで通知なので長めのコンテンツを送るのには向いていない(アプリと同じ)

以上、現時点でこのへんかな、というポイントを列挙してみました。

Webのプッシュ通知はアプリに比べると、よりWebの利点が活かせるといえそうです。ブラウザさえあればどんなURLも対応できるので、サービス対ユーザーの関係性だけでなく、Web空間の中でどう作用するかを考えるといいのかもしれません。

また、アプリ/Web共通でデメリットとなるポイントがいくつかあります。これらはプッシュ通知自体の弱点だったりもしますよね。Webプッシュでは今後これらデメリットを果たして改善できるのか、も注目です。最近はchromeのアップデートのたびに、ちょいちょいプッシュ通知周りの実装に追加があるようなので、今のアプリとは違う、インテリジェントな環境になってくるのかもしれないですね。