<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
		xmlns:xhtml="http://www.w3.org/1999/xhtml"
>

<channel>
	<title>dIG iT &#187; Web Analytics</title>
	<atom:link href="http://an-k.jp/blog/archives/tag/web-analytics/feed" rel="self" type="application/rss+xml" />
	<link>http://an-k.jp/blog</link>
	<description>すっかり最近はWeb解析からの最適化などを書くブログ。育児優先のため最近は若干ペースが落ちてますがActiveです。</description>
	<lastBuildDate>Mon, 14 May 2012 05:55:25 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/tag/web-analytics/feed" />
		<item>
		<title>テストパターンを考える時のアイデア その２</title>
		<link>http://an-k.jp/blog/archives/3014</link>
		<comments>http://an-k.jp/blog/archives/3014#comments</comments>
		<pubDate>Thu, 10 May 2012 16:36:41 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Site Optimization]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=3014</guid>
		<description><![CDATA[前回のエントリでは、「改善案」を考えるにあたって、「何ができる？」といったものを洗い出すための図を紹介させて頂きました。２回目の今回は、ある程度「何ができる？」が見えてきた時に、より「具体的に」落としこむ方法について紹介 [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2012/05/3893797302_be0efe4d75.jpg"><img src="http://an-k.jp/blog/wp-content/uploads/2012/05/3893797302_be0efe4d75-150x150.jpg" alt="" title="Am Gleisdreieck By steffenz" width="150" height="150" class="alignleft size-thumbnail wp-image-3031" /></a><a href="http://an-k.jp/blog/archives/2975">前回のエントリ</a>では、「改善案」を考えるにあたって、「何ができる？」といったものを洗い出すための図を紹介させて頂きました。２回目の今回は、ある程度「何ができる？」が見えてきた時に、より「具体的に」落としこむ方法について紹介をさせて頂きます。</p>
<h2>具体的なパターンを探る</h2>
<p>レスポンススピードといったシステム的な改善ではない場合は、ある程度改善案が見えてきたら、テストパターンに落とし込むための具体的なパターンを考えはじめます。</p>
<p>しかし、実際これは白紙ベースで考え始めるのは難しものです。また、既にずっと運用しているサイトなどではアイデアが凝り固まってしまって大きな変化のあるテストパターンが思いつかないこともあります。</p>
<p>これではテストの魅力半減です。今まで自分たちで思いつかなかったものなどでもテストパターンに入れる方が、テストの面白味もその後の効果の改善も期待できます。</p>
<p>ということでよく実施する方法をご紹介します。</p>
<h2>競合や同業のパターンを探る</h2>
<p>テストパターンを検討する時に競合や同業のパターンを確認することは、非常に重要です。競合となるサイトがある場合、多くにおいて似たようなページや機能が存在することも多々あります。</p>
<p>サービスの特性上、競合も含めて併用利用がされている可能性がある場合は、業界で共通のUIや表現にしていくことも1つのアプローチになります。</p>
<p>また、競合以外にもコマースサイトや新規獲得といったサービスやサイトの構造でみた場合に、違う業界で同じサービス形態のサイトを確認することも非常に参考になります。また、同じ業界の別の国のものを確認するのも非常に参考になることが多々あります。</p>
<ul>
<li>競合他社のサイトを確認</li>
<li>同業他国のサイトを確認</li>
<li>同じサービス構造のサイトを確認</li>
</ul>
<h2>UIのパターンまとめを見る</h2>
<p>UI系のテストパターンを検討する場合は、色々な方がまとめているパターンまとめを参考にするのも1つのアプローチとなります。いくつか参考にしやすいサイトを掲載しておきます。</p>
<p>UIについてユーザーベースで集めているサイトや、〜 TOP10やShwocaseといった単語をつけて検索をすることで結構色々なデザインを探り出すことも出来ます。</p>
<ul>
<li><a href="http://discover.usabilla.com/" target="_blank">Discover Usabila</a>（ALL）</li>
<li><a href="http://www.csscody.com/showcase/top-50-button-design-showcase/1063/" target="_blank">Top 50 Button Design Showcase</a>（Button）</li>
<li><a href="http://mobile-patterns.com/" target="_blank">Mobile UI Patterns | Recently Added</a>（Mobile）</li>
<li><a href="http://inspired-ui.com/" target="_blank">Inspired UI</a>（Mobile）</li>
<li><a href="http://www.lovelyui.com/" target="_blank">lovely ui</a>（Mobile）</li>
<li><a href="http://pttrns.com/" target="_blank">Recent / iOS UI Patterns (beta)</a>（Mobile）</li>
<li><a href="http://www.smileycat.com/design_elements/product_pages/" target="_blank">Product Pages Design Showcase | Elements of Design</a>（Product Page）</li>
<li><a href="http://tympanus.net/codrops/2011/07/07/25-examples-of-inspiring-product-display/" target="_blank">25 Examples of Inspiring Product Display in Web Design | Codrops</a>（Product List）</li>
</ul>
<h2>過去のナレッジの確認</h2>
<p>テストを続けている場合などは、過去に実施したテスト結果なども参考になります。見直すと過去に既にダメだったパターンもあったりするので、そういうものをテストパターンから排除することも可能です。</p>
<p>サイトの別のセクションで実施したテスト案などをそのまま転用することができる場合もあるので、本当に過去のナレッジ蓄積は重要です。</p>
<h2>まとめ</h2>
<p>前回のエントリでは、どんなアプローチをしていくかというざっくりでしたが、今回はもう少し具体的なテストパターンを出すための方法をお伝えしました。こういったものから、どういった部分をテストするのか、どこを要素として評価・比較するのかを検討していきテストパターンを洗い出していきます。</p>
<p>冒頭にも書きましたが他のサイトなどを確認することで、新しい視点のテスト案を検討しやすくなります。良さそうだなと思ったり、おっ、と思ったらテスト案に入れてみる。そんな事から最適化は始まったりするわけです。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/3014/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/3014" />
	</item>
		<item>
		<title>テストパターンを考える時のアイデア その１</title>
		<link>http://an-k.jp/blog/archives/2975</link>
		<comments>http://an-k.jp/blog/archives/2975#comments</comments>
		<pubDate>Tue, 08 May 2012 17:26:47 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Site Optimization]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2975</guid>
		<description><![CDATA[サイトの最適化を進めていくにあたっては、最終的に何かしらの形で「改善案」ができそれに対して「テスト」をしていくわけです。

分析ベースであっても、それ以外の課題からだったとしても、この＜改善案＞を作る時は、ホントーにいろいろと考えます。分析→仮説→改善案といった形でその順番を書いてしまうと、直線的なフローになってしまうのですが、実際はもう行ったり来たりなわけです。]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2012/05/238607762_3c2570b432.jpg"><img src="http://an-k.jp/blog/wp-content/uploads/2012/05/238607762_3c2570b432-150x150.jpg" alt="" title="Roller Coaster - Speed Mouse #2 By Stéfan" width="150" height="150" class="alignleft size-thumbnail wp-image-2987" /></a>サイトの最適化を進めていくにあたっては、最終的に何かしらの形で「改善案」ができそれに対して「テスト」をしていくわけです。</p>
<p>分析ベースであっても、それ以外の課題からだったとしても、この＜改善案＞を作る時は、ホントーにいろいろと考えます。分析→仮説→改善案といった形でその順番を書いてしまうと、直線的なフローになってしまうのですが、実際はもう行ったり来たりなわけです。</p>
<p>そんな中でテスト案を組み立てるのは非常に面白いものの「何をすればいいのやら…」ともなってしまうこともあり、そんな未来の自分を救うべく色々なアプローチのフレームワークを整理してみたいと思います。（長くなってしまったので3回ぐらいで）</p>
<h2>どこに手を付けるのか？</h2>
<p>実際にある程度の仮説まで作れてきたとしても、そこから具体的なテスト案に落とし込む時に「何をテストするのか？」という部分でつまずいてしまうことは多くあります。</p>
<p>非常に簡単な例ですが、特定のページの離脱率が非常に高い場合「そのページへの動線を検討しなおすべきなのか、そのページのコンテンツを直すべきなのか、あと何が考えられる？」となってしまったりします。</p>
<p>実際には、より深い分析を実施したり、改善パターンを作る工数なども含めて考えていくわけですが、とはいえある程度どんなことが出来るかは手元にあると便利なわけで、そいうのが欲しいと思った時につくったのが下記の図です。</p>
<p><a href="http://www.flickr.com/photos/an-k/4677666379/" title="Site Optimization Approach Ver.0.2 by an-k, on Flickr"><img src="http://farm5.staticflickr.com/4020/4677666379_8060c6b690.jpg" width="500" height="408" alt="Site Optimization Approach Ver.0.2"/></a></p>
<p>大きくはコンテンツとサイト動線とUIとくくりながら、こんな改善パターンがあるようなぁと洗い出したものになります。それぞれの専門家が見れば、いくつかの粒度が混在してない？ともなる図なのですが、あくまでテスト案を考えるのに良い粒度にそろえてみてます。</p>
<p>コンテンツなのか、サイトの動線なのか、UIなのか、こういったところをから当たりをつけて、どんな事ができそうか検討して頂ければと思います。</p>
<h2>まとめ</h2>
<p>とりあえず初回としてきっかけを作るための図を紹介させて頂きました。実はこれがあるだけでも結構助かることも往々にしてあります。デスクに貼っておいてもいいぐらい。ということで「何が出来る？」と思った時に思い出してみてください。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2975/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2975" />
	</item>
		<item>
		<title>テストの奥行き</title>
		<link>http://an-k.jp/blog/archives/2833</link>
		<comments>http://an-k.jp/blog/archives/2833#comments</comments>
		<pubDate>Wed, 14 Dec 2011 01:25:58 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2833</guid>
		<description><![CDATA[ウェブサイトでテストを行う場合、通常はAとBの比較をしてどちらが良いかを決めていくといったのが良くやるやり方かと思います。

ボタンのデザインはどちらが良いだろうか？文言の位置はどこが良いのだろうか？…　これはこれで効果が出る場合も多くあります。でも、これだけでテストをしていると言ってしまうと半分以上損をしているかもしれません。]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2011/12/50929576_9995e124c0_z.jpg"><img src="http://an-k.jp/blog/wp-content/uploads/2011/12/50929576_9995e124c0_z-150x150.jpg" alt="Which way ? By Zarking Frood" title="Which way ? By Zarking Frood" width="150" height="150" class="alignleft size-thumbnail wp-image-2844" /></a>ウェブサイトでテストを行う場合、通常はAとBの比較をしてどちらが良いかを決めていくといったのが良くやるやり方かと思います。</p>
<p>ボタンのデザインはどちらが良いだろうか？文言の位置はどこが良いのだろうか？…　これはこれで効果が出る場合も多くあります。でも、これだけでテストをしていると言ってしまうと半分以上損をしているかもしれません。</p>
<p>仮説からきちんと組み立てながらテストをきちんと設計することで、より戦略的にその次のアプローチをテストを利用しながら組み立てていくことが出来るようになります。今回はそんな<strong>テストの奥行き</strong>について少し触れてみたいと思います。</p>
<h2>次のアクションのために</h2>
<p>全てにおいてテストは連続的に出来るわけではありませんが、多くの場合、きちんと設定することでテストの次のアクションまで想定することが出来るようになります。とあるページの改善についてどう考えていくかという事を具体的に触れていきたいと思います。</p>
<p>Web解析ツールを利用した分析を行った結果、「<strong>Aというページにはコンバージョンへの貢献率が高いがトラフィックが少ない。もしかしたら、ページAのトラフィックを増やすことでさらにコンバージョンを増やすことが出来るかもしれない</strong>」という仮説がたったとします。</p>
<p>しかし、これと同時に「<strong>ページAは単に特定のニーズが発生したセグメントだけが利用しているだけで、必ずしもトラフィックを増やしたところでコンバージョンは増えないかもしれない。場合によっては全体として減ってしまうかもしれない</strong>」という疑問も沸き上がります。</p>
<p>こういう時にはテストの出番なわけです。まさにこういった疑問を解消するために利用するわけですよ。そして、より戦略的に実施するためにはまず、ちょっと強引なテストをしてツールA自体の効果を測れるようにします。</p>
<h2>テストの戦略</h2>
<p>このような場合、テストを行うことで、その後の方針を決めることが可能です。最初にページAの全セグメントへの効果テストを行います。このテストによりページAは特定のセグメントのみに効果があるものなのか、そうではないかが判断出来るようになります。</p>
<p>もしページAのトラフィック自体を増やすことで、ページAのポテンシャル を効果的に発揮できる（ページAを使ったセグメントとそうではないセグメントでテスト結果を比較した時にページAを参照しているセグメントの方が効果が高かった場合）、その後はページAの誘導に力を入れる判断が出来ます。</p>
<p>逆にページAの利用がやはり特定のセグメントのみに効果がある（ページAの利用とそうではないセグメントとで利用者の方に効果が出なかった）場合、そのページの利用率しだいですが、ここには手を付けずに他の箇所を行うか、ページ自体の改修などを検討することになります。</p>
<ol>
<li>全訪問者へのページ参照の可能性をテスト </li>
<li>結果に合わせて誘導、もしくは別の検討を開始</li>
</ol>
<h2>まとめ</h2>
<p>解析ツールで得られた数字をベースに改善策を検討する場合、そこには何かしらの仮説、戦略が必要になってきます。テスト設計をうまく行うことで、テストには奥行きを設定することが可能性になります。</p>
<p>上記のご紹介した例を最も効率的に利用した例として、ランディングページを利用してコンテンツのニーズを探る検証・テストを数回繰り返し、ある程度効果的な要素が決まったところで、TOPページのリニューアルにも反映させ見事全体のコンバージョンのリフトにつながった例もあります。</p>
<p>TOPページのリニューアルなどでは、担当者の方にとってはリニューアルをすることでコンバージョンが下がるかもしれないというリスクがあり、それは同時に怖さでもあります。テストをうまく利用してリスクを取り除くことで、このリスクを最小限に抑えていくことが出来るようにもなります。</p>
<p>改善策を検討する際は、テストの奥行きについても意識 をしておくことで、より効率的なリソース投下も出来るようになると思いますので、意識をしていただけると良いのではないかなぁと思います。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2833/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2833" />
	</item>
		<item>
		<title>サイトツールの改善ステップ</title>
		<link>http://an-k.jp/blog/archives/2803</link>
		<comments>http://an-k.jp/blog/archives/2803#comments</comments>
		<pubDate>Wed, 05 Oct 2011 03:58:37 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Site Optimization]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2803</guid>
		<description><![CDATA[先日、「<a href="http://an-k.jp/blog/archives/2716" target="_blank">改善のための分析３つのステップ</a>」について記述しましたが、これのもう少し具体的な例を記述してみたいと思います。簡単に３つステップをおさらいすると下記となります。]]></description>
			<content:encoded><![CDATA[<p>先日、「<a href="http://an-k.jp/blog/archives/2716" target="_blank">改善のための分析３つのステップ</a>」について記述しましたが、これのもう少し具体的な例を記述してみたいと思います。簡単に３つステップをおさらいすると下記となります。</p>
<ol>
<li>状況・ギャップを発見する分析</li>
<li>改善案に昇華させる分析</li>
<li>効果を試算する分析</li>
</ol>
<p>さて、今回は「ツールの改善」という視点で「状況・ギャップを発見する分析」「改善案に昇華させる分析」を中心にブレイクダウンした例に触れていきたいと思います。</p>
<p>ちなみに「ツール」とはサイトの目的を達成するために用意されている機能的なものを指しています。コマースサイトであればカート機能や商品の比較、３Dビューといったものなどがそれにあたります。</p>
<h2>状況・ギャップを発見する分析</h2>
<p>状況・ギャップを発見する分析では、まずは大きく２つのポイントで確認をします。ツールの場合は「利用率」と「コンバージョンへの貢献」です。</p>
<p>利用率とは、サイト利用者のうち<strong>どの程度利用しているか</strong>です。当然のことながら良いツールであっても使われなければ意味がありません。ので、状況把握としてまずシェア率を確認します。</p>
<p>ちなみにサイト内にいくつかのツールがある場合は、それぞれの利用率を比較してみると、どの程度そのツールにポテンシャルがあるかどうか目星をつけやすくなります。</p>
<p>そしてもう１つのコンバージョン率の貢献ですね。当たり前のことながら<strong>コンバージョンに紐づいていないツールは無駄ツールの可能性</strong>があります。場合によってそれにより、コンバージョンを失っているかもしれません。</p>
<p>どの程度の人が利用しているかと同時に、どの程度の人がツールを利用してコンバージョンをしているかも出していきます。これも利用率同様にツールが複数ある場合は比較をすると良いと思います。</p>
<p>この２つの分析によりおおよその方向性を見つけ出します。コンバージョン率が高く、利用率が低い場合、利用を増やす方向での検討を行うわけです。</p>
<p>逆にコンバージョン率がそれほど高くなく、利用率が高い場合は、そのツール自体のニーズはあるため、ツール自体の改善をする方向で検討を行うわけです。</p>
<h2>改善案に昇華させる分析</h2>
<p>実際に、ステップ１で方向性が見えたらより具体的な改善案に落としこんでいくわけです。ツールの場合は先程あげた通り、利用を増やすか（動線の改善）、パフォーマンスを上げるかが方向性になってきます。</p>
<p>そのため、ツールの利用状況を把握することで見えてきた方向性に対して、より深い分析を行なっていくことになります。動線の改善を行うのであれば、流入元（利用元）としてどこが多いのかといった部分にフォーカスをすると良いと思います。</p>
<p>この分析を行う際に頭の中では「<strong>どのようなタイミングで、誰が（どのようなステータスの人が）このツールを使っているのか？</strong>」という部分を忘れないようにすることです。これを考えていることで、より具体的な仮説が組み立てやすくなってきます。</p>
<p>最も流入が多い箇所を確認し、そのページやセクションへのトラフィックのうち、何％ぐらいのが遷移しているかを確認します。この割合を確認することで、どのくらい改善出来そうかなどの判断もつけやすくなります。</p>
<p>そして流入が多いセクションの内容も考え、どのようなタイミングで利用されているかを考えて仮説を組み立てと分析を繰り返していきます。</p>
<p>最初のうちは「もうこれ以上はどちらか判断がつかない」というところまで行なってみると良いと思います。そうするとそのうちどこまでの仮説で改善施策として組み立てるかが見えてきやすくなります。</p>
<p>最終的にはテストを行うことで検証するのが良いでしょう。確証があるものに対してもテストを実施することをお勧めします。そうすることで改善の結果の数字をきちんと残せるためです。</p>
<h2>まとめ</h2>
<p>先日行った３つのステップをより具体的なツールの分析として落とし込んでみました。分析や改善の目的をあらかじめ設定することで、おおよそこのような感じで分析から改善施策まで落とし込んでいくことが可能になります。フレームワークの１つとしてぜひ活用して頂ければと思います。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2803/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2803" />
	</item>
		<item>
		<title>改善のための分析３つのステップ</title>
		<link>http://an-k.jp/blog/archives/2716</link>
		<comments>http://an-k.jp/blog/archives/2716#comments</comments>
		<pubDate>Wed, 21 Sep 2011 14:07:51 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Site Optimization]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2716</guid>
		<description><![CDATA[以前にポストした「<a href="http://an-k.jp/blog/archives/2008" target="_blank">分析レポートは４つに分けて考える。</a>」というエントリでは解析ツールの利用を「体重測定」「効果測定」「課題分析」「深堀分析」という４つの視点で整理をしました。

今回はその視点の「課題分析」「深堀り分析」の２つの部分によりフォーカスして、分析を通してサイトの改善につなげる際のポイントとして整理をしてみました。]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2011/09/01.png"><img src="http://an-k.jp/blog/wp-content/uploads/2011/09/01-150x150.png" alt="" title="Don&#039;t Panic iPhone Background By Patrick Hoesly" width="150" height="150" class="alignleft size-thumbnail wp-image-2741" /></a>以前にポストした「<a href="http://an-k.jp/blog/archives/2008" target="_blank">分析レポートは４つに分けて考える。</a>」というエントリでは解析ツールの利用を「体重測定」「効果測定」「課題分析」「深堀分析」という４つの視点で整理をしました。</p>
<p>今回はその視点の「課題分析」「深堀り分析」の２つの部分によりフォーカスして、分析を通してサイトの改善につなげる際のポイントとして整理をしてみました。</p>
<h2>０：目的設定</h2>
<p>今回は大きく３つのステップに分けてみることで整理をしました。そしてこれらのステップを行うに前にまず「目的」を設定し、それらに対して行なっていきます。この目的はある程度具体化さらたものが望ましいでしょう。</p>
<p>例えば「サイトの回遊性を高めたい」でも分析を開始することは可能ですが、目的が大きすぎ、少し分析の方向性がぶれてしまう可能性があります。これに対して「サイトの回遊性向上のために、フリーワード検索の利用向上をしたい」であればより分析の目的を明確にすることができます。</p>
<ol>
<li>状況・ギャップを発見する分析</li>
<li>改善案に昇華させる分析</li>
<li>効果を試算する分析</li>
</ol>
<h2>１：状況・ギャップを発見する分析</h2>
<p>このフェーズでは目的で設定した箇所の状況の把握とギャップの発見を行なっていきます。状況の把握では、分析対象がどの程度なのかを知ります。</p>
<p>先ほどのフリーワード検索であれば、フリーワード検索の利用状況やその検索内容などを知ることが状況の把握となります。ギャップについては以前に記述した「<a href="http://an-k.jp/blog/archives/2375" target="_blank">最適化のために重要なたった1つのこと</a>」で触れているギャップの発見です。</p>
<p>これが結構難しい部分なのですが、何かと比較をして仮説につながる大きな違いを見つけることです。ページとページ、セクションとセクション、サイトとサイト、セグメントとセグメントなど色々な切り口があります。</p>
<p>先ほどのフリーワード検索の場合であれば、商品の詳細ページを見つけるための他の手段、メニュー、特集といった箇所と比較をしてパフォーマンスなどを比較するのが１つの手段になると思います。また、検索されたワードを比較することで見えてくる部分があると思います。</p>
<h2>２：改善案に昇華させる分析</h2>
<p>次のステップとして改善案を作っていくための分析を行なっていきます。ここが一番の肝になる部分です。前のステップで分析した部分から仮説を導きだしていくわけです。</p>
<p>改めて目的として設定している部分に対して、そのままその戦略を実施すべきなのか、そうではない判断をすべきなのかも含めてここで整理をします。</p>
<p>例えば前述のサイト内検索であれば、サイト内検索をより利用してもらうべきなのか、サイト内検索のパフォーマンスをアップすべきなのか、サイト内検索は縮小方向にするのかも検討しながら分析を行なっていくわけです。</p>
<p>分析の結果、サイト内検索のコンバージョンへの貢献は高いものの、それほど利用されていない（当初の目的通り）のであれば、利用する動線を強化する方法を検討するための分析を行います。</p>
<p>サイト内のどこから利用されることが多いのか、どのようなシチュエーションの時に利用されることが多いのか、そういったものを想像しながら分析をしていくわけです。ここで必要に応じてユーザーインタビューや外部評価などを使っても良いと思います。</p>
<p>分析から得られるもののほとんどは「解決策」ではありません。課題点とその改善案のための糸口となる情報です。そのためStep1、Step２といった分析を通して、どのように改善するかを頭に描いていくわけです。</p>
<p>改善仮説を考えるために有効な考えは<strong>「どこから来て」「何をして」「どこに行くのか（行ったのか）」</strong>を考えながら分析を進めていくことです。そして、その中で<strong>「パフォーマンス」なのか「動線（トラフィック）」</strong>のどちらが課題なのかを検討していくわけです。</p>
<h2>３：効果を試算する分析</h2>
<p>ステップ２で組み立てた改善案に対してこれは実際に実施をするかどうかを判断する１つの方法として効果を試算する方法があります。ただ、これは必ず必要なステップというわけではなく、場合によって行うステップです。</p>
<p>効果の試算はあくまで実施するかどうかの目処を決定するための補助です。そのため取得出来るデータに基づきデータの試算をします。体よく言えば「フェルミ推定」個人的には前職の上司の言葉を借りて「緻密などんぶり勘定」です。</p>
<p>つまり、知り得る数字のみを利用しながら期待値を計算していくわけです。これらを計算するにあたっては先ほどのパフォーマンスの改善なのか、トラフィックの改善に分けると考えやすくなります。</p>
<p>パフォーマンスの改善の場合は</p>
<blockquote><p>（現状のトラフィック数×改善したCVR）ー現状のCV数＝改善期待値</p></blockquote>
<p>として導きだすことが可能です。</p>
<p>トラフィックの改善の場合は</p>
<blockquote><p>（改善したトラフィック数ー現状のトラフィック数）×CVR＝改善期待値</p></blockquote>
<p>といった感じで導き出します。</p>
<p>実際にはこれをベースにして分析によって抽出できるデータを利用しながら細かく組み立てを行います。例えばトラフィック改善での計算の場合、「改善したトラフィック数」を導き出すためには、さらにその元となるデータを辿ります。</p>
<p>改善施策として、既にある入口を何かしらの方法で誘導を増やす場合、遷移元のターゲットとなるページからの流入数を確認します。これが流入元のトラフィックに対してどの程度改善できそうかを計算し、結果として「改善したトラフィック数」を算出するわけです。</p>
<p>まぁ、色々とゴニョゴニョする方法があるのですがそれはまた別で記載したいと思います。</p>
<h2>まとめ</h2>
<p>効果の試算については、あくまで参考でしかないのであくまで１判断材料としてみて頂くのが良いです。例えばトラフィック数が増えれば、そこのCVRは少し下がったりする場合もあります。ただ、それを考慮し続けると果てしない旅の始まりになってしまいますので、ある程度の割り切りの中で作っておく必要があります。</p>
<p>かなり長い文章になりましたが、基本的にこれらのステップと分析の目的とを組み合わせていくことで、分析アプローチの整理が出来るんじゃないかなぁと思ってます。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2716/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2716" />
	</item>
		<item>
		<title>FacebookのKPIを考える</title>
		<link>http://an-k.jp/blog/archives/2605</link>
		<comments>http://an-k.jp/blog/archives/2605#comments</comments>
		<pubDate>Wed, 29 Jun 2011 17:32:47 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Facebook]]></category>
		<category><![CDATA[KBR]]></category>
		<category><![CDATA[KPI]]></category>
		<category><![CDATA[Social Media]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2605</guid>
		<description><![CDATA[Facebookで色々と行っているが「そもそもKPIを何にすべきなのか？」という質問をちょくちょく受けるようになってきました。ということで簡単にそこを整理。]]></description>
			<content:encoded><![CDATA[<p>Facebookで色々と行っているが「そもそもKPIを何にすべきなのか？」という質問をちょくちょく受けるようになってきました。ということで簡単にそこを整理。</p>
<h2>FacebookアプローチでのKBR</h2>
<p>Facebookでそもそも何をするのか？という部分ですが、以前のエントリ<a href="http://an-k.jp/blog/archives/2514" target="_blank">Facebookのアクティビティを整理する </a>でも記述していますが、Facebook側でリーチできるユーザーを増やし、最終的にサイトに来訪をしてコンバージョンしてもらうことが基本です。</p>
<p>上記を踏まえて整理をするとKBRは大きく２つに分かれてくるわけです。あ、そもそも「KBR何よ？」という部分については<a href="http://an-k.jp/blog/archives/1675" target="_blank">GoalとKPIに潜むキャズムの乗り越え方 その１</a>を呼んでいただけると。</p>
<ul>
<li>リーチの拡大</li>
<li>サイトへの効果</li>
</ul>
<p>これらに全体のモニタリングを行うための「状況の把握」が加わり大きく３つの軸で整理をすることでKPIが整理しやすくなってきます。</p>
<h2>KPIへの落し込み</h2>
<p>KPIはKBRの達成のための度合いを認識できるような指標群のことだったりします。つまり、先ほど整理した３つの軸「リーチの拡大」「サイトへの効果」「状況の把握」を利用しつつ、何でもかんでもではなく指標をきちんと絞り込んでいく必要があります。</p>
<p>「リーチの拡大」ではFacebook上でどのくらいのユーザーにリーチできているかどうかが重要なわけで、<strong>Facebookページのファン数</strong>や<strong>いいね！ボタンが押下された総数</strong>といったものがKPIになってきます。</p>
<p>「サイトへの効果」では実際にサイトへの流入やコンバージョンへの結びつきを見ます。そのため<strong>Facebookからの流入数</strong>や<strong>Facebookからのコンバージョン数</strong>といったものが指標になってきます。</p>
<p>そして「状況の把握」では<strong>Facebookページのデモグラフィックデータ</strong>や<strong>競合のFacebookページのファン数</strong>といったものを見ることで全体の把握が出来るようになってきます。</p>
<h2>まとめ</h2>
<p>上記以外についても色々データは取得・計測が可能ですが、どれももう少し詳細に分析をするためのものであってKPIにはならないんじゃないかなと考えています。</p>
<p>またソーシャルメディア系では非常に大事なのですが「取れるデータの中で評価をすること」です。そのため上記のKPIなどもそのうち変わる可能性もあるわけです。</p>
<p>といった感じでバーっと整理をしてみました。ご参考になれば。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2605/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2605" />
	</item>
		<item>
		<title>第４回解析しないと！やりました。</title>
		<link>http://an-k.jp/blog/archives/2587</link>
		<comments>http://an-k.jp/blog/archives/2587#comments</comments>
		<pubDate>Tue, 28 Jun 2011 15:52:18 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Event]]></category>
		<category><![CDATA[Social Media]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2587</guid>
		<description><![CDATA[先日、福岡にて解析しないと！を行ってきました。ということで今回はそのフィードバックエントリです。]]></description>
			<content:encoded><![CDATA[<p>先日、福岡にて解析しないと！を行ってきました。ということで今回はそのフィードバックエントリです。</p>
<h2>何を話したの？</h2>
<p>福岡での開催は初めてだったこともあり、なんだか盛りだくさんの内容にしてしまいました。大きくは２つのポイントです。</p>
<ul>
<li>最適化のお作法</li>
<li>解析の最新事例</li>
</ul>
<p>最適化のお作法については大きく２つに分けています。１つがサイト全体の最適化という考え方。もう１つがターゲティングを行う際に必要になるセグメンテーションの考え方について。</p>
<p>また、解析の最新事例ではアプリ計測や動画計測、そしてソーシャルメディアの計測の考え方や出来ることについてなどに触れています。</p>
<h2>反応の反応と資料たち</h2>
<p>もう少し事前に告知していれば良かったかもですがUstreamを見ていてくださった方などのコメントをTogetterにまとめましたのでこちらもご参考くださいませ。</p>
<ul>
<li><a href="http://togetter.com/li/155120" target="_blank">Togetter &#8211; 「第４回解析しないと！ @ D2K福岡」</a></li>
</ul>
<p>また当日利用した資料もアップします。もともと文字をほとんど書かないプレゼンをするので、これだけ見てもって感じの部分も多いのですが下記は今回利用した資料の一部です。参考にはなると思います。</p>
<ul>
<li><a href="http://an-k.jp/t/analytics_night_vol04.pdf" target="_blank">解析しないと！安西資料（PDF：14.1MB）</a></li>
</ul>
<h2>Special Thanks!</h2>
<p>今回のイベント <a href="http://www.d2k-net.com/" target="_blank">D2K</a>の運営は<a href="http://www.pencil.co.jp/" target="_blank">株式会社ペンシル</a>様がメインで行っており、今回もたくさん方が運営スタッフとして参加をされていました。</p>
<p>改めて当日手厚いサポートをしていただけたこと、そしてこのような機会をいただけたことに本当に感謝です！</p>
<h2>ブログに書いて頂いた感想！</h2>
<p>いつも自分の私的勉強ではアウトプットをして頂くようにしてます。ということで書いて頂いたブログエントリーで見つけたもの、TB頂いたものなどはここに記載していきたいと思います！</p>
<ul>
<li><a href="http://tatsuma1484report.blogspot.com/2011/06/d2k70digit.html" target="_blank">Tatsuma1484 Report: D2K第70回セミナー「『解析しないと！diGiT』解析するとサイトからの売上があがる？！に行ってきました</a></li>
</ul>
<p>今後ともこのノマドセミナーである解析しないと！は続けていきたいと思いますので何卒よろしくお願いいたします。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2587/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2587" />
	</item>
		<item>
		<title>第４回 解析しないと！やります！</title>
		<link>http://an-k.jp/blog/archives/2570</link>
		<comments>http://an-k.jp/blog/archives/2570#comments</comments>
		<pubDate>Sat, 18 Jun 2011 14:23:52 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Event]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2570</guid>
		<description><![CDATA[久しぶりに解析しないと！をやります。といっても今回は東京開催ではなく、福岡開催です。

<a href="http://www.d2k-net.com/" target="_blank">D2K（デジタル大名2000）</a>というイベントをやっているペンシルさんにお声がけを頂き今回の 解析しないと！in福岡 を開催することになりました。ありがたいことです。]]></description>
			<content:encoded><![CDATA[<p>久しぶりに解析しないと！をやります。といっても今回は東京開催ではなく、福岡開催です。</p>
<p><a href="http://www.d2k-net.com/" target="_blank">D2K（デジタル大名2000）</a>というイベントをやっているペンシルさんにお声がけを頂き今回の 解析しないと！in福岡 を開催することになりました。ありがたいことです。</p>
<h2>イベント詳細</h2>
<p>今回は福岡なので、正直自分も開催される場所を知らないのですが、下記がイベント詳細になってきます。</p>
<ul>
<li>日程：6月24日</li>
<li>時間：<strong>Open:18時45分　Start:19時～21時30分</strong></li>
<li>場所：エルガーラ７Ｆ多目的ホール（<a href="http://maps.google.co.jp/maps?q=%E7%A6%8F%E5%B2%A1%E5%B8%82%E4%B8%AD%E5%A4%AE%E5%8C%BA%E5%A4%A9%E7%A5%9E%EF%BC%91%E3%83%BC%EF%BC%94%E3%83%BC%EF%BC%92&#038;oe=utf-8&#038;rls=org.mozilla:ja-JP-mac:official&#038;hl=ja&#038;client=firefox-a&#038;um=1&#038;ie=UTF-8&#038;hq=&#038;hnear=0x354191903879c233:0x228a8b69b50b4ac6,%E7%A6%8F%E5%B2%A1%E7%9C%8C%E7%A6%8F%E5%B2%A1%E5%B8%82%E4%B8%AD%E5%A4%AE%E5%8C%BA%E5%A4%A9%E7%A5%9E%EF%BC%91%E4%B8%81%E7%9B%AE%EF%BC%94%E2%88%92%EF%BC%92&#038;gl=jp&#038;ei=6LD8TbD3M4O4vQOZubyqAw&#038;sa=X&#038;oi=geocode_result&#038;ct=title&#038;resnum=1&#038;ved=0CBkQ8gEwAA" target="_blank">福岡市中央区天神１ー４ー２</a>）</li>
<li>詳細：<a href="http://www.d2k-net.com/20110624/" target="_blank">申し込みはこちらのページ</a></li>
</ul>
<h2>こんな事考えてます</h2>
<p>まだ色々と検討しているところではあるのですが、漠然としがちない最適化についてを「最適化のお作法」としてまとめてみようかなぁと思っています。</p>
<p>あとはソーシャルメディア計測をはじめ、最新の解析事情についても触れてみたいと思っています。最新事情については、結構びっくりする事例もあると思いますよぉ。</p>
<p>ということで福岡近辺の皆様（誰）よろしくお願いいたします！</p>
<h2>2011年6月23日追記</h2>
<p>Ustreamを準備して頂いたのでここにも貼りつけておきますね。すごい体制準備をして頂いていて恐縮です。<br />
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="480" height="296" id="utv641926"><param name="flashvars" value="autoplay=false&amp;brand=embed&amp;cid=3740623&amp;locale=ja_JP&amp;v3=1"/><param name="allowfullscreen" value="true"/><param name="allowscriptaccess" value="always"/><param name="movie" value="http://www.ustream.tv/flash/viewer.swf"/><embed flashvars="autoplay=false&amp;brand=embed&amp;cid=3740623&amp;locale=ja_JP&amp;v3=1" width="480" height="296" allowfullscreen="true" allowscriptaccess="always" id="utv641926" name="utv_n_634652" src="http://www.ustream.tv/flash/viewer.swf" type="application/x-shockwave-flash" /></object><br /><a href="http://www.ustream.tv/" style="padding: 2px 0px 4px; width: 400px; background: #ffffff; display: block; color: #000000; font-weight: normal; font-size: 10px; text-decoration: underline; text-align: center;" target="_blank">Streaming .TV shows by Ustream</a></p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2570/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2570" />
	</item>
		<item>
		<title>最適化のために重要なたった1つのこと</title>
		<link>http://an-k.jp/blog/archives/2375</link>
		<comments>http://an-k.jp/blog/archives/2375#comments</comments>
		<pubDate>Wed, 02 Feb 2011 17:54:54 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2375</guid>
		<description><![CDATA[少しばかり釣りなタイトルですがまぁたまには誇張も大事です。オンラインビジネスやサイトの最適化を進めていく中で最も重要なキーワードは1つだけだと思っています。

それは<strong>ギャップを見つけること</strong>です。
]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2011/02/1789216472_2977fb3f8c.jpg"><img src="http://an-k.jp/blog/wp-content/uploads/2011/02/1789216472_2977fb3f8c-150x150.jpg" alt="" title="Watch the Gap By CarbonNYC" width="150" height="150" class="alignleft size-thumbnail wp-image-2378" /></a>少しばかり釣りなタイトルですがまぁたまには誇張も大事です。オンラインビジネスやサイトの最適化を進めていく中で最も重要なキーワードは1つだけだと思っています。</p>
<p>それは<strong>ギャップを見つけること</strong>です。</p>
<p>最適化を進めていく中で行う事は細かくみれば沢山ありますが自分が最も重要視しているのが<strong>ギャップ</strong>です。このギャップは色々な所で利用出来ます。</p>
<p>例えばサイトの課題を見つける時には戦略や仮説とのギャップを探します。そこから新たな仮説を見いだしながら次のアプローチや改善策を検討していくわけです。</p>
<p>前回のエントリ（<a href="http://an-k.jp/blog/archives/2324" target="_blank">最適化をする前にやるべき３つのこと</a> ）ではKBRやハイレベルサイトマップについて触れましたが、これらはギャップを見つけだす為に必要なものです。</p>
<p>これらを整理しておくと、KBRであれば戦略とのギャップ、ハイレベルサイトマップであれば想定していた動線とのギャップを見つけていく為のアンカーになるわけです。</p>
<p>ランディングページの分析であれば、入口数が多いのに、直帰率が高い箇所が最初に改善をしていくべきところです。</p>
<p>また、ちょっと視点を変えると、セグメンテーション別の分析では、いかに複数のセグメンテーションで異なる部分を見つけるかがポイントです。そのギャップがターゲティングをしていく隙間です。</p>
<p>このギャップが大きければ、大きいほどターゲティングする価値を作りだすことが出来るわけです。逆にギャップがないなら無理にセグメントを分ける必要もないわけです。</p>
<p>戦略とのギャップ、想定とのギャップ、セグメント間のギャップ。このギャップがどこにあるかを見つけることが、最も重要なキーワードだと思うわけです。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2375/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2375" />
	</item>
		<item>
		<title>ランディングページは生きている。</title>
		<link>http://an-k.jp/blog/archives/2344</link>
		<comments>http://an-k.jp/blog/archives/2344#comments</comments>
		<pubDate>Wed, 26 Jan 2011 03:57:00 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Landing Page]]></category>
		<category><![CDATA[LPO]]></category>
		<category><![CDATA[Web Analytics]]></category>
		<category><![CDATA[Writing]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2344</guid>
		<description><![CDATA[Markezineで書かせていただいている連載の第３回が公開されました。今回は「<a href="http://markezine.jp/article/detail/13230" target="_blank">ランディングページは生きている ― 作りっぱなしにしないために知っておきたいページ設計・改善の3ステップ</a>」です。]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2009/11/markezine.png"><img src="http://an-k.jp/blog/wp-content/uploads/2009/11/markezine-150x150.png" alt="" title="markezine" width="150" height="150" class="alignleft size-thumbnail wp-image-1525" /></a>Markezineで書かせていただいている連載の第３回が公開されました。</p>
<p>今回は「<a href="http://markezine.jp/article/detail/13230" target="_blank">ランディングページは生きている ― 作りっぱなしにしないために知っておきたいページ設計・改善の3ステップ</a>」です。</p>
<p>１回作って終にせずに、ビジネスやサイトの最適化を見据えたページやサイトの構築のあり方を考えた時に、どうアプローチ出来るか？という部分をランディングページを題材に書いてみました。</p>
<p>実際にこの方法についてはいくつかの実例もあるのでオススメだったりもします。個人的にはランディングページを作成する制作サイドの方にも読んでいただきたい内容だったりしますので是非。</p>
<p>次回はこの事例について具体的に触れていく予定です〜。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2344/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2344" />
	</item>
	</channel>
</rss>

