• ウェブでの新しいお金の払い方 - Web Payments と Payment Request API について

    前回の記事では、フォームを最適化することでウェブの決済フローを改善するアイディアについて書きましたが、今回は新しい標準 API を使ったアプローチについて書きます。 見た目にも違いが分かりやすいものですので、まずはこちらをご覧ください。 デモはこちらからお試し頂けます (実際に商品を購入することはできません。また、クレジットカードなどの情報がサーバーに渡されることはありません)。 これまで使われていたフォームの代わりに、支払い専用のユーザーインターフェースが使われていることにお気付きと思います。実はこの UI はウェブサイトが用意したものではなく、ブラウザが提供するもので、サイト管理者はこれを呼び出すことにより、従来のフォームよりも手軽に、正確な支払情報をユーザーから提供してもらうことが可能になります。今回ご紹介するのはこれを実現する Payment Request API についてです。 Payment Request API は、ウェブでの支払いを標準化しようという一連の仕様である Web Payments を構成する要素のひとつであり、中心を成すものです。Web Payments を構成する要素には下記のようなものがあります。 Payment Request API Payment Handler API Payment Method Identifiers Basic Card Payment Payment Request API には Android 版 Chrome がバージョン 53 から対応していますが、他にも Microsoft Edge や Samsung Internet Browser...


  • モバイルウェブのコンバージョンを改善する - フォーム編

    インターネットが登場して 20 年以上が経過し、時代はデスクトップからモバイルへと移り変わりました。モバイルでは、単に小さな画面に対応しているだけでなく、よりスピード感のある体験が求められています。それは E コマースビジネスも例外ではありません。 モバイルでの決済において、66% がネイティブアプリではなくウェブ上で行われているというデータがあります。検索結果からアプリをインストールしてまで商品を購入するのは手間がかかりすぎるため、そのままウェブ上で決済しようとする人が多いことが原因と考えられます。 ただ逆にモバイルウェブサイトは、デスクトップのウェブサイトと比較として、コンバージョンレートが 66% 低いというデータも存在します。これは逆に言えば、モバイルウェブでのコンバージョンレートにはまだ伸びしろがある、ということも意味しています。 そこで今回は、フォームを改善することでモバイルウェブのコンバージョンを向上する方法を 2 つ紹介したいと思います。 なぜオートフィルは役に立たないのか 商品を購入するに当たり、ユーザーは住所や支払情報などの情報を提供する必要があります。そのために広く使われているのがいわゆるフォームです。ただでさえ埋めるのがめんどくさいこのフォームですが、ユーザーにとってモバイルデバイスの小さな画面でバーチャルキーボードを使って自分の住所を打ち込むのは、苦痛以外の何者でもありません。モバイルでの購入が面倒なので、パソコンから購入した、もしくは諦めた、という経験があるのは僕だけではないはずです。 幸いなことに、最近のブラウザの多くには「オートフィル」と呼ばれる自動的にフォームに最適な情報を埋めてくれる機能が備わっています。これを使えば、ユーザーは自分で文字を打ち込んだり、間違えて何度も修正するなどの手間が大幅に減少します。 ただ、それでうまくいくなら、デスクトップよりもコンバージョンレートが低いはずはありません。つまり、多くのウェブサイトでは、オートフィルが期待通りに動いていない可能性があるのです。何が足りないのでしょうか? オートフィルの仕組み まずはオートフィルの仕組みを説明しましょう。例えば Chrome のオートフィル機能では、一度ユーザーが入力した情報をブラウザに記憶し、二度目以降は繰り返し文字をタイプすることなく埋めることができます。さらに最近は、埋める情報が住所とクレジットカードの場合構造化され、どのフィールドに何を埋めればいいかを自動的に判断するようになっています。 左が Chrome、右が Safari のオートフィル設定 Chrome の場合、ユーザーがブラウズ中に保存した情報を再利用するのに対し、Safari の場合、住所は OS の持つ連絡帳機能を利用して引き出します。 (Firefox や Edge では現時点ではフォームデータの構造化は行われていないようですが、今後同様の方向になっていくと予想されます。) 構造化されたデータ ここで重要なのが「構造化」されている、という点です。言い換えると、情報が何らかの定型に沿った形で、ひとつの塊として扱われているということです。もう少し具体的に言いましょう。Chrome では 住所の場合: 名前 所属 国 郵便番号 都道府県 市区町村 それ以降の住所 電話番号 メールアドレス クレジットカードの場合: カード番号 所有者名...


  • ウェブのプッシュ通知、何がそんなにすごいのか?

    3 月 13 日、Chrome Beta のブログポストが出ました。Android 版 Chrome でプッシュ通知が使えるようになったのが個人的なハイライトです。 「確かにプッシュ通知は便利かもね〜」と思ったあなた、驚きが足りません。のけぞるべきです。小躍りするべきです。 理由を説明します。 ユーザーエンゲージメントが変わる あなたのウェブサイトのビジネスモデルが広告モデルにしろ課金モデルにしろ、ユーザーが繰り返し訪れてくれることは大前提です。通常のウェブサイトやサービスは、そのための策を練ります。そのきっかけをサービス側から能動的に与えることで、ユーザーが戻ってきて、ビジネスは回ります。しかし、そのきっかけを与える方法は、非常に限定されていると言わざるを得ません。 インターネットが普及し始めた当初から伝統的に利用されているのがメール、数年前から利用されているのがソーシャルメディア、最近ではネイティブアプリの通知 (この場合はアプリ自体が戻ってきてほしい場所) 辺りが代表的です。そしてこれらいずれの方法も、スタートラインに立つことすら難しいのが現状です。 メールアドレス 例えばダイレクトメールといった形でユーザーに最新情報を届けることで興味を持ち、戻ってきてもらうにしても、そもそもそのメールアドレスの獲得自体が簡単ではありません。ユーザーのプライベートな情報であるメールアドレスは、大抵の場合、会員登録という形で他のプライバシー情報と合わせて収集されます。そのためサイトは、少なからぬ信頼を短時間の間にユーザーから得られる必要があります。メジャーなサイトですら、多少姑息な方法を使ってでもメールを送り続ける理由を保つ策が練られていたりするくらい、メールアドレスの獲得はウェブサービスにとって生命線です。 ソーシャルメディア 近年流行ってる、いわゆるソーシャルメディアマーケティングは、Facebook で「いいね」や Twitter で「フォロー」してもらうことで、ユーザーのタイムラインに任意の情報を流せるというものです。メールアドレスの獲得に比べれば、ユーザーのボタンクリックひとつで実現できる上、ユーザーが普段見ているであろう「場」に情報を流せるとあり、今まさにメインストリームと言ってもよいマーケティング方法です。 とはいえ、これはあくまでユーザーがその「場」を普段から見ているという前提があって成り立つものであり、必ずしもすべてのユーザーがそういう行動を取るわけでもなければ、そもそもサイトを訪れたユーザーが Facebook や Twitter を使っているという保証はどこにもありません。 ネイティブアプリ サービス提供者がウェブよりもネイティブアプリを選ぶ理由は、パフォーマンスだけではありません。 A year ago, I asked what features made you turn to native. #1 response: push notifications. Today, they're available: http://t.co/wDOKa5qVbf—...


  • HTML Imports - Web Components を構成する技術

    この記事は webcomponents.org の記事とのクロスポストです。 Template や Shadow DOM、Custom Elements を使うことで、機能ごとの UI コンポーネントが実現できるようになることはこれまでに説明してきました。しかし、それらを使ったコンポーネントの HTML、CSS、JavaScript を別々に呼び出すのは、非効率です。 依存関係の解決も容易ではありません。jQuery UI や Bootstrap を思い出して下さい。JavaScript、CSS、Web Font といった各種リソースを、必要に応じて別々のタグに記述しなければなりませんでした。特にタグごとにコンポーネントとして扱うことが想定されている Web Components の場合、状況が複雑化することは簡単に想像できます。 これらのリソースを、ひとつの HTML ファイルにまとめてロードできるのが、HTML Imports です。 HTML Imports の使い方 HTML にまとまったリソースをロードするには、link タグの rel 属性に import、href 属性にロードしたいリソースの URL を指定して、追加します。例えば index.html という HTML から component.html という HTML を読み込みたい場合、このように記述します: index.html <link rel="import"...


  • Custom Elements - Web Components を構成する技術

    この記事は webcomponents.org の記事とのクロスポストです。 HTML は言うまでもなく、ウェブページを構成する最も重要な要素です。しかし、提供される機能が低レベルなため、複雑なコンポーネントを作ろうとすると、途端に div だらけの分かりにくい構造になってしまいがちです。例えば、あなたが必要な機能を盛り込んだ独自のコンポーネントを作れるとしたらどうでしょう?例えばそのコンポーネントに、機能を的確に表すタグ名を付けられるとしたら?既存のタグを拡張して、新しい機能を追加できるとしたら? Custom Elements は、それを可能にします。 Custom Elements とはなにか? Custom Elements は開発者が独自に HTML タグを定義し、サイト上で利用できるようにすることで、繰り返し利用されるコンポーネントを単純化し、再利用する手間を大幅に削減します。 Custom Element の作り方 Custom Element の定義はシンプルです。document.registerElement() の第一引数に要素名を示す文字列を入れるだけ。 var XComponent = document.registerElement('x-component'); これで定義後は HTML 上に <x-component> を使うことができます。 <x-component></x-component> ※ <x-component> は要素の定義前にドキュメント上に存在していて構いません。詳しくは HTML5Rocks の記事をご確認下さい。 Custom Elements をサポートしないブラウザをターゲットにしたい場合は、Polyfill である webcomponents.js をロードしておきましょう。 <script src="bower_components/webcomponentsjs/webcomponents.js"></script> タグ名のルール Custom Element...