ログマニアックス

日々学んだこと、気づいたことをメモ代わりに残していければ。カバー範囲は割と広めです。

アクセス解析を切り替えるための9つのステップ

b4f051e952d4b304ad511fedf1b2bf42

アクセス解析ソリューション業界は狭い業界ですが、

狭いながらも数多くのソリューションがあります。

SiteCatalystVisionalistのような多機能なものから、

WebAntennaのように集客分析に特化したもの、導線分析に特化したものなど

多種多様です。

特にGoogle Analyticsなどの無料ツールから、

ビジネスの拡大とともに有料ツールに切り替えたり、

逆にコストを抑えることも併せ、無料ツールに切り替えることもよく聞く話です。

このようにアクセス解析を併用したり、

あるいはあるソリューションから別のソリューションに

切り替えたりすることも多いと思いますが、切り替えるのためのステップを紹介します。

導入設定の確認

まずは導入したソリューションが設計通りの計測をできているか、を確認しましょう。

代理店やベンダーを介して導入している場合には、

検証用のツールやチェックシートが用意されていることがあります。

この段階で、集計の単位やコンバージョンの指標など、

最低限の指標が正しく設定され、実際に取得されていることを確認しましょう。

このプロセスを省略すると、

後の各プロセス実施時にトラブルが発生してしまいます。

移行スケジュール作成

これがある意味もっとも大事なステップかもしれません。

全体の移行スケジュールを大いなる勇気を持って設定することが必要です。

サイト・ビジネスによりますが、

アクセス解析の影響範囲は非常に大きい場合もあれば、数人でしか利用していない場合もあります。

いずれのパターンにおいても、たとえば、3ヶ月や2ヶ月と

実際の以降スケジュールを引いた上で、以下に列挙するステップの

スケジュールを作成する必要があります。

このとき、

他のメンバーの意見を十分に聞くことは大事ですが、

意見に必ずしも従うことがよいことではありません。

特に有料ソリューションの場合には、活用しない間もコストが発生します。

勇気を持って、NOといえる部分はきちんと伝え、

既存ソリューションの停止スケジュールもきちんと伝えることが大事です。

利用者教育の実施

このプロセスを含め、以下のステップは順不同なのですが、

ソリューションを切り替える際にはユーザーへの教育は不可欠です。

ベンダーの研修に頼るもよし、オフィシャルマニュアルに頼るもよし、

いろいろな場や機会はあるかと思います。

ベンダーや同一ツールを利用しているメンバーに相談しつつ進めましょう。

ただし、公式のトレーニングを含め、

完璧な教育というのはありません。

(僕が社内で行っているのはなおのほかそうです)

サイトのことや運用のことを誰よりも知っているのは

サイトを運用しているユーザーのはずなので、

教育の資料を基に独自の教育を実施することはきっとプラスになると思います。

モニタリングシートの移行

このステップがもっとも時間もパワーもかかります。

特に大規模なサイト、歴史のあるサイトの場合、

日次・週次・月次、さまざまなタイミングで多種多様なレポートを作成しています。

すべてを移行させていくのは関係者との調整も併せ、

非常に手間がかかり、根気の要る作業です。

数字の取得方法の把握、数値の定義の確認、数字誤差の考え方、

気の遠くなるような作業に思えるかもしれません。

おすすめする方法としては、

まずは一つ一つのモニタリングシートにあたるのではなく、

最初にINDEXを作ってしまうこと。

まずはモニタリングシートのリストのシートを作ってみます。

その上で、

各レポートの作成者や頻度、目的、データ元を確認します。

各レポートを精査すると案外、

必要でない項目や複数のレポートでかぶって取得している項目、

誤った取得内容が見つかるものです。

モニタリングシートとあわせて、

それぞれのシートでとっている指標のリストも作っておくと便利です。

この機会に各指標の定義や、なんとなくとっているだけで改善につながらない指標などは

モニタリングからはずしてしまいましょう。

このステップに関しては機会があればもっと深く掘ってみたいと思います。

集客施策対応

リスティングやアライアンス、アフィリエイト施策への対応も必要です。

モニタリングシートの移行でも触れましたが、

ソリューション間では定義や指標がことなることがあります。

そのため、今までの基準のCPAやCPCが通用しなくなることも多いので、

ソリューションを併用する場合には感覚値をつかんだ上での

移行が必要になります。

また、アフィリエイトやアライアンスで成果で握っている場合には

各パートナーさんとの金銭面も含めた交渉も必要です。

ログデータを利用したシステムの対応

サイトによりますが、

アクセス解析データを用いたシステムを組んでいる場合があります。

営業向けのレポート出力や、リスティング運用データ、

エクセルのマクロやアクセスの類など、

規模の大小はあるものの、

こうしたシステムの改修も必要です。

細かいツールを含めて、

改修する必要があるか、必要ならどうするか、といった点を

検討していくことが重要でしょう。

既存データのダウンロード

このステップは実施する必要がない場合も多いと思います。

アクセス解析はあくまでもトレンドを追うことが重要であり、

個別のデータの連続性自体はそこまで重要ではない、という考えもあります。

ただ、他のメンバーに安心感を与えるためなどのために

「なんとなく」取得しておきたい、

という相談もよく受けるのは事実です。

こうした場合に一度確認してほしいのが、

・過去のモニタリングシートがあればいらないのではないか

・データ取得にかかるコストに大して見合う価値・成果はどの程度のものか。

・過去データを保持するためのコストは見合っているか

上記のようなポイントです。

こうしたコミュニケーションの結果、過去データのDLは不要になることも多いです。

既存ソリューション計測の停止

最近の多くのソリューションは、

PCサイトであればJavascriptのタグ、

モバイルの場合はキャプチャリングサーバーやスクリプト設置などの

実装があります。

特のJSの場合、ほかのタグやスクリプトと干渉しないか、

画面描画に影響がないか、

を確認した上で停止する必要があります。

既存データの削除

上記の8つのステップが終わっていればこのプロセスは

たいしたものではありません。

おもむろにベンダーに連絡して、削除を依頼するだけになります。

まとめ

つらつらとステップを並べて紹介してみました。

特にモニタリングの移行がもっともパワーがかかるポイントだと思います。

ソリューション切り替えにはいろいろな理由があるでしょう。

ただ、究極的な目的はPDSサイクルをまわし、ウェブビジネスを加速化、改善することなのは

結局は変わりません。