GitLab におけるコンバージョンのためのテスト
GitLab では、デザインやコピーの変更に対する仮説を検証するために、変更のテストを実施しています。これらの変更にはさまざまなツールや手法を用いることがありますが、目的は同じです。すなわち、訪問者体験を改善し、GitLab の価値をよりよく伝えるための変更を行うことです。
私たちは、誤字修正、リンク更新、その他のサイト構造改善のためのテストは行いません。
目標
- 私たちの仮説を検証し、挑戦すること
- ビジネスインサイトを得ること
- 顧客体験を改善すること
常にテストを行う
テストでは、同一の期間内にコントロール（基準）とバリアント（変更案）を用意し、その他のすべての変数は一定に保つ必要があります。A/B テストツールを使用することで、テストのベストプラクティスに従ってテストを作成し、サイトでの滞在時間やフォームでのコンバージョンを促進する上で何が機能するか・しないかについてデータを収集できます。テストにより、対象オーディエンスにとって何が機能して目標達成を助けるか、また私たちにとって何がビジネス目標達成を助けるかについて、情報に基づいた意思決定が可能になります。
テストの種類
ウェブサイトテスト
- A/B テスト: ページの 2 つのバリアントをテスト
- A/B/n テスト: ページの 2 つ以上のバリアントをテスト
- 多変量テスト: 2 つ以上の異なるセクションを持つバリアントをテスト
- リダイレクトテスト: 異なる URL またはパスで識別される個別のウェブページをテスト
- パーソナライゼーション: ターゲット訪問者向けにページをパーソナライズ
ウェブサイトまたはメールテストのリクエスト
- テストの構築: A/B または多変量テストをリクエストしたい場合は、このテンプレート を使ってデジタルマーケティングプログラム向けに Issue を作成してください。
- MVC を意識する: すべての変更をテストする必要はありません。テストすべきなのは主要なコンバージョンページへの変更であり、以下のページ・要素はよくテストする重要領域です:
- ホームページ
- トップナビゲーション
- 価格ページ
- 無料トライアル
- 営業へのお問い合わせ
- テスト対象のページがあるかどうか CODEOWNERS を確認してください。
#Active testsセクションを更新しており、@shanerice と @dmor がアクティブなテストのある MR でレビュアーとして表示されます。
実験を始める前に
ヒートマップ、アナリティクス、メトリクス、KPI（重要業績評価指標）など、関連するデータを必ず収集してください。
テストの告知
主要なテストについては Slack の #whats-happening-at-gitlab で告知します。主要なテストとは、過去 30 日間で 10,000 ページビュー以上のページに対するものを指します。たとえば、/pricing/ や /free-trial/ とそのサブページ、ホームページに対するテストは、すべて主要テストに該当します。告知では、テストの基本的な詳細とタイムラインを共有し、追加コンテキストとしてテスト Issue へのリンクを記載します。
テストの DRI は、適切なチャンネル（#sales、#marketing など）に元の Slack 告知をシェアする必要があります。
テストツール
テストの種類によって異なるツールを使用しています。
フィーチャーフラグテストは、ページ全体やページの大きなセクションをテスト用に置き換えます。
WYSIWYG テストは、ページの小さな要素を置き換えたり、コピーを更新したりします。
Hotjar テストは、テスト前後の調査用にページ上のインタラクションを計測します。
フィーチャーフラグによるテスト
これは私たちがテストの大半を実施する予定の方法です。複数のテストを同時に走らせることができ、ページ全体・部分・コンポーネント・小さな変更に使えます。現在、フィーチャーフラグテストには Launch Darkly を使用しています。このツールは @bradon_lyon が管理しており、ツールに関する質問は彼に連絡してください。テストのリクエストは AB Test テンプレート で行えます。
Launch Darkly はクリックデータでテストを計測するため、Cookie ベースのアナリティクスよりも正確にインタラクションを計測できます。このデータは、Google Analytics や Snowplow といった Cookie ベースのアナリティクスとは整合しないことに注意してください。
コントロールとテストのバリアントは、レビューアプリでも、?experiment-review-control や ?experiment-review-test を使えば about.gitlab.com 上でも、それぞれ確認できます。
フィーチャーフラグのベストプラクティス
フィーチャーフラグはインクルードシステムと同様の形でコードに実装してください。例:
- サードパーティサービスにログインし、フィーチャーフラグと関連する設定変数を作成します。
- インターフェース内でそのフラグの所有権を割り当てます。
- ページを編集します。
- ページの既存コンテンツを
/source/experiments/1234-control.html.hamlという名前のインクルードファイルに入れます（ここで experiments は includes ではなくフォルダ名、1234 は関連する Issue の ID 番号）。「Control」とはテスト対象のベースライン計測値を指します。 - そのインクルードファイルを
/source/experiments/1234-test.html.hamlという名前で複製します。 - 変更を加え、デプロイ前にローカルやレビューアプリでフィーチャートグルが動作することを確認します。
- 必要なすべてのデータを収集できるようにします。ヒートマップやアナリティクスなどの適切なツールを設定します。
- フィーチャーフラグの利点の一つは、オンにせずに本番リリースできることです。
- 準備が整ったら、テストを有効にします。データ収集を開始します。
- 必要に応じて、ベースラインデータを収集するためにコントロールのみで実験を実行します。
CDN によるテスト
これは大規模な変更をシステムレベルでテストするための高度なツールです。当面、これは一度に 1 つだけ実行する予定です。
WYSIWYG によるテスト
これらのテストには Google Optimize を使用します。大規模なテストではパフォーマンスへの影響があるため、このプラットフォームは少数の CSS 要素やコピー変更のテストにのみ使用します。
任意のページで Google Optimize を有効にするには、ページのフロントマターに google_optimize: true を追加します。
Hotjar によるテスト
このリンク から、about.gitlab.com のページに対するヒートマップテストや結果をリクエストしてください。
新しいヒートマップは、ページが 2,000 ページビューに達するまでデータを記録し続けます。サーチマーケティングマネージャーが結果が完了したらお知らせします（所要時間はページの平均トラフィックに依存します。テストによっては 1 か月以上かかる場合もあります）。
注: 訪問者が見るすべてのページは、1 ページビューとしてカウントされます。
テストローンチチェックリスト
テストをローンチするときには、インバウンドマーケティングチームが通知すべき GitLab チームメンバーが多数います。最大限カバーするため、#whats-happening-at-gitlab で 1 つのメッセージを投稿し、以下のチャンネルにクロスポストします。追加のチャンネルがあれば追加し、テストを追跡したい全員に通知できるよう、#search-marketing-team でサーチマーケティングチームに連絡してください。
オリジナルの更新を共有するチャンネル:
#marketing#sales#ceo#support_team-chat#s_growth
