57一般的なA/Bテストの間違いとその回避方法

A / Bテストを実行していますが、正しく機能しているかどうかわかりませんか？

壊れたキャンペーンで貴重な時間を無駄にしないように、A / Bテストでよくある間違いを学びたいですか？

さて、朗報です！ この記事では、57の一般的な（場合によってはまれな）A / Bテストの間違いについて説明します。これにより、それらを回避するか、発生したときに気づき、すばやく修正することができます。

これらを3つの主要なセクションに分けました。

• テストを開始する前の間違い、
• テスト中に発生する可能性のある問題、
• また、テストが終了するとエラーが発生する可能性があります。

あなたは単に読んで、あなたがこれらのどれかを自分で作っているかどうか見ることができます。

そして覚える：

すべての失敗は、テストとセットアップの間違いの両方において貴重な教訓です。 重要なのは彼らから学ぶことです！

では、飛び込みましょう…

テストを実行する前に発生する可能性のある一般的なA/Bテストの間違い

＃1。 テストする前に何かをライブでプッシュしてください！

あなたは素晴らしい新しいページやウェブサイトのデザインを持っているかもしれません、そしてあなたはそれをテストせずにそれをライブにプッシュすることを本当に熱望しています。

ちょっと待って！

クイックテストを実行して、最初にどのように機能するかを確認します。 データを取得せずに根本的な変更をライブでプッシュしたくない場合は、売上とコンバージョンを失う可能性があります。

その新しい変更により、パフォーマンスが大幅に低下する場合があります。 したがって、最初に簡単なテストを行います。

＃2。 実際のA/Bテストを実行していない

A / Bテストは、単一のトラフィックソースを制御ページとそのページのバリエーションに実行することで機能します。 目標は、実装した変更によってオーディエンスのコンバージョンが向上し、行動を起こすかどうかを確認することです。

重要なのは、このテストが制御され、公平であることを確認するために、特定のパラメーターを使用してそのテストを実行する必要があるということです。 同じ期間にキャンペーンを表示する同じトラフィックソースが必要です。これにより、一方のテストに影響を与え、もう一方のテストに影響を与えない外部要因がなくなります。

テストを順番に実行するという間違いを犯す人もいます。 現在のページをX時間実行し、その後X時間新しいバージョンを実行して、差を測定します。

これらのテストウィンドウ中に多くのことが起こった可能性があるため、これらの結果は完全に正確ではありません。 新しいトラフィックのバーストを取得し、イベントを実行して、2ページのオーディエンスと結果が大きく異なる可能性があります。

したがって、トラフィックを2つのバージョン間で分割し、それらをまったく同時にテストする実際のA/Bテストを実行していることを確認してください。

＃3。 ツールが機能するかどうかを確認するためのテストは行っていません

100％正確なテストツールはありません。 開始時に実行できる最善のことは、A / Aテストを実行して、ツールの精度を確認することです。

どのように？ トラフィックを単一のページ間で50:50に分割するテストを実行するだけです。 （特定の結果を測定できるように、オーディエンスが変換できるページであることを確認してください。）

なんで？

オーディエンスの両方のセットがまったく同じページを見ているので、変換結果はテストの両側で同じであるはずですよね？

そうでない場合もあります。これは、ツールが正しく設定されていない可能性があることを意味します。 したがって、キャンペーンを実行する前に、テストツールを確認してください。

＃4。 低品質のツールとコンテンツの点滅を使用する

一部のツールは他のツールほど良くありません。 彼らは仕事をしますが、交通負荷または「点滅」とちらつきの下で苦労します。

これにより、勝つ可能性のあるバリアントがある場合でも、実際にテストが失敗する可能性があります。

ページ上の画像を分割テストしているとしましょう。 コントロールページは正常に読み込まれますが、新しいテスト画像と元の画像の間でほんの一瞬だけ変化がちらつきます。 （または、ユーザーがページを上下にスクロールするたびに。）

これは気が散って信頼の問題を引き起こし、コンバージョン率を低下させる可能性があります。

実際、新しい画像は理論的にはより適切に変換される可能性がありますが、ツールのちらつきによって結果が低下し、その画像のテストが不正確になります。

テストするのに十分なツールがあることを確認してください。

（これは非常に重要なユーザーエクスペリエンスの要因であるため、Googleは現在、ちらつきや動きのある要素がないサイトのランキングを調整しています）。

＃5。 テストQAなし

非常に単純な間違いですが、すべてが機能することを確認しましたか？

• 販売プロセスを終えましたか？
• 他にありますか？ （また、キャッシュされていないデバイスでは、ブラウザーに保存されているものがページの外観と異なる場合があるためです。）
• ページの読み込みは問題ありませんか？ 彼らは遅いですか？ デザインがめちゃくちゃになっていますか？
• すべてのボタンは機能しますか？
• 収益追跡は機能していますか？
• ページが複数のデバイスで機能することを確認しましたか？
• 何かが壊れた場合のエラー報告はありますか？

これは、キャンペーンへのトラフィックの実行を開始する前に確認する価値があります。

＃6。 新しい治療/バリエーションは機能しますか？

同様に、テストを実行する前に、新しいバリエーションが機能することを確認してテストしましたか？

これはQAテストの見落とされがちな部分かもしれませんが、キャンペーンは多くの場合、壊れたボタンや古いリンクなどで実行できます。 最初に確認してからテストしてください。

＃7。 仮説に従わず、古いものをテストするだけ

何も考えずにテストする人もいます。

彼らは変更のアイデアを得て、それをテストしたいと思っていますが、ページが現在どのように変換されているか、またはテストしている変更が違いを生む可能性がある理由についての実際の分析はありません。 （ベースラインの結果がまだ追跡されていないため、コンバージョンを下げても、それを知らない可能性があります）。

問題がどこにあるのか、その原因、そしてそれをどのように解決できるのかという仮説を立てることは、テストプログラムに大きな違いをもたらします。

＃8。 テストできない仮説を立てる

すべての仮説が正しいわけではありません。 これで結構です。 実際、この言葉は文字通り「私はXの情報に基づいたアイデアを持っており、YはZの状況で発生する可能性があると思います」という意味です。

ただし、テスト可能な仮説が必要になります。つまり、テストを通じて証明または反証できるということです。 検証可能な仮説はイノベーションを動かし、活発な実験を促進します。 それらは成功（この場合あなたの予感は正しかった）または失敗のいずれかをもたらす可能性があります–あなたがずっと間違っていたことを示します。 しかし、彼らはあなたに洞察を与えるでしょう。 これは、テストをより適切に実行する必要がある、データが正しくない、または正しく読み取られていない、または機能しないものを見つけたために、はるかに適切に機能する可能性のある新しいテストへの洞察が得られる可能性があります。

＃9。 テストの明確な目標を事前に設定していない

仮説を立てたら、これを使用して、達成したい特定の結果に合わせることができます。

キャンペーンを実行して何が変わるかを確認するだけの場合もありますが、どの特定の要素を増やしたいかが明確であれば、確実に多くのリード/コンバージョンまたは売上を得ることができます。

（これにより、重要な要素の低下が見られなくなりますが、「より多くのシェアを獲得した」ため、テストが勝利と見なされます。）

そういえば…

＃10。 表面的な指標に焦点を当てる

テストは、常にGuardrailメトリックまたは売上に直接影響する要素に関連付ける必要があります。 それがより多くのリードである場合、あなたはリードが何の価値があるか、そしてそのコンバージョン率を上げることの価値をドルまで知る必要があります。

同時に、測定可能な結果に接続しない、または測定可能な結果を​​促進しないメトリックは、通常は回避する必要があります。 Facebookの「いいね」が増えても、必ずしも売り上げが増えるわけではありません。 それらのソーシャル共有ボタンを削除して、さらにいくつのリードを獲得するかを見てください。 バニティメトリックに注意してください。1つのリークが修正されたからといって、他に対処するリークが他にないという意味ではないことを覚えておいてください。

実験プログラムの一般的なガードレールメトリックのBenLabayのリストは次のとおりです。

＃11。 定量的データのみを使用してテストのアイデアを形成する

定量的なデータを使用してアイデアを得るのは素晴らしいことですが、それもわずかに欠陥があります。 特に、私たちが使用するデータが分析からのものだけである場合。

なんで？

データから、X人のユーザーがクリックしなかったことがわかりますが、その理由はわからない可能性があります。

• ボタンがページの下に低すぎませんか？
• 不明ですか？
• それは視聴者が望んでいるものと一致していますか？
• それも機能していますか？

最高のテスターも聴衆の話を聞きます。 彼らは、何が必要か、何が彼らを前進させるか、何が彼らを妨げるかを見つけ、それを使って新しいアイデア、テスト、そして書かれたコピーを作成します。

時々、あなたのユーザーは信頼の問題と自己不信によって妨げられます。 他の時には、それは明快さと壊れた形または悪いデザインです。 重要なのは、これらは定量的データでは常にわかるとは限らないことです。そのため、常に視聴者に質問し、計画に役立ててください。

＃12。 競合他社をコピーする

秘密の準備はできましたか？

多くの場合、競合他社はただそれを翼にしているだけです。 長期的なリフトキャンペーンを実行した人がいない限り、アイデアにデータを使用せずに、何が機能するかを確認しようとしているだけかもしれません。

そしてそれでも、彼らのために働くものはあなたのために働かないかもしれません。 そうです、それらをインスピレーションに使用しますが、テストのアイデアを、それらが実行しているのを見るものだけに限定しないでください。 インスピレーションを得るために業界の外に出て、それがいくつかの仮説を引き起こすかどうかを確認することもできます。

＃13。 「業界のベストプラクティス」のみをテストする

繰り返しますが、ある人に効果があるのは、常に別の人に効果があるとは限りません。

たとえば、スライダー画像は通常、ひどいパフォーマンスを示しますが、一部のサイトでは、実際にはより多くのコンバージョンを促進する可能性があります。 すべてをテストします。 失うものは何もなく、得るものはすべてあります。

＃14。 最初に小さな影響のタスクに焦点を合わせ、影響の大きい大きな報酬/ぶら下がっている果物が利用できる場合

私たちは皆、細部に焦点を当てることで罪を犯す可能性があります。 より良いパフォーマンスを実現し、レイアウトのデザインや画像、さらにはボタンの色をテストしたいページがあるかもしれません。 （私は個人的に、5回目の反復の販売ページを持っています。）

問題は、あなたが今テストしているより重要なページがおそらくもっとあるということです。

何よりも影響を優先します。

• このページは売上に直接影響しますか？
• 販売プロセスの他のページのパフォーマンスが大幅に低下していますか？

もしそうなら、最初にそれらに焦点を当てます。

販売ページの1％の伸びは素晴らしいですが、そこに到達するページの20％の伸びははるかに重要である可能性があります。 （特に、その特定のページがほとんどの視聴者を失っている場所である場合。）

より多くのリフトを探しているだけでなく、代わりにボトルネックになっているものを修正することもあります。

最初に最大の影響、最も低いぶら下がっている果物をテストして改善します。 これがエージェンシーが行うことであり、社内チームと同じ数のテストを実行するのはそのためですが、ROIは高くなります。 エージェンシーは、同じ量のテストで21％多くの勝利を獲得します！

＃15。 一度に複数のことをテストし、どの変更が結果を引き起こしたのかわからない

一度に複数のことを変更してページ全体を再設計するという根本的なテストを行うことには何の問題もありません。

実際、これらの抜本的な再設計は、トラフィックの少ないサイトであっても、特に停滞していてそれ以上リフトが得られないように見える場合でも、ROIに最大の影響を与えることがあります。

ただし、すべてのA/Bテストがこのような根本的な変更を対象としているわけではないことに注意してください。 99％の時間、次のような1つの変更をテストしているだけです。

• 新しい見出し
• 新しい画像
• 同じコンテンツの新しいレイアウト
• 新しい価格設定など

ただし、単一要素テストを実行する際の鍵はそれだけです。 何が違いを生み出しているのかを確認し、そこから学ぶことができるように、テストを1つの要素の変更だけに保ちます。 変更が多すぎて、何が機能したのかわかりません。

＃16。 適切な事前テスト分析を実行していない

テストグループには十分な訪問者がいますか？ テストはあなたの時間の価値さえありますか？

計算する！ テストを実行する前に、十分なトラフィックがあることを確認してください。そうしないと、時間とお金が無駄になります。 トラフィックが不十分であるか感度が低い（またはその両方）ため、多くのテストが失敗します。

テスト前の分析を実行して、実験のサンプルサイズと最小検出可能効果を決定します。 ConvertのようなA/Bテストの有意性計算機は、テストのサンプルサイズとMDEを教えてくれます。これは、実行する価値があるかどうかを判断するのに役立ちます。 また、この情報を使用して、テストを実行する時間と、テストが成功したかどうかを判断する前に見逃したくないリフトを決定することもできます。

＃17。 テストの誤ったラベル付け

非常に単純な間違いですが、それは起こります。 テストに誤ったラベルを付けてから、間違った結果が得られます。 バリエーションは勝ちますが、それはコントロールと呼ばれます。そうすれば、勝ちを実装して敗者と一緒にいることは決してありません！

常に再確認してください！

＃18。 間違ったURLに対してテストを実行する

もう一つの単純な間違い。 ページのURLが正しく入力されていないか、ライブバージョンではなく、変更を加えた「テストサイト」に対してテストが実行されています。

見た目は問題ないかもしれませんが、実際にはオーディエンスには読み込まれません。

＃19。 テストに任意の表示ルールを追加する

繰り返しますが、あなたはあなたの治療で一つのことをテストする必要があり、他には何もする必要がありません。

画像の場合は、画像をテストします。 人々が両方のページを見ることができる時間帯を含め、他のすべては同じでなければなりません！

一部のツールでは、1日のさまざまな時間をテストして、さまざまな時間枠でトラフィックがどのように機能するかを確認できます。 これは、サイトのトラフィックが最も多い時期を確認したい場合に役立ちますが、ページが誰に表示され、さまざまなバリエーションがあるかによってページが分割されている場合には役立ちません。

たとえば、私たち自身のブログのトラフィックは週末に減少します（ほとんどのビジネスブログのように）。

コントロールページの月-水でテストを実行し、その後、治療で金-日からのトラフィックを示したと想像してみてください。 テストするトラフィックがはるかに少なくなり、結果が大きく異なる可能性があります。

＃20。 目標に対して間違ったトラフィックをテストする

理想的には、テストを実行するときは、オーディエンスの1つのセグメントのみをテストしていることを確認する必要があります。 通常、それは新しい有機的な訪問者であり、彼らがあなたのサイトで彼らの最初の反応をどのように反応するかを見ます。

リピーター、電子メールサブスクライバー、さらには有料トラフィックをテストしたい場合があります。 秘訣は、一度に1つだけをテストして、そのグループがそのページでどのように機能するかを正確に表現できるようにすることです。

テストを設定するときは、一緒に作業するオーディエンスを選択し、リピーターなど、結果を汚染する可能性のある他のオーディエンスをすべて削除します。

＃21。 訪問者をテストに戻すことを除外せず、結果を歪める

これをサンプル汚染と呼びます。

基本的に、訪問者がサイトのページを見て、戻ってバリエーションを見ると、そのうちの1つだけを見た場合とは非常に異なる反応を示します。

それらは、単にそれらの余分な相互作用のために、混乱したり、跳ね返ったり、さらにはより高く変換したりする可能性があります。

問題は、データが汚染され、精度が低下する原因になるということです。 理想的には、表示するページをランダム化するツールを使用しますが、テストが終了するまで常に同じバージョンを表示します。

＃22。 テストからIPを削除しない

サンプルの汚染と言えば、データを汚染する別の方法があります（とにかく分析には良い習慣です）。

分析およびテストツールからあなたとあなたのスタッフのIPアドレスをブロックするようにしてください。 あなたが望む最後のことは、あなたまたはチームメンバーがページで「チェックイン」し、テストでタグ付けされることです。

＃23。 コントロールグループのバリエーションをセグメント化しない（ネットワーク効果）

まれですが、特に視聴者向けのネットワークがある場合に発生する可能性のある別の汚染オプション。

これが例です。

視聴者がコミュニケーションできるプラットフォームがあるとしましょう。 おそらくFacebookページやコメントセクションですが、誰でもアクセスできます。

この状況では、あるページを見ている人とバリエーションを見ている人がいる可能性がありますが、それらはすべて同じソーシャルネットワーク上にあります。 これは、お互いの選択やページとの相互作用に影響を与える可能性があるため、実際にはデータを歪める可能性があります。 Linkedinは、ネットワーク効果の問題を防ぐために新機能をテストする際に、オーディエンスをセグメント化しています。

理想的には、テストが完了するまで、2つのテストグループ間の通信を分離する必要があります。

＃24。 季節的なイベントまたは主要なサイト/プラットフォームイベント中にテストを実行する

季節のイベントをテストする場合を除いて、休暇中や特別セールや世界のイベントなどの他の主要なイベント中にテストキャンペーンを実行することは絶対に避けてください。

時々あなたはそれを助けることができません。 テストを実行すると、Googleは新しいコアアップデートを実装し、キャンペーンの途中でトラフィックソースを混乱させます*咳*。

最善の方法は、すべてが停止した後に再実行することです。

＃25。 文化の違いを無視する

ページの目標があるかもしれませんが、さまざまな言語や国で複数のバリエーションが表示されるグローバルキャンペーンも実行しています。

テストを実行するときは、これを考慮する必要があります。 単純なレイアウトシフトや信頼信号の追加など、一部の変更はグローバルに行うことができます。

また、文化的な違いを考慮する必要がある場合もあります。 人々がレイアウトをどのように見るか、画像をどのように見るか、そしてあなたのページのアバター。

Netflixは、すべての番組のサムネイルを使用してこれを行い、さまざまな視聴者にアピールする可能性のあるさまざまな要素をテストします（代わりにその国で有名な特定の俳優をフィーチャーしています）。

ある国でクリックを獲得するものは、他の国では信じられないほど異なる可能性があります。 あなたがテストするまであなたは知りません！

＃26。 複数の接続されたキャンペーンを同時に実行する

興奮するのは簡単で、一度に複数のテストを実行したいです。

覚えておいてください：販売プロセスの同様のポイントに対して同時に複数のテストを実行できますが、目標到達プロセス内の複数の接続されたポイントに対して複数のテストを実行しないでください。

これが私の言いたいことです。

あなたが持っているすべてのリード生成ページで、すべて同時にテストを非常に簡単に実行することができます。

ただし、リードページ、販売ページ、チェックアウトページを一度にテストすることは望ましくありません。これは、テストプロセスに非常に多くの異なる要素を導入する可能性があり、有用な洞察を得るために大量のトラフィックとコンバージョンを必要とするためです。

それだけでなく、各要素が次のページに良い影響と悪い影響の両方を引き起こす可能性があります。 週に数十万人の訪問者がいない限り、正確な結果を得るのに苦労するでしょう。

したがって、辛抱強く、一度に1つのステージ、またはプロセスで接続されていないページのみをテストしてください。

サイドノート：

Convertを使用すると、1つの実験のユーザーを他のユーザーの表示から除外できます。 したがって、理論的には販売サイクル全体をテストしてから、他のページのコントロールのみを確認できます。

＃27。 不均等なトラフィックの重み付け

A / B、A / B / n、または多変量テストを実行しているかどうかは関係ありません。 正確な測定値を取得できるように、各バージョンに等しいトラフィック量を割り当てる必要があります。

最初から等しくなるように設定します。 ほとんどのツールでは、これを行うことができます。

テスト中に発生する可能性のある一般的なA/Bテストの間違い

＃28。 正確な結果を得るのに十分な時間実行されていない

テストして正確な結果を取得する場合は、次の3つの重要な要素を考慮する必要があります。

• 統計的有意性、
• 販売サイクル、および
• サンプルサイズ。

それでは、それを分解しましょう。

ほとんどの人は、テストツールが一方の結果が他方よりも優れており、結果が統計的に有意であると判断すると、テストを終了します。つまり、テストがこのように実行され続ける場合、これは確実な勝者です。

重要なのは、トラフィックが少ない場合でも、「statsig」をかなり速くヒットできることです。 ランダムにすべての変換が1つのページで発生し、他のページでは発生しません。

ただし、常にこの状態が続くとは限りません。 テストが開始された可能性があります。それは給料日であり、その日にたくさんの売り上げがありました。

そのため、販売サイクルを考慮する必要があります。 売上とトラフィックは、曜日または月によって変動する可能性があります。 テストの実行状況をより正確に表すには、理想的には2〜4週間の期間で実行する必要があります。

最後に、サンプルサイズがあります。

テストを1か月間実行している場合は、正確な結果を得るのに十分なトラフィックが得られる可能性があります。 少なすぎると、テストでは、期待どおりに実行されるという信頼水準を得ることができません。

したがって、経験則として、

• 95％の信頼度を取得してください。
• 1か月間実行します。
• 事前に必要なサンプルサイズを把握し、それがヒットするまでテストを停止しないでください。そうしないと、勝者がいることを疑う余地なく証明する驚くべき結果が得られます。

＃29。 ヘリコプターの監視/覗き見

ピークとは、テスターがテストのパフォーマンスを確認するためにテストを確認するときに使用される用語です。

理想的には、一度実行したテストを見たくはありません。また、適切なサンプルサイズで統計的有意性に達するまで、完全なサイクルが終了するまでテストを決定することはありません。

ただし…テストが実行されていない場合はどうなりますか？

何かが壊れた場合はどうなりますか？

ええと、その場合、あなたはそれが壊れているのを見るのに本当に一ヶ月待ちたくないでしょう？ これが、テストを実行するように設定してから24時間後に、テストがコントロールとバリエーションで結果を取得しているかどうかを常に確認する理由です。

彼らがトラフィックを受信し、クリック/コンバージョンを獲得していることがわかると、私は立ち去って、それを実行させます。 テストがコースを実行するまで、私は決定を下しません。

＃30。 ユーザーのフィードバックを追跡しない（テストが直接の即時アクションに影響を与える場合は特に重要）

テストがクリックを獲得し、トラフィックが分散されているため、テストは機能しているように見えますが、突然、販売フォームに入力できないというレポートが表示され始めたとします。 （さらに良いことに、ガードレールのメトリックが許容レベルを大幅に下回ったという自動アラートが表示されます。）

さて、あなたの最初の考えは何かが壊れているということです。

常にではありません。 あなたはあなたの申し出に共鳴しない聴衆からクリックを得るかもしれません、しかし念のために、それはそのフォームをチェックする価値があります。

壊れている場合は、修正して再起動します。

＃31。 テストの途中で変更を加える

これらの最後のいくつかの点から明らかだったかもしれませんが、テストが公開された後は、テストに変更を加えたくありません。

確かに、何かが壊れるかもしれませんが、それが私たちがこれまでに行うべき唯一の変更です。 デザインを変更したり、コピーしたりすることはありません。

テストが機能している場合は、テストを実行して、データに何が機能するかを決定させます。

＃32。 テストの途中でトラフィック割り当てを変更するか、パフォーマンスの低いユーザーを削除します

テスト対象のページを変更しないのと同様に、テスト中にバリエーションを削除したり、トラフィック分散を変更したりすることもありません。

なんで？

コントロールと3つのバリエーションを使用してA/B/nテストを実行しているとします。 テストを開始し、1週間後、いたずらに覗き見をすると、2つのバージョンがうまく機能していて、1つがうまく機能していないことに気付きます。

ここで、「負けた」バリエーションをオフにして、他のバリエーション間でトラフィックを再分散したくなるでしょう。 ヘック…トラフィックの25％を余分に取り、それをトップパフォーマーに送信することもできますが、そうしないでください。

なんで？

この再配布はテストのパフォーマンスに影響を与えるだけでなく、結果とレポートツールでの表示方法にも直接影響を与える可能性があります。

以前に削除されたバリアントにバケット化されたすべてのユーザーは、バリアントに再割り当てする必要があり、変更されたWebページが短時間で表示されます。これは、ユーザーの動作とその後の選択に影響を与える可能性があります。

そのため、途中でトラフィックを変更したり、バリエーションをオフにしたりすることはありません。 （そして、なぜあなたは覗いてはいけないのか！）

＃33。 正確な結果が得られたときにテストを停止しない

時々あなたはただテストをやめるのを忘れました！

それはあなたの聴衆の50％をより弱いページに、そして50％を勝者に送り続けます。 おっとっと！

幸い、Convert Experiencesなどのツールは、キャンペーンを停止し、特定の基準（サンプルサイズ、統計信号、コンバージョン、時間枠など）に達すると、勝者を自動的に表示するように設定できます。

＃34。 バリエーションを失うことに感情的に投資されている

テスターとして、私たちは公平である必要があります。 ただし、場合によっては、自分が好きな特定のデザインやアイデアがあり、それが勝ったはずだと確信していることがあります。そのため、テストをどんどん延長して、それが先に進むかどうかを確認します。

絆創膏を引き剥がします。

改善が必要なだけの良いアイデアがあるかもしれませんが、現在のテストを終了するまでそれを行うことはできません。

＃35。 テストの実行時間が長すぎて追跡が途切れる

別の潜在的なサンプル汚染の問題があります。

4週間を超えてテストを実行すると、ユーザーのCookieが削除される可能性があります。 これにより、イベントの追跡が不足する可能性がありますが、サンプルデータが返され、再び汚染される可能性があります。

＃36。 テストを停止/実装できるツールを使用しないでください！

もう1つのまれな問題。

一部のテストプログラムは、ハードコードされたテストの作成を要求します。 つまり、開発者とエンジニアはキャンペーンを最初から作成します。

ただし、テストが終了し、同じ開発者がテストをオフにして、勝利のバリエーションをインストールするのを待つ必要がある場合は、それは素晴らしいことではありません。 これは苛立たしいだけでなく、実行できるテストの数や、ページが公開されるのを待っている間のページのROIさえも大幅に低下させる可能性があります。

テスト終了後に発生する可能性のある一般的なA/Bテストの間違い

＃37。 1回のテストで諦めます！

通常、10回のテストのうち9回は失敗です。

つまり、その勝者を獲得するには、10回のテストを実行する必要があります。 手間はかかりますが、それだけの価値はありますので、1回のキャンペーンでやめないでください。

＃38。 すべてのバージョンをテストする前に、適切な仮説をあきらめる

失敗は単にあなたの仮説が正しいことを意味するかもしれませんが、より良く実行される必要があります。

新しい方法、新しいデザイン、新しいレイアウト、新しい画像、新しいアバター、新しい言語を試してみてください。 あなたはアイデアを持っており、それをより良く実行できるかどうかを確認します。

クライアントのページを改善するにはCXL21回の反復が必要でしたが、コンバージョン率は12.1％から79.3％になりました。

＃39。 常に大きな勝利を期待する

問題の事実は、10以上の勝利キャンペーンごとに1つだけ大きな勝利を得るかもしれないということです。

これで結構です。 1％でも時間の経過とともに化合物が増加するため、私たちはテストを続け、改善を続けています。 それを改善して2％にすると、効果が2倍になります。

どのタイプのテストが最良の結果をもたらしますか？

真実は、さまざまな実験がさまざまな効果をもたらすということです。 300を超えるテストからのJakubLinowskiの調査によると、レイアウト実験はより良い結果につながる傾向があります。

最適化するのが最も難しい画面タイプは何ですか？ 同じ調査により、チェックアウト画面が明らかになりました（25回のテストで効果の中央値は+ 0.4％）。

＃40。 テスト後に有効性をチェックしない

これでテストは終了です。 あなたは十分長い間走り、結果を見て、統計信号を取得しましたが、データの正確さを信頼できますか？

テストの途中で何かが壊れた可能性があります。 チェックするのは決して痛いことではありません。

＃41。 結果を正しく読み取っていない

あなたの結果は本当にあなたに何を伝えていますか？ それらを正しく読まないと、勝者になる可能性があり、完全な失敗のように見える可能性があります。

• 分析を深く掘り下げます。
• あなたが持っている定性的なデータを見てください。

何が機能し、何が機能しなかったのですか？ なぜそれが起こったのですか？

結果を理解すればするほど、良い結果が得られます。

＃42。 セグメントごとの結果を見ていません

少し深く潜るのは常に報われます。

たとえば、新しい亜種はコンバージョン率が低いように見えるかもしれませんが、モバイルではコンバージョン数が40％増加しています。

あなたはそれをあなたの結果にセグメント化することによってのみそれを見つけることができます。 使用されているデバイスとそこでの結果を見てください。 あなたはいくつかの貴重な洞察を見つけるかもしれません！

セグメントサイズの重要性に注意してください。 各セグメントへのトラフィックが十分になく、完全に信頼できない可能性がありますが、モバイルのみのテスト（またはそれがどのチャネルであったか）をいつでも実行して、そのパフォーマンスを確認できます。

＃43。 結果から学んでいない

テストを失うことで、さらに改善したり、さらに調査を行う必要がある場所についての洞察を得ることができます。 CROとして最も厄介なのは、今見たものから学ぶことを拒否するクライアントを見ることです。 彼らはデータを持っていますが、それを使用していません…

＃44。 敗者を連れて行く

さらに悪いことに、彼らは負けたバリエーションを取ります。

たぶん彼らはデザインを好み、変換率はわずか1％異なりますが、時間の経過とともにそれらの効果は複合します。 それらの小さな勝利を取りなさい！

＃45。 結果に対して行動を起こさない

さらに悪い？

勝利を収めるが、それを実装しない！ 彼らはデータを持っていて、それで何もしません。 変更も洞察も、新しいテストもありません。

＃46。 勝利を繰り返して改善しない

時々あなたはリフトを得ることができますが、まだまだあります。 前に述べたように、すべての勝利が2桁の上昇をもたらすことは非常にまれです。

But that doesn't mean that you can't get there by running new iterations and improvements and clawing your way up 1% at a time.

It all adds up so keep on improving!

#47. Not sharing winning findings in other areas or departments

One of the biggest things we see with hyper-successful/mature CRO teams is that they share their winnings and findings with other departments in the company.

This gives other departments insights into how they can also improve.

• Find some winning sales page copy? Preframe it in your adverts that get them to the page!
• Find a style of lead magnet that works great? Test it across the entire site.

#48. Not testing those changes in other departments

And that's the key here. Even if you share insights with other departments, you should still test to see how it works.

A style design that gives lift in one area might give a drop in others, so always test!

#49. Too much iteration on a single page

We call this hitting the 'local maximum'.

The page you're running tests on has plateaued and you just can't seem to get any more lift from it.

You can try radical redesigns, but what next?

Simply move onto another page in the sales process and improve on that. (Ironically this can actually prove to give a higher ROI anyway.)

Taking a sales page from a 10% to 11% conversion can be less important than taking the page that drives traffic to it from 2% to 5%, as you will essentially more than double the traffic on that previous page.

If in doubt, find the next most important test on your list and start improving there. You may even find it helps conversion on that stuck page anyway, simply by feeding better prospects to it.

#50. Not testing enough!

Tests take time and there's just only so many that we can run at once.

では、何ができるでしょうか。

Simply reduce the downtime between tests!

Complete a test, analyze the result, and either iterate or run a different test. (Ideally, have them queued up and ready to go).

This way you'll see a much higher return for your time investment.

#51. Not documenting tests

Another habit mature CRO teams have is creating an internal database of tests, which includes data about the page, the hypothesis, what worked, what didn't, the lift, etc.

Not only can you then learn from older tests, but it can also stop you from re-running a test by accident.

#52. Forgetting about false positives and not double-checking huge lift campaigns

Sometimes a result is just too good to be true. Either something was set up or recording wrong, or this just happens to be that 1 in 20 tests that gives a false positive.

それで、あなたは何ができますか？

Simply re-run the test, set a high confidence level, and make sure you run them for long enough.

#53. Not tracking downline results

When tracking your test results, it's also important to remember your end goal and track downline metrics before deciding on a winner.

A new variant might technically get fewer clicks through but drives more sales from the people who do click.

In this instance, this page would actually be more profitable to run, assuming the traffic that clicks continues to convert as well…

#54. Fail to account for primacy and novelty effects, which may bias the treatment results

Let's say you're not just targeting new visitors with a change, but all traffic.

We're still segmenting them so 50% see the original and 50% see the new version, but we're allowing past visitors into the campaign. This means people who've seen your site before, read your content, seen your calls to action, etc.

Also, for the duration of the campaign, they only see their specific test version.

When you make a new change, it can actually have a novelty effect on your past audience.

Maybe they see the same CTA all the time and now just ignore it, right? In this case, a new CTA button or design can actually see a lift from past visitors, not because they want it more now, but because it's new and interesting.

Sometimes, you might even get more clicks because the layout has changed and they're exploring the design.

Because of this, you will usually get an initial lift in response, but which dies back down over time.

The key when running your test is to segment the audience after and see if the new visitors are responding as well as the old ones.

If it's much lower, then it could be a novelty effect with the old users clicking around. If it's on a similar level, you might have a new winner on your hands.

Either way, let it run for the full cycle and balance out.

＃55。 実行中の対価期間の変更

テスト時に考慮すべきもう1つのことは、聴衆の検討期間を変更する可能性のあるバリアントです。

どういう意味ですか？

通常、すぐに売り上げが得られないとします。 リードは30日またはそれ以上の販売サイクルになる可能性があります。

検討と購入の時間に直接影響する行動の呼びかけをテストしている場合、結果が歪められます。 一つには、あなたのコントロールは売り上げを得るかもしれませんが、テスト期間外であるため、あなたはそれらを見逃します。

もう1つのシナリオは、取引を提供するCTAがある場合、つまり、今すぐ行動を起こしたいと思わせる他の価格帯がある場合、ほとんどの場合、結果が歪んで、このバージョンの変換がはるかに優れているように見えます。

これを念頭に置いて、テスト中およびテスト後に分析を確認してください。

＃56。 X時間後に再テストしない

これは、特定のページやテストの間違いに関するものではなく、テスト哲学に関するものです。

はい、あなたは素晴らしいページを持っているかもしれません、そしてはい、あなたはそれを今日の場所に到達させるためにそれに対して20回の反復を行ったかもしれません。

数年後には、そのページ全体をもう一度オーバーホールする必要があるかもしれません。 環境の変化、使用される言語および用語、製品は微調整することができます。

常に古いキャンペーンに戻って再テストする準備をしてください。 （テストリポジトリを持つことがうまく機能するもう1つの理由。）

＃57。 パスのみをテストし、製品はテストしません

私たちのほとんどすべてが販売への道に焦点を合わせ、そのためのテストを行います。 しかし、現実には、製品はA / Bテストと改善も可能であり、より高いリフトを提供することさえできます。

iPhoneについて考えてみてください。

Appleはそのウェブサイトをテストし、それを改善しましたが、それは製品の反復と改善であり、さらに多くのリフトを推進し続けています。

今、あなたは物理的な製品を持っていないかもしれません。 プログラムやデジタルオファーがあるかもしれませんが、視聴者のニーズについて詳しく学び、それをテストしてから、それを販売ページに戻すことは、リフトの点で非常に大きなものになる可能性があります。

結論

だからあなたはそれを持っています。 私たちが目にする57の一般的およびまれなA/Bテストの間違いと、それらを回避する方法。

このガイドを使用すると、今後のすべてのキャンペーンでこれらの問題を回避するのに役立ちます。