ブラウザ

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側に寄せすぎるのはそれはそれでちょっと違和感も感じます。アプリに比べると若干緩い制限の中でユーザーに支持されるのはどれか?という視点で発展していくのが結果的にいいのではという気がします。

Webプッシュ通知はどうあるべき?サイトやプッシュの特性、マイクロモーメントから考えてみました

pushimg2

Chrome42から始まったService WorkerによるWebプッシュ通知ですが、早いもので9月現在Chrome46のベータというところまできました。毎回アップデートのたびにちょこちょこ改善がされています。まだ機能として安定というところまでは来てない感じですが、つい先日Facebookでも利用が始まったりFirefoxUC Browserなど対応ブラウザが増えつつあるという話もありました。となると近いうちに仕様もしっかり決まってきそうなわけで、いい機会なので今後どうあるべきか?という考察を好き勝手に書いてみようと思います。

続きを読む

Webプッシュ対応の中国発ブラウザ「UC Browser」について調べてみました

ucb

先日TechCrunchの記事「Facebook、Googleと協力してモバイルウェブユーザーにプッシュ通知を送信」にて、Webプッシュ通知対応ブラウザとして、Firefoxに加えてさりげなく触れられていたUC Browser。数年前、まだスマホでブラウザが固定化する前にDolphinとかMavenとか試していた頃に見た記憶がありますが、ほとんどノーマークでした。いい機会なのでちょっと調べてみたのですが、メモがてら書いておこうと思います。

UC Browserは中国企業UC Web社が提供するブラウザで、ChromeやSafariがリーチしきれていない中国、インドを中心に普及しています。Google Playだけでも1〜5億DLのレンジで、合計だと調べる限り2012年前時点で10億を突破しているようです。

Wikipediaによると、UC Web社は2014年にAlibabaに買収されており、モバイル検索の会社を合弁で設立したりと、グループの中でもモバイルウェブの先端を追求する役割を期待されているようです。対Baiduみたいなイメージでしょうか。

サービスのほうですが、さすがアジア圏ということでFacebookモードや動画ダウンロード、ADブロックがあったりと、米国企業とはちょっと違うテイストでユーザー目線を貫いている印象を受けます。iOS9で「ADブロックがー!」とか騒ぐのが恥ずかしくなってくるくらいです。

中国のモバイルウェブ周りの競争環境というと、Baidu、テンセント、そしてAlibabaというのがよく話題になります。米国でいうとそのままGoogle、Whatsapp(Facebook)、amazon、という感じでしょうか。これをUC Browserに当てはめるとamazonがブラウザやってるようなイメージですが、amazonは検索領域をやったりスマホやタブレットに進出していますので、現時点で持っていないものだったりこれから押さえたい領域を考えると国は違えど同じような戦略になってくるのかもしれません。

ご存知の通り、アジア圏ではAndroidのシェアが高いので現時点ではWebプッシュを展開しやすいわけです。Chrome主導で始まったService WorkerおよびWebプッシュですが、思わぬ場所で思わぬプレイヤーが活用しまくる、ということになるのかもしれないですね。

FirefoxでWebプッシュ通知が使えるようになるにあたっての雑感

mff

前回の投稿でも紹介しましたが、ついに2015年11月にFirefoxでもWebサイトでのプッシュ通知ができるようになるそうです。現在のところデスクトップ版からということですが、近いうちにAndroid版でもできることになりそうな気がします。iOSはSafariがやるまではダメそうですね。

Firefox、ここ数年はChromeにシェアを逆転されスマホでも存在感がないので正直インパクトは少ないと思います。自分の周りの感覚でもたまに物好きな人がPCで使っている、くらいな印象。以前は拡張機能が豊富とかメリットありましたが、とっくに抜かされていますし・・

というような状況をふまえると、日本国内でのWebプッシュ、事例としてはPCサイトから出てくるんじゃないかという気がしてます。これでMicrosoftが対応したらなおさらそうですね。BtoB向けのサービスなんか相性がいいかも。そして日本はiOSのシェアが高いのでスマホでのWebプッシュは日本でも米国でもなくアジアのどこかでブレイクするのかもしれません。

とりあえずFirefoxにはWebプッシュの仕様確定やService Worker/Javascript周りの発展、およびChromeやSafariのライバルとなることでのやる気促進、そのあたりを期待したいところです。特に今はプッシュ通知内にユーザーごとに異なるデータを載せることができないので、そこが決まってくると利用方法がいっきに広がりそうです。

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のアップデートのたびに、ちょいちょいプッシュ通知周りの実装に追加があるようなので、今のアプリとは違う、インテリジェントな環境になってくるのかもしれないですね。