本格的な実験プログラムを実行するための要件

公開: 2023-04-11

実験プログラムの実行は芸術であり科学です。 私はいつもそれを言います。 プログラムには、システム、プロセス、および手順を意味する、ある程度の厳密さが必要です。 軽々しく扱うものではありません。 最小限の準備と計画で明日からプログラムを開始できると考えるのは誤りです。 残念ながら、それは常に起こります。 当然のことながら、多くのお金、時間、労力が無駄になります。 これは、準備のトピックにつながります。

実験に真剣に取り組み、市場での競争力をレベルアップしたい場合は、うまくやった方がよいでしょう。 競合他社がうまくやっていると想定する必要があります。 これがあなたの心に響くなら、読み続けてください。金塊を1つか2つ手に取ってすぐに使用できることを保証します.

成功するか失敗するかを決める実験プログラムを構築する前に避けられない前兆: 事前テストの計算

テスト前の計算。 それらについて聞いたことがありますか? あなたはそれらをしましたか? MDE または検出可能な最小効果は聞き覚えがありますか? 期間の見積もりやサンプルサイズはどうですか? 私が話していることを知っていることを願っていますが、私自身のクライアントとの個人的な経験のために、あなたの大多数が知らないお金を賭けています.

実験に関連する何かを行う前に、それを行うのに十分なデータ量があるかどうかを確認してください。 テスト前の計算を通じて、テストできるかどうかを確認してください。 データ量とは、訪問者とコンバージョンを意味します。 訪問者は、通常使用するものであれば何でもかまいません (セッション、ユーザー、MAU など)。 コンバージョンは、テストで使用する主要なメトリックからのものです。 これを知っています:

  1. すべての企業が、任意の容量で実験を行うのに十分なデータ量を持っているわけではありません。
  2. もしそれができるなら、希望の速度をどこからともなく選ぶだけではないことを知っておいてください。 計算に基づいています。

これらのポイントの 1 つまたは両方を無視する最大の犯人は、営業担当者です。 あらゆる種類のツールの購入を検討している場合は、これが会話の一部であることを確認してください. 実験プログラムに参加するための最低限の障壁: 1 つのスイムレーンで 8 週間以内に 1 つのテストを実行するのに十分なデータ量。

このトピックについては、数か月前に Experiment Nation で詳しく取り上げました。 このトピックを理解せずに最初から実行すると、最終的に何らかの望ましくない結果を招くことになることを知っておいてください. もう 1 つの非常に重要な注意事項: テスト ツール (または使用する予定のツール) が固定期間テストまたは逐次テストに基づいて構築されているかどうかを確認してください。 これは、計算とプログラムの実行方法に影響します。

ステップ 1 (ポスト前駆体): 測定とデータ品質

テスト前の計算のハードルをクリアし、テストするのに十分なデータ量があることを確認したら、次のハードルは測定とデータ品質です。 この仕事で何を目指しているのかを知らなければなりません。 そうしないと、川岸の魚のようにヒラヒラしてしまいます。 フォームの送信、トランザクション、収益、LTV など、何に取り組んでいるのかを理解していないチームが多すぎます。

実験とビジネス全体のための主要、第 2、第 3 の指標が何であるかを理解します。 完全に明確に理解してください。 長引く混乱や不確実性を許してはなりません。 全員が同じページにいることを確認してください。

次に、十分なデータが得られたら、適切な場所でそのデータを収集していることと、それが信頼できることを確認してください。

測定やデータ品質に問題がある場合は、停止してください。 すべてを止めて、それを正しくするために全力を尽くしてください。 実験をピラミッドと考えてください。 この 2 つは、ピラミッドの基盤となる層です。 いつでもひびが入ると、その上に他のすべてが崩れます。 約束します。

私はこれらが難しいことを知っていると言います。 それらを正しく理解するには、さらに時間がかかる場合があります。 ひょっとしたら1、2ヶ月以上かもしれません。 ただし、それらを正しくすることには価値があります。 私は、プログラムを開始してから 6 か月以上後に問題が発生するのを見てきました。 その時点で誰も幸せではありません。

主要な指標がどうあるべきかについてのメモ…

これは時々、開業医の間で意見が分かれる話題です。 私はこの問題について非常に確固たる立場を持っています。特に、マーケティング チームや Web サイト (必ずしも製品チームや製品であるとは限りません) に関してはそうです。

プライマリ メトリックは常にダウン ファネル メトリックである必要があります。 注文。 フォーム送信。 MQL。 収益。 LTV。 SQL。 あなたはアイデアを得る。 自分が行っている変化やエンゲージメント指標に常に最も近いアクションであるべきだと言う人もいます。 間違い。 いいえ。 正しくない。 BS。 これをあなたに言う人は誰でも、会社の CMO または CEO に対して、6 か月または 1 年でプログラムを正当化する必要があるはずです。 彼らはホットシートになります。 ボタンのクリック、クリックスルー、ページビュー、平均に焦点を当てたテストでいっぱいのプログラムを用意しないでください。 セッション継続時間、離脱率、直帰率、動画再生回数など。 これでは、この作業に何千ドルも何十万ドルも費やしたことを正当化することはできません。 誰もが自分の ROI と、その作業が収益にどのような影響を与えたかを知りたがっています。 ボタンのクリックではそれができません。

エンゲージメント指標や目標到達プロセスの上位指標を測定するなと言っているわけではありませんが、それらは二次的または三次的な指標であるべきです。 一次的なものではありません。 テストのストーリーにコンテキストを追加します。 それらは、決定を下すときにテストが左右されるものではありません。 また、決して例外がないと言っているわけではないことに注意してください。 ケースバイケースでテストを評価します。

アドバイス: このトピックについて議論している方へ、私は常にチームにオプションについて話し合い、自分で決めるように伝えています. 全員が前進することを順守するという総合的な結論に達していることを確認してください.

ステップ 2: ユーザーの調査と構想

この時点で、(1) テストするのに十分なデータ量があること、(2) 何を測定しているか、信頼できる適切なデータを収集していることを確認する必要があります。 では、次は何ですか? 何をテストするかを考えています。 あなたのテストのアイデアは何ですか? それらをどのように生成しますか?

ほとんどのチームが何をしていると思いますか? 彼らは直感と多くの「私たちが考える」、「私たちが感じる」、「私たちが信じる」から外れます。 これはあまりにも主観的であり、プログラムを実行するにはひどい方法です。 そのアプローチは、データに裏付けられたものではありません。 これは、専門家が「スパゲッティ テスト」と呼んでいるもので、別名、壁に物を投げつけて、それがくっつくことを望んでいます。 データに基づく会話では、そのような言語はあまり使用されず、必要なデータはユーザー調査から得られます。 「研究」とは何かとよく聞かれます。

データを収集する方法論はいくつかありますが、これらには分析、投票、調査、ユーザー テスト、メッセージ テスト、ヒートマップ、セッション記録、カード ソーティング、ツリー テスト、カスタマー ジャーニー マッピング、ペルソナなどがあります。 これらのそれぞれを完了するのに役立つツールもいくつかあります。 私はいつも、1つまたは2つから始めて、そこから他のものへと進んでいくと言います. それは確かに何もないよりはましです。 技術的には、最近はすべての企業が分析データを持っているため、私はもはや分析を数えません。 それがない場合は、揚げる魚が大きくなる可能性があります。 ただし、それを持っている場合は、それよりも 1 つまたは 2 つ努力してください (「大丈夫です」とは言わないでください)。

ヒューリスティック評価と呼ばれる方法論があります。 それは、誰かが経験を視覚的に評価し、経験と専門知識に基づいて洞察を開発するときです。 それには時と場合がありますが、ほとんどの場合、「ハード データ」に裏付けられたものではありません。 これはかなり主観的なもので、完成させる人によって多少異なります。 プログラムは、これらの種類の洞察に基づいてはならないことを理解してください。

ここでは調査の方法について詳しく説明するつもりはありませんが、CXL の ResearchXL モデルについて詳しく説明している私の VWO ウェビナーの 1 つをチェックしてください。

ステップ 3: 優先順位付け

テストのアイデアのリストができたら、それらすべてを一度に実行することはできません。 アクション プランを作成するには、戦略的かつ論理的な方法が必要です。 ここで、優先順位付けのフレームワークが役立ちます。 多く存在します。 私が特に気に入っているのは、CXL の PXL フレームワークです。 その他の一般的なものには、PIE、ICE、または PILL があります。 私の意見では、PXL が最も客観的です。 カスタマイズ可能で、より堅牢です (良い意味で)。

他のモデルは問題なく、何もないよりはましです。 あなたが何かを持っていて、それがあなたのために働いているなら、素晴らしい. 1 つ持っているだけで、みんなが使っていることを確認できます。 余分な混乱に対処する必要がなくなります。

ステップ 4: ロードマップ

ロードマップは、特定の時点で何が実行されているかを視覚的に示します。 優先順位付けとテスト前の計算とブームを組み合わせます。 ロードマップがあります。 これらは、ガント チャートで行うのが最適です。 すべてのスイムレーンとテストを、推定所要時間、デバイス、およびその他の役立つメタデータとともに追加します。 不要なオーバーラップや不要な相互作用の影響を回避できます。 誰もがより効果的かつ効率的に計画を立てるのに役立ちます。 これにより、さらなる混乱からあなたを救うことができます。

例
明確なロードマップを構築するために使用できるガント チャートの例

ステップ 5 以降: 通常どおりのビジネス

これまで説明してきたことはすべて終わったので、通常どおりです。 実行するテストが手元にあります。 モックアップ > 設計 > 開発 > QA > 立ち上げ > 監視 > 結論 > 分析 > 共有とアーカイブ > 繰り返しという通常の実験ワークフローを通じて送信します。

関連トピック: プログラム管理とガバナンス

個々のテスト以外にも、「プログラム」全体に関連して考慮すべきトピックがあります。 これらには、プログラム管理とガバナンスが含まれます。 これが私がそれらについて非常に煮詰めた方法でどのように考えるかです…

プログラム管理: このすべての作業をどのように整理して追跡しますか? タスク、データ管理、およびコミュニケーションに使用するツールを把握します。 (その内訳は、Speero の CEO である Ben Labay から入手しました。)

ガバナンス: 全員にはどのような役割と責任がありますか? これを判断するのに役立つ方法は、(1) ガバナンス モデルを選択し、(2) ガバナンス モデルに合わせて RASCI チャートを完成させることです。 調査および検討すべき一般的なガバナンス モデル: 個別、集中型、分散型、センター オブ エクセレンス、テスト カウンシル、およびハイブリッド。

これらの両方を他のすべてで突き止めないと、さらなる混乱が生じ、すべての段階でその代償を払うことになります. これらを釘付けにします。 余分な時間がかかりますが、それだけの価値があります。 しばらく物事をハックすると、結果は最終的に追いつきます。 約束します。 (どうやら、私はここでかなりの数の約束をしたようです。)

結論

実験を開始するために何ができるか、またはすでに実行されているプログラムをレベルアップするために何ができるかについて、少し (またはかなり) 自信を持って感じる必要があります。 難しすぎる、または簡単すぎると感じないでください。 だいたい真ん中あたりです。 私が言及したすべてに当てはまる私の最大の推奨事項は、クォーターバックを持つことです。 このすべての作業をリードする人が必要です。 フルタイムの役割である必要はありませんが、誰かが担当する必要があります。 それは通常、私が最も成功したときです。

締めくくりとして、厳密さ、結果、そしてちょっとした楽しみが散りばめられた実験プログラムができたことを願っています。

実験がどのように革新と成長を促進し、誇大広告に値するかについて詳しく知りたい場合は、VWO との最新のウェビナーをご覧ください。