サイトを最適化をしていくにあたり、途中経過、結果をナレッジとして落とし込むことも組織として重要なポイントと言えます。

ここについては私が関わる様々なところで、色々な検討をされているところもあれば、逆にあまり行っていないために、同じようなテストをサイトごとに行ってしまっていたというケースもあったりします。

テストを行うこともタダではありません。制作や改修といったコストに影響もします。「既に過去に行ったことがある」 「グループサイトで既に実施」などといったものを再度検証してしまっているのは会社として見たときに非常にもったいないコストになってしまっているとも言えます。

さて、一言にナレッジといってもどのような事が、ナレッジと言えるのでしょうか？ ここにはいくつかのステップがあると考えています。まず、行ったものを記録するという行為です。そもそも何故テストを行ったのか、それは成功したのか、失敗したのかなどを書き起こす必要があるわけです。ちなみに失敗も記載しておくことが大事です。その失敗を今後は行わないために。

これを後で実施しようとすると、年末の大掃除のように時間を大きくとって行う必要があるわけですが、そんなころにはテストの仮説なんてものは忘れてしまっています。鉄は熱いうちに打てです。テストが終わった時には評価を含めてきちんと落とし込む必要があります。もうこれはテストにかかる工数を見積る時にとっておいた方が良いです。

さて、次にドキュメント化されたものをシェアする必要があるわけです。同僚、上司、未来の担当者など様々な場合が考えられます。上司からしてみれば完結でわかりやすいもの、未来の担当者からしてみれば、必要な時に検索出来ることなどがあげられます。

難しいですね。

それぞれをパワーポイントでまとめることもさることながら、社内にWikiやブログを用意してシェアしていくことも良いと思います。 パワーポイントを作りつつ、共有サーバにアーカイブしてWikiからリンクを設置するといった方法も良いかもしれません。

さて、テストが終わり、それが成功だった場合、もう1つタスクが残っている場合があります。それが横展開です。先ほどのナレッジシェアも横展開と言えば、横展開なのですが、ここでは先ほどのものとは変わってきます。

テストをきちんと設計した場合、このテキストが効く、このコミュニケーション方法が効くといったものがテスト結果から読み取れます。もしランディングページで実施したメッセージのテストであれば、サイトのTOPページやメール、リスティング広告にも流用出来る可能性があります。

ランディングページで行ったテストが他のチャネルや場所に横展開出来るなんてすばらしいことじゃないですか。だって、その人たちはもうそのテストしなくていいんですから！（ちょっと洋書の翻訳本風）実際にそれがきちんと展開できれば、他の場所で同じことを行っていたかもしれないことを、1つのテストで済ませることができればわけです。これはやっぱり会社のコストという面からも非常にHappyです。

つらつらとやっておいた方が良さそうな内容を挙げてみたわけですが、これらを実施しようとしたらやっぱりプロセスとして組み込んでおいた方が良いわけです。じゃないと忘れちゃいます。ドキュメント化であれば、それを書き終えてテスト終了としておき、必ずアーカイブまですることを義務付けるとか、なんだたら関係者で必ずレビューをする時間を設けておくとかでも良いと思います。

シェアの部分は上のアーカイブができていれば良いわけですが、今度はその逆ですね。テスト案を考えられます時に似たようなケースがあるかをきちんと検索して探すことが求められるわけです。つまり、やっぱりですよ、テスト案をアーカイブする時は、検索されそうなキーワードをメタ情報として登録しておかないとダメなわけですよ。

そして、横展開です。これは全てを管理しているようなコアチームのようなところがあるのであれば、そこが責務を追うというのでも良いと思いますが、定期ミーティングを設定し強制的に何かシェアをする場にしてしまっても良いかもしれません。定期ミーティングを設定するって、結構それだけでもものごとが進むんですよね。たまに形骸化しますけど。

ということで、あまりまとめながら書いていないので無駄に長くなりましたが、ナレッジシェアしていこうよという話しでした。

※おそらくこんな話はどこぞのナレッジマネジメントの本などを読めばある程度出ているかもしれません。

Cube Model Beta

下の図がCube Model（Beta）になります。Cube自体がサイト全体というか管理みたいなもので、図の右側から訪問があるイメージです。

Cubeの下側（緑色）にあたる部分は、「サイトのベース（中長期的視点）」にあたる部分です。そしてCubeの上部（黄色）が「キャンペーン／プロモーションなど（短期的視点）」です。

ベース部分

先程、ベース部分は中長期的視点と書いていますが、これはKBR型KPI（KBRが何たるかについてはGoalとKPIに潜むキャズムの乗り越え方 その１あたりから読んでいただけるとよいかと）にあたる部分でもあります。この部分は大きく流入部分（entry）とサイト内部（path flow）に分けています。

サイト流入（entry）については全体バランスや全体予算などを管理する必要があり、これらはキャンペーンの実施などとは別に実施されている必要があります。

また、前々回のエントリで触れた中長期的に向上施策を行う必要がある、自然流入増加などもSEO対策として実施する必要があり、その部分についてもこのベース側のサイト流入での管理となるかと思っています。

またトラフィックの後ろ側にあるのが、サイト内部（path flow）なわけですが、ここでは、一般的なサイトのUIであったり、機能、フォームなど、サイト共通的な部分についてポテンシャルをアップする部分になります。

全体としてサイト全体のコンバージョン率が大きな指標であり、その中でより全体のフローを良くしていくための管理です。

キャンペーン部分

キャンペーン部分はより短期的な視点になります。ベース部分と違い流入に対して縦長に切り分けているのが特徴です。

キャンペーンの場合は、短期的かつ結果へのコミットも非常に重要になってきます。そのため流入だけ確保できました、あとはサイトよろしく！ではなく、きちんと結果についてもコミットしていく必要があります。

特にきちんとセグメントをターゲティングして行うキャンペーンの場合、それらセグメントの良し悪しやターゲティングなども行っていく必要があります。また、サイト外部と内部でキャンペーンをうまく相互活用していく必要があります。

そのため流入部分からサイト内部まできちんとみていくことが必要になり、それが複数本ながれるということで、縦長に分かれている図にしています。

まとめ

このCube Modelは自分の中でかなりしっくり来ている図だったりするのでご紹介しました。KBR型KPIとKGI型KPIとの区分けとしても非常にわかりやすいかと思いますので、何かサイト施策を考える際の一助となれば幸いです。

「サイトのポテンシャルを最大限にすること」

ポテンシャルのとらえ方は様々で、現状のトラフィック（集客予算）の中で最大限の効果(コンバージョン）を達成すること、や、現状のコンバージョンを維持しつつ、集客予算をより下げることもあります。

最適化の視点ではポテンシャルの最大化です。しかし、サイト全体で見れば、ポテンシャルを最大化することだけではなく、合わせてトラフィックを確保していくことで、始めて全体的なゴールの最大化を計ることが出来るわけです。

ポテンシャルの最大化を少し分解

ポテンシャルを最大化は深く掘りさげていくと果てしないわけで、まぁ、結局これが自分の仕事のほとんどなわけでして、ほんの少しだけ。

さて、このポテンシャルの最大化ですが、サイトのユーザビリティ強化や機能追加／改善、フォーム最適化などを様々なベースとなる部分を指しています。

また、自分の中では「広告予算を利用しないトラフィック（ブックマークや自然検索流入など）」や「サイトブランド」などもここに含んでいます。

これらが達成できれば、サイトのコンバージョンを減らさずに広告予算を減らしたりもで、かつ、中長期施策の中で行われ、中長期的に効果が持続する可能性が高いものだからです。

だからサイトのベース。これです。

トラフィックの確保を少し分解

トラフィックの確保といっても、上記のような自然検索やブランド力をあげることでトラフィックを増やす中長期的施策もあれば、短期的にはキャンペーンなどによるトラフィック確保があるわけです。

これらは以前に「GoalとKPIに潜むキャズムの乗り越え方 その２」で触れたKBRから直接落とし込んだKPI（KBR型KPI）とKGIから落とし込んだKPI（KGI型KPI）はそれぞれ、これらにも当てはまります。

前者のような中長期的施策については、サイトのベースを向上させる、KBRを直接達成するものに近いという部分でKBR型KPIであり、キャンペーンなどは短期的かつ、直近の目標値を達成するために行われることが多いことから、KGI型KPIと言えると思います。

どこを目標に置いているかで、期間的なものも違いますし、評価や分析の方法もこれらで変わってきます。

まとめ

ちょっと長くなってしまったので、いったんここまでで。ポテンシャルの最大化とトラフィックの確保的な部分は、結構難しくて、場合によっては組織的な部分も考える必要もあったりします。

しかし、これをきちんと捉えておき、自分の施策で何をしているかを意識しておくことで、オンラインマーケティングを行ううえでのとっちらかりは大分押さえられるような気がします。

追記：2010年5月11日

このエントリの続きを「サイト運用と解析の関連をモデル図にしてみた」として書きましたので合わせてご参照頂ければと思います。

ということでそのあたりの話を。

プロセスを2回転目、3回転目と続けて回し、かつきちんと最適化されるように進めていくには（いまのところ思いついたのが）大きく２つのポイントがあると思っています。

１：次のPlanまで計画しよう

実際に施策を行っていくにあたって、計画をして、実行していくというフローは日々起きているわけです。キャンペーンを新たに行うのであれば、必要なコンバージョン数やそれに伴う集客数を計算し、広告の予算を決定したり。

最終的に期間が終われば、「何件のコンバージョンを獲得し、目標を120%達成しました」などという報告があがるわけです。でも、これではこのキャンペーンを実施した際の、失敗や成功が次に生かせないわけですよ。同じものを繰り返していくだけ。

マーケティングの”手法”で重要なのは「トライ＆エラーを繰り返しながら、良い方法を残し活用していくこと」です。

先ほどの例では、結果が良かった施策はわかっても、なぜ良かったか、次の施策をやる時に応用できる部分が見つからないわけです。この淡々とした施策の報告を乗り越えていくためには、ちょこっとだけ施策計画時に次のPlanまで考えて検討しておくだけで変わってきます。

「この施策が終わったら、こんな事がわかるから、そうしたらそれを使って次の施策ではこういうことができるな」という感じです。

テスティングを行っていくときも同じです。バナーのA/Bテストを行って、そのテストでAが良かった、Bが良かったがわかっただけではテストの意味が半減というかそれ以下です。

AとBを比較したときに、Bが良かった結果「××のセグメントにはBで利用したキャッチコピーの方がコンバージョンに結び付きやすいことが分かった。メールなどでこのキャッチコピーの利用することでより、同じ効果が見込める！」になった方が良いわけですよ！

特にテスト計画を行う際は、結果が良かったとしても、悪かったとしてもきちんとナレッジに落とし込めるような設計が非常に重要です。（というよりもテストは計画が8割）

ということで長くなりましたが次のPlanを計画しましょう！！

２：「なぜ？」を共有しよう

サイトの運営にかかわる人数が増えたり、複数サイトを運営しているサイトの場合は、ナレッジ共有の方法も非常に重要になってきます。最近は結構、実施しているというお話も多く聞くようになりました。ここで気をつけたいのは共有する内容です。

共有する側は「○○を実施したらコンバージョン数が何ポイント良くなりました！」というところだけをついつい共有してしまいがちです。かつて自分も行った経験があります。

しかし、ここで成功した結果と合わせて重要なのは「なぜ？」という部分です。「なぜその方法を実施しようと思ったのか？」という組み立ての背景です。

「なぜそう考えたか？」という部分を共有することで、違う施策やサイトであっても、組み立てのロジックを当てはめて結果別の結論を導く可能性もあるわけです。

ここを共有しておかないと、サルまねのように同じことだけを理由もなく実施してしまい、「どこどこの事例で良かったと聞いたから…」という半ば都市伝説的に取り込むことになってしまうわけです。

それじゃもったいないですよね！なので共有するときの「なぜ？」も大事！

まとめ

ということで思いついた2つのポイントについてまとめてみました。細かく見ればまだ色々と出てくると思いますが、この２つのポイントも大事ということで。

せっかく改善プロセスを回しているのに、1回転しかしなかったり、グループにそれをうまく共有できていなかったりってすごくもったいないですよね。ということで、改善プロセスをすでに回されている方などは、こういうったポイントを意識して頂くと良いんじゃないかと。

今回は個人での協力で、Webガバナンスについて話すことになってます。Webガバナンスってなんぞや？という話もなきにしもあらずですが、ようは今までイチ企業の解析担当者としてどんなことをしてきたかを話す感じです。

ステータスとしてはまだ募集になっているみたいですが、既に1日目が先週終わっているという感じなので、今さらここに書いたところで…ということもあるのですが、まぁ、記録の１つということで。

ちなみに、このところブログの更新頻度が落ちているのは、「これ用の資料を作成してたからではありません」とは言いません。

アクセス解析以前

アクセス解析ツールを導入する前は、図のように計画があって、制作があって、訪問者に使われるということになります。

細かいステップはどうであれ、およそどこもこんな感じだと思います。この時の矢印の方向は一方通行なんですよね。

だから、常に計画（PLAN）は正しいだろうという仮説のもとに動いて、結果独りよがりになりかねない。

アクセス解析以後

アクセス解析ツールを導入すると、利用者の行動というのを収集するわけです。

これをアクセス解析担当者が数字の検証するわけですね。これを見ると、先ほどの一方通行ではなく、サイクル的にまわることがわかるかと。

これが円になることで、サイトが成長しやすいものになるんですよね。

２つのフィードバック先

さて、ここでもう１つポイントとなるのが、分析したあとの矢印の方向です。

自分としては数字のフィードバック先は２つあると思っていて、１つが計画（PLAN）の上流部分です。そして、もう１つとして制作（CREATIVE）の部分です。

数字がフィードバックされて計画（PLAN）の見直しがされた場合、もちろん制作（CREATIVE）の部分にも影響が出るわけです。

しかし、計画（PLAN）をスキップして制作（CREATIVE）へのフィードバックもあると思ってます。

これは計画（PLAN）を遂行するために、よりよいデザインなどを求めていくフェーズといった感じでしょうか。

数字を検証する人はこれを１つのツールから見分けていくわけです。だから、数字だけわかってても、マーケティングだけ分かってても、制作だけわかってても難しいんですよね。

まとめ

これをツールでうまく整理していくことで、それぞれの担当者に必要な数字だけを出せるようにすることも出来ます。

そうすることで選り分けがの手間というのはなくなるわけですが、その設定は誰かがやらなければならないわけで…やっぱり大変ですね。

日本では難しい？

下のリンク先はAvinash Kaushik氏が書かれたWeb Analytics AN HOUR A DAYという良書からの引用翻訳文が載っています。

Insight for WebAnalytics: アクセス解析を最終的には社内でやるべき3つの理由

個人的には自分もこの意見には賛成派なのですが、実際問題難しいなぁと思う部分もあったりするわけです。それが日本の企業風土という部分かなぁと思っています。

大きな企業になればなるほど、様々な部署を経て役職が上がっていくのが日本の流れかなぁと思ってます。もちろん、そうではない企業もありますが、今まで接してきた限りでは多いのかと。

そうすると、実は担当の方も結構頻繁に入れ替わりがあるんですよね。Web担当者になっただけでも、業務知識プラスWebの知識が必要になるわけです。アクセス解析の場合は、さらにそれらの知識をベースにしてモノを語ることが多い部分だと思ってます。

とすると、慣れてきてアクセス解析をある程度使いこなせるようになったころには「異動…」ということにもなってしまいかねないんですよね。

このあたりが悩ましい部分だと思ってます。

外部で見ることが出来る範囲

リンク先の部分でも書かれている通り、アクセス解析で知り得るデータというのは意志決定に利用するための一部であるわけで、その他の社内データというのは外部コンサルタントはほとんど見ることが出来ないわけです。

ある程度は一時的に見られるようにしたとしても、全ての意志決定を行う際にコンサルタントに来てもらうわけにも行かないわけです。

ここまでが現状。

じゃあ、どうしたら良いかという部分ですが、これが難しい。あくまで個人的な見解として書きます。基本は企業規模（もしくはサイト規模）によって分けるのが良いのかと。

まず、ある程度の規模がある企業では、グループ会社に委託するのが１つの方法かなぁと思ってます。大きな企業であれば、システム部門をグループ会社として持っていることが多いわけです。そして、そもそもが専門部隊の集まりなので、本部よりも異動タームは遅い（はず）。そうすることで、ナレッジと社内データを組み合わせたシステムが作れるわけです。

じゃあ、中企業になるとどうするかというと、どのくらい運営しているかにもよりますが、基本は専任化。異動も少ないですしね。というよりも、上層部が専任意識を持ち動けばおそらく大丈夫。

小規模な企業の場合は、専任化と外部コンサルを利用する方法のどちらでも良いかと思ってます。これはサイト運営に関する意志決定がまだ少ないだろうということで、そうしています。ある程度、それが会社として決定する事項が多くなるのであれば、やっぱり専任化なのかなぁとも思います。

まとめ

ということで、ホントに主観ベースで理想を書いてみました。実際に、これからの話なので、どれが最適なのかは自分もよく分かりません。

ただ、アメリカでのWebガバナンス論については、企業風土が大きく違う日本にそのまま当てはめることは出来ないというのは絶対だと思っているので、その違う風土の中で、日本なりの最適化論がうまく見つけられれば良いのかなぁと思ってます。