<?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; A/BTest</title>
	<atom:link href="http://an-k.jp/blog/archives/tag/abtest/feed" rel="self" type="application/rss+xml" />
	<link>http://an-k.jp/blog</link>
	<description>すっかり最近はWeb解析からの最適化などを書くブログ。育児優先のため最近は若干ペースが落ちてますがActiveです。</description>
	<lastBuildDate>Wed, 14 Dec 2011 01:26:16 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/tag/abtest/feed" />
		<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[Headline]]></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>1</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/2230</link>
		<comments>http://an-k.jp/blog/archives/2230#comments</comments>
		<pubDate>Mon, 22 Nov 2010 16:04:55 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=2230</guid>
		<description><![CDATA[いくつかの方法を検証して、良いものを選択していく。これが最適化のプロセスです。

このコアとなるのが、テストです。テストを行っていくことって最適化プロセスをドライブさせるものだったりします。

しかし、テストの文化ってなかなか企業に根付きにくいんですよね。ということでこのテスト文化について感じる雑感など。]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/wp-content/uploads/2010/11/33413040_0e17c93611_b.png"><img src="http://an-k.jp/blog/wp-content/uploads/2010/11/33413040_0e17c93611_b-150x150.png" alt="" title="Stopalicious 2 by CarbonNYC" width="150" height="150" class="alignleft size-thumbnail wp-image-2232" /></a>いくつかの方法を検証して、良いものを選択していく。これが最適化のプロセスです。</p>
<p>このコアとなるのが、テストです。テストを行っていくことって最適化プロセスをドライブさせるものだったりします。</p>
<p>しかし、テストの文化ってなかなか企業に根付きにくいんですよね。ということでこのテスト文化について感じる雑感など。</p>
<h2>何故テストか？</h2>
<p>Avinash Kaushikの <a href="http://www.amazon.co.jp/gp/product/0470529393?ie=UTF8&#038;tag=apgmap-22&#038;linkCode=as2&#038;camp=247&#038;creative=7399&#038;creativeASIN=0470529393" target="_blank">Web Analytics 2.0</a><img src="http://www.assoc-amazon.jp/e/ir?t=apgmap-22&#038;l=as2&#038;o=9&#038;a=0470529393" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" /> でもCreating Nurturing a Test Cultureという項目があるぐらいで、＜テストをする文化＞根付かせるのは難しいのは、良く起きる課題の１つだったりします。</p>
<p>しかしながら、Webで最適化を推進するにあたり、テストの概念ははずせないとも言えます。「<a href="http://www.amazon.co.jp/gp/product/4163697705?ie=UTF8&#038;tag=apgmap-22&#038;linkCode=as2&#038;camp=247&#038;creative=7399&#038;creativeASIN=4163697705">その数学が戦略を決める</a><img src="http://www.assoc-amazon.jp/e/ir?t=apgmap-22&#038;l=as2&#038;o=9&#038;a=4163697705" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />」でも力強く書かれている部分でもあるのですが、Webはとくかくテストがしやすいプラットフォームなんですよね。</p>
<p>道沿いにあるような看板でテストをするとなると、同じ条件で、違う内容の広告はテストしにくいですし、結果の評価も街頭インタビューとかになってしまうわけです。</p>
<p>また、リアルで少し精度の高いテストを行うとなるとダイレクトメールとかになってくるわけですが、それでもやっぱり手間がかかってしまう。</p>
<p>ということで、ランダムにその人だけに表示している内容を変えることが出き、クリエイティブのコストも比較的安いウェブは、テストを行う土壌としては最適なわけです。</p>
<h2>テストをすること自体の壁</h2>
<p>さて、テストの文化を作っていくにあたり、まず、最初の壁が「テストすること自体」の壁だったりするわけです。</p>
<h3>対マーケティング部門</h3>
<p>よく成功体験ということが言われるのですが、これも１つ重要な要素で自社のサイト内でテストでの成功体験をしていただくことは非常に重要です。</p>
<p>しかしながら、そのテスト結果をシェアしたとしてもそれだけで文化できるほど簡単じゃなかったりするんですよね。テストは顕著に差を出してしまうこともあるわけで、まぁ、その方がテスト的には価値があるんですけどね。</p>
<p>ただ、そういった数字で示されれてしまうと、マーケティング部門、それはそれで自分の感性に近いところで行っていた方には、やっぱり受け入れがたい部分もあるんですよね。</p>
<p>自分が信じていた感覚を数字で否定されてしまうわけですね。特に長くマーケティングを行われている方に多い気がするので、そのうち変わってくるとは思いますが。</p>
<h3>対制作部門</h3>
<p>マーケティング側だけでなく、制作側から見てもやっぱりテストという文化に壁は存在しているような気がしています。</p>
<p>これは制作が関わる場合のほとんどがローンチまでであり、運用時も含めて細かく関わることが少ないということが大きい気がしていて、ちょっときつめの言葉を使うと「作りっぱなし」なんですよね。</p>
<p>精度をあげるためにユーザビリティやIAとかも勉強しているはずなのにもったいない限り。IAと言えば、コンセントの長谷川さんなどに聞くと、本来はフィードバックというプロセスがあるそうなのですが、普段そういう事が語られることが少ないようです。</p>
<p>IAも最初の組み立ては仮説ベースで組み立てを行っているわけなので、それが完全に正しいなんてわからないわけです。</p>
<p>なので、本来は正しいかどうかの検証をテストを通して行い、修正していくことも必要だと思っています。あえて言おうペルソナは仮説であると。</p>
<h2>テスト案で息切れの壁</h2>
<p>さて、ここまでがテストをそもそも行うという部分にフォーカスしたのですが、テストを行う文化になってくると２つ目の壁が立ちはだかるような気がしています。</p>
<p>それがテスト案を考える中で息切れをしてしまうケースだったりします。ランディングページでテストをして、そのテスト内容は「パターンAとパターンBの比較」というのを行ったりするわけですが、こういったテストを繰り返しているとパターン出しに息切れしちゃうんですよね。</p>
<p>これは＜仮説＞が置き去りでテストを実施してしまっているパターンで、頭を悩ませながらUIのパターンなどを創りだしてテストしていく方法です。</p>
<p>それ自体は良い結果を生み出す場合もあるので、パッと思いついたアイデアでテストも実施することは重要です。ただ、あくまでパッと思いついた場合のみで、これを恒常的に実施するのはかなり辛いです。</p>
<p>仮説ベースのものとは、例えば「ここのページはセグメントAの訪問が中心であり、それらのニーズは甲と乙が考えられるので、ニーズの特定のためにパターンAとBのテストを実施する。」といったものです。</p>
<p>こうなると次のテストが非常に組み立て易いんですよね。「テストの結果、ニーズ甲を想定していたパターンAが良かったので、ニーズ甲の興味をさらにアップするために〜〜についてさらにテストします。」</p>
<p>といったように、仮説のどちらが採用されたかで、仮説のステップが１つ進み、次のテストの設計が非常にしやすくなるわけです。</p>
<h2>まとめ</h2>
<p>ということで、テストの文化を作っていくことに関して、感じている壁についてパッと書きだしてみました。</p>
<p>通常のクリエイティブだと、最初に作ったものが最終型なわけですが、Webでのテストを繰り返しながらの最適化は必ずしもそうでもなかったりします。</p>
<p>仮説の検証を繰り返しながら、より先良いものを作りだすために結果を意識した完成形ではない一時的なページを作って、その後、最終版に落としこむといった方法も選択できたりします。</p>
<p>これがリアルだけではない、Webの最適化の本当に面白いところなんですよね。だから好きなんです。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/2230/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/2230" />
	</item>
		<item>
		<title>テスティングまとめ</title>
		<link>http://an-k.jp/blog/archives/1417</link>
		<comments>http://an-k.jp/blog/archives/1417#comments</comments>
		<pubDate>Mon, 07 Sep 2009 16:12:04 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=1417</guid>
		<description><![CDATA[以前に書いた、直帰率まとめエントリが意外と人気だったので、今回はテスティングについて過去のエントリを参照しつつまとめていきたいと思います。たまには、過去の掘り起こしも良いものです。]]></description>
			<content:encoded><![CDATA[<p><img src="http://an-k.jp/blog/wp-content/uploads/2009/09/364313119_61bf09d14b-150x150.jpg" alt="You can choose: Pepsi or... Pepsi? by Michel Filion" title="You can choose: Pepsi or... Pepsi? by Michel Filion" width="150" height="150" class="alignleft size-thumbnail wp-image-1427" />以前に書いた、直帰率まとめエントリが意外と人気だったので、今回はテスティングについて過去のエントリを参照しつつまとめていきたいと思います。たまには、過去の掘り起こしも良いものです。</p>
<h2>なぜテストするのか？</h2>
<p>もうこれは一言で「<strong>そこに仮説があるから</strong>」です。</p>
<p>基本的にサイトは全て仮説の上に成り立ってます。「ビジネスマン向けのサイトです」「主婦向けのサイトです」などもそうですし、「このボタンならわかりやすいだろう」だって仮説です。</p>
<p>なので、可能性としては間違っていることもあるわけです。設計／制作段階で沢山の仮説が出てしまい、どれも甲乙付けがたく、いくつかの仮説が出来てしまったということもあるかもしれません。</p>
<p>なんにせよ仮説を裏付けしていくためにテストするわけです。そして、Web自体はとてもテストを行う環境が揃っていたりするので良かったりするわけです。なぜ、Webはテストを行う環境が揃っているかについては、「<a href="http://an-k.jp/blog/archives/187">テストを行い最適化を行う。</a>」に書かれています。</p>
<p>テストって結構なじみが無いんですよね。なんか、そういう文化がある企業が意外と少なかったり（もちろんそうでは無いところもあります）。</p>
<h2>テストの仕方</h2>
<p>これは２つも書いているエントリーがありました。欲張りですね。基本的な期間やテストパターンについては「<a href="http://an-k.jp/blog/archives/199">テストと計画と結果の解釈</a>」に書かれています。</p>
<p>ただ、ここに書かれていることについては手動で行う場合も含めてのテストで、実際にツールを使った場合はきちんとした振り分けをして、テストの確度も出してくれるのでそこまで気にする必要の無い部分もあります。</p>
<p>そして、テストの外枠もテスト計画を考える上では非常に重要なのですが、テストの中身も非常にに重要です。「AとBというクリエイティブがあるから比較しよう」というのは、テストをすれば結果が出ます。しかし、場合によっては、その知見が再利用できないため、その１回だけしか使えないものになってしまう可能性もあります。</p>
<p>テストを行う際には、何をテストして、どういった知見が得られるかをきちんと設定しておくことで、その知見が再利用でき、結果、サイトのより良い向上に繋がって行きます。つまり、<strong>テストは設計が重要</strong>なんです。ということで、バナーテストを行う際に、どんな設計ができるかについては、「<a href="http://an-k.jp/blog/archives/1042">バナーをテストをする時の要素７つ+ ２</a>」 に書いてあります。</p>
<h2>テストの事例</h2>
<p>さて、最後に事例です。これはブログには１つしかアップしていませんが、非常に面白い事例であることは確かです。エントリ内にも書いていますが、実際に会場に挙手をして頂くと、ほとんどの方が結果を間違えるというものです。（この会場挙手に関しては２回別の会場で実施しても同じように、良かったパターンではないものに挙手が集中）</p>
<p>「<a href="http://an-k.jp/blog/archives/1211">バナーテストをしてました。</a>」と「<a href="http://an-k.jp/blog/archives/1355">バナーテストしてました（結果編）</a>」</p>
<p>この２つのエントリのケースを見て頂いて、もし、ご自分が考えられていたものと違うものが良かったのであれば、それは「仮説」が間違っていたわけです。そういった間違った部分を見つけ出し、改善をしていくことでサイトは最適化されていくわけです。</p>
<h2>まとめ</h2>
<p>ということで、今までにアップしていたテスト系エントリを掘り出してまとめ直してみました。以前に書いたエントリでエコシステムを作って行く重要性について書きました（<a href="http://an-k.jp/blog/archives/1246">結局はエコシステムを作る事</a>）。</p>
<p>テストを行って行くことは、このエコシステムを推進していくうえで核となる部分です。テストの結果から得られる知見は、そのサイトでしか得られないものも沢山出てきます。つまり、それは財産にもなり得るわけです。ぜひぜひ、テストをどしどし行って行ってください！</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/1417/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/1417" />
	</item>
		<item>
		<title>バナーテストしてました（結果編）</title>
		<link>http://an-k.jp/blog/archives/1355</link>
		<comments>http://an-k.jp/blog/archives/1355#comments</comments>
		<pubDate>Wed, 12 Aug 2009 22:38:59 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[CSS Nite]]></category>
		<category><![CDATA[Display Ad]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=1355</guid>
		<description><![CDATA[先日、CSSniteの告知もかねて書いたエントリー「<a href="http://an-k.jp/blog/archives/1211" target="_blank">バナーテストをしてました。</a>」の結果を遅ればせながら書いておきます。

実際のテスト場所やパターンについては、長くなってしまうので、<a href="http://an-k.jp/blog/archives/1211" target="_blank">前回のエントリ</a>でご確認頂ければと思いますが、基本は下のような３つのバナークリックテストです。]]></description>
			<content:encoded><![CDATA[<p>先日、CSSniteの告知もかねて書いたエントリー「<a href="http://an-k.jp/blog/archives/1211" target="_blank">バナーテストをしてました。</a>」の結果を遅ればせながら書いておきます。</p>
<p>実際のテスト場所やパターンについては、長くなってしまうので、<a href="http://an-k.jp/blog/archives/1211" target="_blank">前回のエントリ</a>でご確認頂ければと思いますが、基本は下のような３つのバナークリックテストです。</p>
<p><a href="http://www.flickr.com/photos/an-k/3689079578/" title="banners by an-k, on Flickr"><img src="http://farm3.static.flickr.com/2461/3689079578_75c8594503_o.png" width="500" height="139" alt="banners" /></a></p>
<p>さて、もう結果について触れてしまいますが、結果は下記となりました。これらはクリック率を比較していて、クリック率は訪問（Visit）に対してのクリックになっています。</p>
<p><strong>パターンA（左）</strong>：コントロール<br />
<strong>パターンB（中）</strong>：コントロールに対してクリック率が 57.40% の上昇<br />
<strong>パターンC（右）</strong>：コントロールに対してクリック率が  5.64% の上昇</p>
<p>パターンAのコントロールとは、これを基準して比較をした場合、といった形で算出されるためこのような結果になりました。</p>
<p>サンプル数は約4500件の１ヶ月検証で、テスト結果の確度も良い感じです。実際にグラフで期間中のクリック率を見ても、常にパターンBが上回っていたので確実と言って良いと思います。</p>
<h2>まとめ</h2>
<p>さて、もともとテストをしたかったのは「ボタンの有無による違い」と「ボタンの場所による違い」でした。</p>
<p>ということで、今回のテスト結果から見られる知見ですが、新たな仮説として下記のようなことが見えたと思ってます。</p>
<ul>
<li>ボタンがあった方がまぁクリック率が高くなる傾向にある。</li>
<li>バナーの位置によってボタンの位置の工夫が必要？（今回はバナーが右側にあり、エントリーの横にあたるため、目につき易い左側にボタンが配置されることが多かったのかも）</li>
</ul>
<p>先日、CSSniteで、この結果を挙手して頂き実際に聴きにきてくださった方に予想をして頂いたところ、８割の方がパターンCがクリック率が高かっただろうと予想され、みごとほとんどの方がはずれてしまうという結果になりました。</p>
<p>個人的にも、「もしや？」という部分があったのでテストをしたものの、正直びっくりな結果でした。今回のようなテストを通すことで、実際に予想と違った結果が出てくるのがテスティングの醍醐味なんですよね。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/1355/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/1355" />
	</item>
		<item>
		<title>バナーテストをしてました。</title>
		<link>http://an-k.jp/blog/archives/1211</link>
		<comments>http://an-k.jp/blog/archives/1211#comments</comments>
		<pubDate>Sun, 05 Jul 2009 02:41:07 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[CSS Nite]]></category>
		<category><![CDATA[Display Ad]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=1211</guid>
		<description><![CDATA[バナーテストをしてました。今度の<a href="http://an-k.jp/blog/archives/1009">CSSnite</a>で利用しようかなぁということで、このブログでのテストです。ということで概要を紹介です。]]></description>
			<content:encoded><![CDATA[<p>バナーテストをしてました。今度の<a href="http://an-k.jp/blog/archives/1009">CSSnite</a>で利用しようかなぁということで、このブログでのテストです。ということで概要を紹介です。</p>
<h2>何をテストしていたか？</h2>
<p>ブログでバナーテスティングといっても、広告を出しているわけでもないので、今回はCSSniteのセミナー告知として、告知を載せたエントリーへのバナーとしてテストをしました。</p>
<p>ブログで取得できるコンバージョンというのもそうないので、今回はCTR（クリック率）で比較です。なので評価としてはバナーのクリエイティブの効果のみです。</p>
<p>テスト場所は、ブログの右側の部分です。TOPページ以外にも、各アーカイブの横にも出ていました。TOPページでは↓の緑色の部分です。</p>
<p><a href="http://www.flickr.com/photos/an-k/3683826802/" title="dIG iT by an-k, on Flickr"><img src="http://farm3.static.flickr.com/2508/3683826802_131a027c05_m.jpg" width="240" height="214" alt="dIG iT" /></a></p>
<h2>実際のバナー</h2>
<p>下が実際にテストをしていた３種類のバナーです。ボタンなし、あえてのボタンあり左下、あえてのボタンあり右下の３種類です。</p>
<p><a href="http://www.flickr.com/photos/an-k/3689079578/" title="banners by an-k, on Flickr"><img src="http://farm3.static.flickr.com/2461/3689079578_75c8594503_o.png" width="500" height="139" alt="banners" /></a></p>
<p>これを比較することで２つのことがわかると良いなぁと考えてました。１つめが、「<strong>ボタンの有無による違い</strong>」。バナー全体がクリックできるのは当たり前なのですが、まぁ、こういう告知っぽいものの場合にもボタンの効果はあるのかなぁと。</p>
<p>もう１つが「<strong>ボタンの場所による違い</strong>」。ボタンを設定した場合に、そのボタンの位置によって違うのか？違うならどのくらい違うのか？を知りたかったのです。</p>
<p>ちなみにバナーテスティングをする際の要素は「<a href="http://an-k.jp/blog/archives/1042">バナーをテストをする時の要素７つ+ ２</a>」にまとめてあるので、こちらもご興味が有れば。</p>
<h2>結果</h2>
<p>結果は結構面白い感じになりました。…がここで書いてしまうとCSSniteでの楽しみが無くなってしまうので、CSSniteで発表したあとに、このブログに結果を書こうと思います。</p>
<p>というこで是非<a href="http://an-k.jp/blog/archives/1009">CSSnite</a>へ！</p>
<p>2008/08/13 追記：結果編を書きました。<a href="http://an-k.jp/blog/archives/1355">バナーテストしてました（結果編）</a></p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/1211/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/1211" />
	</item>
		<item>
		<title>バナーをテストをする時の要素７つ+ ２</title>
		<link>http://an-k.jp/blog/archives/1042</link>
		<comments>http://an-k.jp/blog/archives/1042#comments</comments>
		<pubDate>Sat, 16 May 2009 07:19:42 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[Display Ad]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=1042</guid>
		<description><![CDATA[テスティングをしていくにあたって、ただ闇雲に複数のバナーを作ってAとBを比べてみると、もちろん結果は出ます。AかBのどちらかが良いか、AとBのどちらもそんなに変わらないです。

１回限りのテストであれば、これで良いかもしれません。でも実際は、サイトは常に運用され続けていくわけで、「<strong>良い知見を見いだして、次のバナーを作る際に活用できること</strong>」の方がより良いじゃないですか。次はさらに良い結果がでるわけです。]]></description>
			<content:encoded><![CDATA[<p><img src="http://an-k.jp/blog/wp-content/uploads/2009/05/1020029311_0436e22d69-150x150.png" alt="dismantle" title="dismantle by fdecomite" width="150" height="150" class="alignleft size-thumbnail wp-image-1047" />テスティングをしていくにあたって、ただ闇雲に複数のバナーを作ってAとBを比べてみると、もちろん結果は出ます。AかBのどちらかが良いか、AとBのどちらもそんなに変わらないです。</p>
<p>１回限りのテストであれば、これで良いかもしれません。でも実際は、サイトは常に運用され続けていくわけで、「<strong>良い知見を見いだして、次のバナーを作る際に活用できること</strong>」の方がより良いじゃないですか。次はさらに良い結果がでるわけです。</p>
<p>この良い知見を見いだすためには「<strong>何をテストするのか？</strong>」をきちんと決めておく必要があるわけで、このテストをしたら「<strong>何が原因で良かったかがわかる</strong>」ことが重要なわけです。</p>
<p>でも、実際にテストをするとなると「じゃあどうすんのさ？」的にもなってしまうので、バナーテスティングする際の要素みたいなのを書き出してみました。</p>
<p><span id="more-1042"></span></p>
<h2>テキスト系</h2>
<p>実際には、それほどじっくり読まれることは少ないですが、それでもやっぱり「それが何を表しているのか」を伝えてくれるテキストは重要です。</p>
<p>実際には下記の項目が意識するものになります。</p>
<ul>
<li>キャッチ／タイトル</li>
<li>説明文</li>
</ul>
<h2>クリエイティブ系</h2>
<p>テキストだけでももちろん良いですが、やっぱり絵や写真がはいっているだけで、ぐ〜んと引きつけられるかも。</p>
<p>一部では都市伝説的に人の顔が入っていると、目に留まり易いなどもあるので、そういったのも良いでしょう。</p>
<ul>
<li>イメージ画像やクリエイティブ</li>
</ul>
<h2>Call-To-Action（行動喚起）系</h2>
<p>一番わかりやすいのはボタンとかですね。最終的に押してもらいたい部分をどのように見せるかです。</p>
<ul>
<li>ボタンやリンクの有無</li>
<li>ボタンやリンクの場所</li>
<li>デザイン（ふっくらとかのぺーっととか）</li>
<li>ボタンやリンクの文言</li>
</ul>
<h2>掲載系</h2>
<p>バナーを掲載する場所も重要です。とりあえずサイト内でテストする時のことを考えてみました。これらの場合は、バナーデザインは同じにした方が良いです。</p>
<ul>
<li>ページ内の場所（右上なのか、ページしたなのか、ファーストビューに入っているのか…など）</li>
<li>掲載しているページ</li>
</ul>
<h2>まとめ</h2>
<p>テスティングをするにあたって、これらの要素のどこでテストするのかを意識しておかないと、Aのバナーは画像（人の顔）とテキストがこうだった、Bのバナーは画像（イラスト）とボタンを配置した。で、Bが良かったけど、イラストが良かったのか、ボタンを配置したのかわかんない。。。</p>
<p>となってしまうので「Call-To-Actionの文言のテスト」と決めたら、それ以外は同じ条件にしておいた方が、「こういう文言の方が良かった」と結果が明確になるので良い訳ですよ。</p>
<p>テストは仮説を検証するためのものなので、どの仮説がクリアになるのかを、きちんと意識することで、よりテストの意味も出てくるわけです。手間がかかるのにテストの結果が「こっちのこれが良かったかもしれません」じゃもったいないですよね。</p>
<p>とはいえバナーを作る方からしたら、「クリエイティビティがっ！」ってなるのもわかります。</p>
<p>#ちなみに要素はぱーっと書き出したので漏れがあるかも。何か気づいたらご連絡を。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/1042/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/1042" />
	</item>
		<item>
		<title>mixiのバナーコンテスト</title>
		<link>http://an-k.jp/blog/archives/924</link>
		<comments>http://an-k.jp/blog/archives/924#comments</comments>
		<pubDate>Sun, 19 Apr 2009 14:30:35 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[mixi]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analytics]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=924</guid>
		<description><![CDATA[募集、実施期間中に知っていればなぁと感じてやまないのですが、mixiが宇多田ヒカルの本の広告バナーを一般公募し、実際にクリック率を競い合うというキャンペーンを行っていたそうです。 一番クリックされたバナーは？mixiユー [...]]]></description>
			<content:encoded><![CDATA[<p>募集、実施期間中に知っていればなぁと感じてやまないのですが、mixiが宇多田ヒカルの本の広告バナーを一般公募し、実際にクリック率を競い合うというキャンペーンを行っていたそうです。</p>
<ul>
<li><a href="http://markezine.jp/article/detail/7134" target="_blank">一番クリックされたバナーは？mixiユーザーがつくった宇多田ヒカルのプロモバナーコンテンスト結果発表：MarkeZine（マーケジン）</a></li>
<li><a href="http://mixi.jp/pr.pl?id=144" target="_blank">[mixi] 宇多田ヒカル×mixi特別企画 [ mixi内へのリンク ]</a></li>
</ul>
<p>このプロモーションには２つの面白みがあったのかなぁと思ってます。</p>
<p><span id="more-924"></span></p>
<h2>クオリティの高いバナー</h2>
<p>テストを行う場合、いくつかのバナーを用意するわけです。２〜３パターンを行うにしたって、全て100%の力を使って作ったバナーじゃないとテストをする意味すらないわです。</p>
<p>でも、デザイナーにとって100%の違うバナーを用意するって結構大変なんですよね。それが、今回は公募だったため１人が１つ作ったとしてもそれなりの数が集まるわけです。</p>
<p>実際には1,433件集まったようで、そのうちの選抜がmixi内のバナーとして利用されたようです。選抜されたバナーを見る限りは、それほどクオリティに遜色もない非常に良いもののようです。</p>
<p>ということで、テストをするにあたり複数のバナーを用意するのは非常に良かったのではと。</p>
<h2>結果が知れる</h2>
<p>そうはいってもまだまだテストを行っているサイトの方が少ないわけで、このようなバナーのテスト結果も一度に知れるプロモーションは良いですよね。</p>
<p>デザイナーが良いと思ったデザインが実際に効果があるのか？これを制作者も簡単に知ることができるのは現状では非常に良いと感じがします。</p>
<p>ただ、CTRなどもせっかくなので出して欲しかったなぁと個人的には。小数点以下の結果の比較だったら、色々なつっこみも起こるでしょうし、何より売上が想像できちゃうんだろうなぁ…ということで難しいかもしれませんが。。</p>
<h2>まとめ</h2>
<p>mixiは集客も多いサイトなので、ビューも稼げますし、もともと広告配信サーバを持っているので、このようなバナーの制御も非常にやりやすいんだと思います。</p>
<p>このようなプロモーションをきっかけに、デザイナーの方々やサイト運営者の方々にもテストを認知して頂けるとうれしいですね。</p>
<p>自分も参加したかったなぁ。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/924/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/924" />
	</item>
		<item>
		<title>Webアクセス解析の疑問に答える25のTIPS その2</title>
		<link>http://an-k.jp/blog/archives/342</link>
		<comments>http://an-k.jp/blog/archives/342#comments</comments>
		<pubDate>Wed, 20 Aug 2008 11:53:49 +0000</pubDate>
		<dc:creator>あんけい</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[A/BTest]]></category>
		<category><![CDATA[ClickTale]]></category>
		<category><![CDATA[Exit Ratio]]></category>
		<category><![CDATA[MVT]]></category>
		<category><![CDATA[Page View]]></category>
		<category><![CDATA[Redirect]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[Web Analyst Mind]]></category>
		<category><![CDATA[Web Analytics]]></category>
		<category><![CDATA[Web Analytics Tool]]></category>
		<category><![CDATA[Woopra]]></category>

		<guid isPermaLink="false">http://an-k.jp/blog/?p=342</guid>
		<description><![CDATA[前回のエントリーの続きです。 11. 自社のサーバーが落ちていたにもかかわらず、アクセス解析ツールのログにはアクセスの記録があった。なぜ？ タグ型の場合は別サーバで計測されたため、ISPやブラウザのキャッシュから呼び出さ [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://an-k.jp/blog/archives/328">前回のエントリー</a>の続きです。</p>
<h3>11. 自社のサーバーが落ちていたにもかかわらず、アクセス解析ツールのログにはアクセスの記録があった。なぜ？</h3>
<p>タグ型の場合は別サーバで計測されたため、ISPやブラウザのキャッシュから呼び出された際もカウントされてしまいます。これが一番おおそうな原因です。</p>
<p>あとは、サーバの落ちた場所にもよりますが、パケットキャプチャ型も場合によっては計測出来てしまうかも。</p>
<h3>12. 有料ツールを使うメリットってなんですか？</h3>
<p>レポーティングとリマーケティングかなぁと思います。個人的にはリマーケティングがかなり大きいと思ってます。</p>
<p>Google Analyticsだと解析したその先が無いんですよね。それに比べて有料ツールの場合は、色々とカスタムしてプラスαのデータを取得することが出来るものもあったりするわけです。</p>
<p>それこそページ参照者を抽出した際に、会員情報と結びつけられるようにしておけば、特定のコンテンツを参照した方を特定できるわけです。そういった方にメールなどで特定のコンテンツに紐づいた内容を送ったりできるわけです。</p>
<p>こういったアプローチが出来ることが、有料ものの強みだと思います。</p>
<h3>13. アクセス解析の有料製品の値段が高い理由はなぜ？</h3>
<p>データ集計してるんですからねぇ。やっぱり。そこは高いと思います。あとは集計にどのくらいの時間がかかるか、集計サーバの安定度なんかによっても違うと思います。</p>
<p>大規模サイトを計測するのであれば、大規模サイトと同じトラフィックは許容できなければいけないですからね。</p>
<p>個人的には無料で提供できているGoogle Analyticsが異常なんだと思います。</p>
<h3>14. サイトの変更がアクセス数にどれだけ影響あるか、のテストの方法はある？</h3>
<p>「サイトの変更」と「アクセス数への影響」の規模が分からないのですが、サイト全体のトラフィックとしてのアクセス数を捉える場合は、一部の変更が及ぼした影響を知る方法は難しいでしょう。</p>
<p>ただ、その変更が良かったかどうかを知ることはテストを行えば出来ます。大きくは２つの方法があります。</p>
<ol>
<li>A/Bテスト</li>
<li>多変量解析テスト</li>
</ol>
<p>A/Bテストは２つの方法をテストすることです。時期をづらして行う方法もあるのですが、出来れば同時にランダムに出し分けをした方が良いでしょう。そうすることで、直帰率やCTR、CVRなどを比べるだけでどちらが良いかを判断することが出来ます。</p>
<p>また、多変量解析テストの場合は、１ページの中で同時に複数を変更してテストを行いたい場合などに利用されます。これは、多変量解析を利用して、もっとも最適な組み合わせを見つける方法です。</p>
<p>この両方ともテストを行うツールとしてGoogleが無料で提供をしています（ <a href="http://www.google.com/websiteoptimizer">Google Website Optimizer</a> ）。これらをうまく利用することで、テストを通してサイトをより良いものにしていけると思います。</p>
<h3>15. サイトの URL を変更した場合、アクセス数などに影響はあるか？</h3>
<p>サイトのURLを変更した場合に影響がでるのは「検索エンジンに登録されたURL」「CGMコンテンツに貼られたリンク」が多いと思います。</p>
<p>これらの影響はサイトのURLをリダイレクト処理などを行っているかどうかにもよると思います。URLを変更した際に、古いURLをリダイレクト（サーバによる転送やMETAのリフレッシュによる方法など）していればそれほど大きな影響は無いかもしれません。</p>
<p>SEO業者の方に聞いた話ですが、きちんと作られているサイトであれば404になっても、TOPページなどにサイトマップなどをきちんと設定しておけば、再度、キャッシュをし直すそうです。</p>
<p>いずれにしろ、サイトのURL変更の影響を最小限にとどめるためには、色々な準備が必要ですので、きちんと詳しい業者などに確認をしながら行っていくのが良いかもしれません。</p>
<h3>16. PC よりモバイルのサイトのほうが、一人当たりのページビューが多いのはなぜ？</h3>
<p>これは場合にもよるとは思いますが、多くの場合、携帯で受信できるページのMAXを考慮して、かなり１ページの情報量を絞り込んでいることが多いと思います。</p>
<p>そうすると、同じ目的をもってサイトを来訪した場合、同じ情報量を得てサイトを去るにはページ遷移数が携帯の方が増えてしまうわけです。</p>
<h3>17. アクセス解析でよく言われる「離脱率」というのは気にしたほうがいいのでしょうか</h3>
<p>離脱率は場所によっては見てもあまり意味のないところもありますが、コンバージョンプロセスでは非常に重要な指標です。</p>
<p>コンバージョンプロセスは既にある程度、コンバージョン（商品購入など）を達成する意思のある方が入ってきているわけで、より離脱が少ない方が良いわけです。</p>
<p>コンバージョンプロセスの中で、離脱率の高いところを見つけ出して、そこを改善していくことで、コンバージョンプロセス中でのCVR（コンバージョン率）をできるだけ100%に近づくようにしていくわけです。</p>
<p>離脱率は悪い部分を見つけ出すためにも利用できますし、改修を行った際の検証にも利用することが出来ます。</p>
<p>通常の回遊コンテンツの中では、目的が達成されたためそこで離脱をされたり、サイトで迷子になってあきらめたなど様々な理由を特定することが難しいためあまり有用では無いかもしれません（かと言って全く使えないわけでは無いと思います）。</p>
<h3>18. 日本にない、海外系アクセス解析ツールでのすごい機能はありますか？</h3>
<p>個人的に好きなのは<a href="http://www.clicktale.com/">ClickTale</a>です。これは一定期間にサンプリングされたユーザーのクリックやスクロールを再生してくれます。また、ページのどの部分が見られている時間が長かったかをヒートマップで表示してくれます。</p>
<p>その他には<a href="http://www.woopra.com/">Woopra</a>というリアルタイム解析をする中で、現在、サイトに来訪している方とチャットをすることが出来る機能がついているものなどがあります。</p>
<h3>19. いまユーザーが求める機能は何？</h3>
<p>自分は提供側ではなく、利用側なので、自分の意見として欲しいものを書いておきたいと思います。</p>
<p>一番欲しいのはPCと携帯の両方を共通で認識できるツールですね。現状はどのツールも、PC、携帯がそれぞれ取得できたとしても別々で集計されているわけです。</p>
<p>「これがPCで検索をして、後で携帯で購入した。」などがわかるようになると、解析、アプローチの幅が広がると思います。</p>
<p>ツールの自動化という部分では、ある程度自動的に色々出来るものが少しずつ求められているようですが、日本人の文化なのか、アメリカほど需要が無いと聞いたことがあります。</p>
<h3>20. ブログのサービスなど Javascript が使えないサイトでもアクセス解析をしたいが、どうすればいい？</h3>
<p>「そのブログを解析して何をしたいのか？」という部分は大きいと思います。ブログの実情を知るだけであれば、最近のブログサービスで提供している解析ツールでも十分に知ることが出来ると思います。</p>
<p>あとは「画像だけ埋め込み」で計測するツールがありますが、これで解析できる範囲というのはブログサービスがデフォルトで提供しているものとそれほど差異はないと思います。</p>
<p>もっと詳細に分析をしたいのであれば、JavaScriptが使えるサービスやログが落とせるサービスなどに移行した方が良いかもしれません。</p>
<h3>21. アクセス解析を導入することによる悪影響はあるか？</h3>
<p>タグ型の場合は、ページが少し重くなってしまう可能性もあります。また、Scriptのエラーが出ないよう運用で気をつける必要があると思います。</p>
<p>また、まだほとんどの会社で解析を行う人は兼任のようです。そういった中では、仕事量が単純に増えてしまうだけに大変なため使うのをやめてしまう方もいるようです。</p>
<p>たま〜にですが、解析されていることを良いは思わない利用者の方もいるようです。</p>
<h3>22. アクセス解析ツールを使うときの落とし穴は？</h3>
<p>以前にまとめた<a href="http://an-k.jp/blog/archives/185">Web解析の功罪３つ</a>が参考になるかもしれません。</p>
<h3>23. 解析する期間はどのくらいを考えればいい？</h3>
<p>解析する指標、量、メッシュなどによると思います。数ヶ月運用しても数十件しかPVが取れないようなサイトを解析しても意味がありません。</p>
<p>逆に１日数万件のアクセスがあるサイトであれば、それだけでも色々な解析を行うことが出来ます。また、月の変動を見る場合は数ヶ月の時系列による比較と、前年同月との比較がわかりやすいです。こういった場合は１年必要になりますね。</p>
<p>そういえばGoogle Analyticsは２５ヶ月がログデータの保証期間のようです。２年間の比較できれば良いでしょうという考え方なのかもしれません。（<a href="http://web-tan.forum.impressrd.jp/e/2008/08/19/3758">Google Analyticsの過去データは25か月分しか保証されていない | Web担当者Forum</a>）</p>
<h3>24. アクセス数（PV）と広告料のざっくりとした相場を知りたい</h3>
<p>アクセス数の相場はありません。サイトの目的、規模などによって全く変わってきます。他人の数字を考えている暇があったら、まずは、自分のサイトのROIがどのくらいなのかを考えた方がよっぽど意味があると思いますよ。</p>
<p>広告料については、Web系の雑誌などにも掲載されていますし、検索すると結構出てきます。あとは、広告代理店にお願いすればサイトにあったものについて教えてくれると思います。</p>
<h3>25. PV とクリックされた数、つまり「クリック率」って、どれくらいになるのですか？</h3>
<p>これもそんなことを考えてるくらいだったら、少しでも向上するように考えた方が良いと思います。最初は広告出稿しているもの全体の平均と比較することで、そのサイトの中である程度の良い悪いは判断できると思います。</p>
<p>そのあとは運用、改善を行っていく中で、これ以上は結構大変だなという上限が見えてきます。そこまでくれば、新規出稿する際にそのあたりの数値を目標として置いておくようにしたら良いかと思います。</p>
<p>何度も言いますが「一般的な数値」ほど考える必要の無いものはありません！！</p>
<h3>最後に</h3>
<p>といった感じで２５個に答えてみました。結構長いですね。まぁ、少しでも自分の回答がお役に立てば幸いです。</p>
]]></content:encoded>
			<wfw:commentRss>http://an-k.jp/blog/archives/342/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
	<xhtml:link rel="alternate" media="handheld" type="text/html" href="http://an-k.jp/blog/archives/342" />
	</item>
	</channel>
</rss>

