Webマーケティングって難しいですか？いえ、単語が難しいだけで、簡単です。と答えている、ユゲタです。
前回に引き続き、EFOをチョッパヤで作ってみた話をするのですが、
今回は、EFOの技術的な話をしたいと思います。
EFOの基本的な機能
まず、EFOと聞いて、一番最初に思い浮かべる機能は、「リアルタイムアラート」と呼ばれる、入力欄に入れる文字列が違う時に、
その項目のすぐ上あたりに、吹き出しが表示されて、どんな文字を入力すればいいかをアドバイスしてくれる、アレです。
こういうヤツです。
確かにこの機能だけで、ほとんどのコンバージョン（登録完了）率は改善するでしょう。
それほどパワフルな機能なんですね。
その他に今回作った機能には、次のようなものがあります。
- [搭載済み] 項目グループ設定
- 条件必須設定
- Submit制御
- Navi表示(float)
- ログ収集モード
- EFO非表示モード
- 郵便番号から住所の自動入力機能(zip-recommend)
- autoload機能（通信容量削減）
ボクの開発ドキュメントからコピペしたものなので、意味のわからない機能もあるかと思いますが、
とにかく、どれも、これまで商用入力フォームを日本で一番見てきた事を自負するボクが、cv率アップには、効果的な機能だと思って構築してみました。
それぞれ簡単に説明すると、
項目グループ設定
複数の項目がセットになって、エラーになるようなケースがたまに（というか結構な頻度で）あります。
例えば、チェックボックスを３つ以上選択するような場合は、この機能を設けないとなかなか汎用的な設定を行うことができません。
条件必須設定
この機能は、EFOを開発する時に、最初に要望された機能だと記憶しています。
例えば、「どういう送信方法でメルマガを配信しますか？」という選択項目があり、「メール」を選択したら、メール入力欄が必須になり、「SMS」を選択したら、携帯電話の電話番号が必須になる
というような場合ですが、こうした分岐的な入力フォームを設けている企業サイトは、おそらく50%以上は存在しているでしょう。（ユゲタ的認識）
Submit制御
ページ内のエラー項目数が0になるまで、送信ボタンを物理的に押せないようにする機能なんですが、
入力サイトの離脱の最も多い原因は、送信ボタンを押した跡、次のページで赤い文字列でエラー内容が書かれているのをみた時に人は、「お役所仕事的対応」と感じて、
その無機質差に嫌気が差して、「もういいや」という風になって、ページを離脱していきます。
これを防止するために、送信させないという仕組みなんですね。
そして、この機能は、デザインにこだわりたいと感じる要素が強いので、スタイルシートをセットできるのもポイントなのかもしれません。
Navi表示(float)
ページ内の入力項目が何個あって、あと何個入力すればいいのか、色々とナビゲーションしてくれる機能は、入力者にとっては、ありがたい機能でしょう。
画面領域の小さなスマホなどでは、必須といってもいいかもしれません。
ログ収集モード
EFOの操作記録をログで取得するモードで、当たり前ですが、サーバー負荷やデータ量が膨大になるので、オフで利用してもいいのですが、できることであれば、全てのログを取得して、
その後、効果計測につなげるのがいいでしょう。
ちなみに、どういう計測ができるのかというと、項目毎の入力時間や、どの項目で間違えた入力が多くされているかというエラー発生率、どういう順番で入力さされているかという流れや、
入力ページに来訪したPV数から、CVページに遷移できた人の数や割合（CV率）、他にもどういう端末で多く入力がされていて、どの端末でCV率が高いのかというデバイスレポート。
ビジネスで使われているページで、こうした情報は、GoogleAnalyticsでは、取得できないですからね？
EFO非表示モード
これは、ABテストと称して販売しているサービスが多いと思いますが、前述した「ログ収集モード」という効果計測をするための機能なんですね。
EFOを実装したときとそうでないときのcv率を見ると、EFOの効果が明確に出ることが明らかになるはずです。
郵便番号から住所の自動入力機能(zip-recommend)
これも最近では、ありがちな機能になりましたが、郵便番号を入力すると、都道府県や住所が自動的に入力されるという便利機能です。
別途郵便番号データリスト管理というサーバー運用が発生しますが、実はそのデータも色々なアルゴリズムが必要になりますが、
簡単にしたい場合は、
「郵便局データ」を元に行うのがいいでしょう。
autoload機能（通信容量削減）
そして、これまでのどのEFO（というかASP全体で）で、実装されていない、ブラウザにおけるプログラムキャッシュ機能を搭載してみました。
通常は、インターネットブラウザ自体にキャッシュ機能がついていて、同じURLからファイルを取得する場合、同じURLであれば、一定期間は、キャッシュデータを参照するようになっていますが、
あまりにもあやふやなキャッシュ保持期間と、デバイスごとの差が開きがありすぎるため、エンジニアの不具合対応の「ブラウザキャッシュが原因です」が、流行語大賞になりそうな勢いです
。
それを、localStorageに、圧縮した状態で保存しておくことで、サーバー負荷も軽くなるし、ネットワーク帯域も軽減される。
結果的にスピードアップにもつながるし、キャッシュ管理も、運用側が自由に行うことができるわけです。
誰も損をしないASP業界の夢の機能なんですが、コレだれもやっていないんですよね。（ユゲタの知っている限り）
なので、うちの会社の専売特許にすることにしました。
要望機能
とりあえず、本番で使える機能は搭載できたので、自分の会社のWEBサイトで搭載してみたので、気になる方は、いじってみてください。
それから、自分的に、まだまだ搭載したい機能は、たくさんあるので、今後も機能追加をして、世の中の入力フォームを塗り替えて行きたいという願望も密かに持っておきたいと思います。
本当にCV率を上げたければ、フォームの構成を改善すべし！
最後に、入力フォームを数多くみてきたボクならではの意見として言わせてもらうと、
「そもそもの、入力ページの構成を見直すことが一番いい成果がでるのにな〜〜〜」
と思います。
確かに、入力フォームの作り直しは、非常にコストも労力もかかるので、EFOツールを導入して、補助的な使い方をするのも悪くないでしょうが、
１年ほどEFOサービスを利用して、自社サイトの入力フォームのポイントが見えたとのことで、ページ（またはサイト自体）を作り直す企業さんもたくさんあったことを思い出しました。
基本的に、レイヤー的にかぶせて使うEFOツールは、よほどのデザインの悪さが無い限り、離脱率が上がるという事はないはずです。
EFOを使ってもらっていたお客さんの中には、EFOのせいで、機会損失が発生したというモンスタークライアントなども、中にはいて、困った経験もあるんですが、
確かに、一昔前のjavascriptタグでは、サーバー障害のタイミングで、ページ処理が止まってしまうという問題がありましたが、
async属性を利用することで、もはや、EFOレイヤーが表示されないだけということで、機会損失は皆無な状態になっています。
改めてEFOという商材が強いと思わせるブログを書いてしまいました。
自分的にも、懐かしさあり、過去のレガシコードの作り直しができて、非常に有意義な期間になりました。
0 件のコメント:
コメントを投稿