Digital Experience Optimization Program

ツール

• Optimizely: ライブのデジタル体験における変更を about.gitlab.com 上でテストし、統計的厳密性をもってその影響を測定し、実際のユーザー行動に基づいて自信を持って最適化判断を行うことを可能にする実験プラットフォームです。このツールにより、あらゆる技術レベルのチームメンバーが、ノーコードで操作できるエディタを通じて実験を実装できます。
• Figma: 実験の実装を進める前に、チームが視覚的にアイデアを練り、実験のモックアップを作成できるデザインプラットフォームです。
• ContentSquare: 実験対象の機会領域やフローについて、セルフサービスでデータ分析（エンゲージメント指標、ヒートマップ、セッション再生、サーベイなど）を可能にするアナリティクスプラットフォームです。
• Google Analytics: トライアル登録の指標について、テスト結果のパフォーマンスと組み合わせて使用するアナリティクスプラットフォームです（Optimizely は現在 gitlab.com には実装されていないため）。
• Tableau Digital Experience Dashboard: ページのトラフィックデータと平均ページコンバージョン率をセルフサービスで取得できるアナリティクスプラットフォームです。

方法論

Step 1: 機会モデル

実験対象としてインパクトの大きな領域を特定するため、各領域がどの程度のインパクトを生む可能性があるかを理解する助けとなる「機会モデル」を使用します。

機会ステートメントの例: 「DevSecOps Free Trial ページの高価値フリートライアルコンバージョン率を 10% 改善できれば、同じリードあたりコストで通年 900 件の追加高価値トライアルにつながる可能性があります — または、同じ量のリードを 10 万ドル安く効果的に生成できる可能性があります。」

Step 2: 仮説ステートメント

問題、その問題がどう解決され得るか、そしてそれが解決されたとどう判断するかを効果的に確立するため、仮説を策定します。

機会ステートメントの例: 「DevSecOps Free Trial ページにおけるコンバージョンへのパスを単純化し、不要なリンクを削除して補助コンテンツを単純化すれば、フリートライアル CTA のクリックスルー量がより高くなり、最終的に高価値フリートライアルコンバージョン量がより高くなる可能性があると考えています」

Step 3: 実験の実行

このセクションでは、さまざまなテストタイプと統計的厳密性の期待値について概説します。実行するテストは、統計的有意性テストか、方向性（“do-no-harm”）テストのいずれかになります。統計的有意性に到達するまでの所要時間が 3 週間未満であれば、それは統計的有意性テストタイプとみなされます。統計的有意性に到達するまでに長期間を要すると予測されるテストは、明確な証明よりも学習速度を優先する方向性（“do-no-harm”）テストとして分類される場合があります。

テスト期間の決定には Duration Estimate Calculator を使用します。

テストタイプ: 統計的有意性テスト テスト結果が 80〜95% の信頼度に達すれば、どのバリアントで進めるかについて明確な判断を下せます。勝者バリアントが実装された場合の年間インパクトを予測できます:

期間と信頼度ステートメントの例: 「Free Trial DevSecOps ページで新バリアントレイアウトをコントロールレイアウトに対してテストするには、80〜95% の統計的有意性に到達するまで 1〜2 週間かかります。」

*MDE（Minimum Detectable Effect、最小検出効果）はテスト対象の変更の規模によって決定されます。軽微な改良（ボタンの色、コピーの微調整）は 10% MDE、中規模の変更（フォームフィールドの変更、CTA の再配置）は 20% MDE、大規模なリデザイン（新しいレイアウト、テンプレート変更）は 20%+ MDE を使用します。

テストタイプ: 方向性テスト（“Do-no-harm”） テストは 2〜3 週間実行し、それが完了すればテストは終了します。結果を使ってどう進めるかについて方向性のある判断を下します:

期間と信頼度ステートメントの例: 「Why GitLab ページの主要 CTA のラベルを変更するテストは 2〜3 週間実行し、その結果に基づいて方向性のある判断を下します。」

Step 4: 結果の意思決定フレームワーク

実験はさまざまなタイプの結果を提示します。最終的なテスト結果が出たら、私たちはこの意思決定モデルを使ってアクションを決定します。

結果意思決定ステートメントの例: 「DevSecOps Free Trial Page テストにおけるバリアントは、高価値トライアルコンバージョンを +10% 増加させたため、バリアントの実装を進めます。」

テストの実行方法

Step 1: アイデア発想

GitLab の誰でも実験アイデアをコントリビュートできます。

1. 「experiment」Issue テンプレートを使って Issue を作成し、仮説セクションを記入します。

2. Issue は自動的に DEx Design Manager と Marketing Analyst にアサインされ、残りのセクションと実験のセットアップが完了します。

   • UX Designer: 視覚エディタを使った最初の実験セットアップとバリエーションデザインの責任者。
   • DEx Engineer: 視覚エディタの能力を超える高度な設定を必要とする実験を担当。これには utilities の使用が必要になることがあります。
   • Marketing Analyst: オーディエンスターゲティング、トラフィック割り当て、ロールアウト戦略、成功指標の定義を管理。

3. ローカライゼーションの考慮事項: ローカライズされたパスに対して別々の実験が必要かどうかを判断する場合:

   • テキストベースのバリアント: 翻訳されたテキストが意図したメッセージを維持しているかを Localization チームに確認します。意味が大きく異なる場合は、ローカライズページに対して別々の実験を作成します。
   • 非テキストバリアント: デフォルトの英語ページのみで実験します。

Step 2: 優先順位付け

DEx Experimentation Roadmap Google Sheet には計画された実験と優先度スコアリングが含まれています。

Step 3: 実験のデザイン

1. DEx Designer が Figma でモックアップを作成し、Design Manager のレビューと承認を必要とします。

2. Marketing Analyst が以下を定義します:

   • オーディエンスターゲティング
   • トラフィック割り当て
   • ロールアウト戦略
   • 成功指標
   • 推定期間

Step 4: Optimizely 設定

実験のセットアップ

命名規則: [ページパス] - [実験名]

例:

• Home - Hero Trial CTA
• /pricing/premium/ - Anchor Links Blue vs Green
• /why-gitlab/ - Sticky CTA vs Fixed

説明: 仮説、デザイン変更、GitLab Issue へのリンクを含めます。

Target By（ページ）:

1. まず “Saved Pages” の下で既存ページを検索する
2. ページが存在しない場合は “Create New Page” をクリック
3. ページパスを Name として使用する（ホームページは除く）

例:

• Home
• /pricing/
• /sales/
• /solutions/supply-chain/

バリエーション命名規則:

• Control: [要素名]（例: “Control: Get Started”）
• Variant: [要素名]（例: “Variant: Free Trial”）

オーディエンスターゲティング

“ターゲット化された実験は、一般的な体験よりも特定のオーディエンスに対して 41% 高いインパクトを生み出すことができる”

Optimizely は複数のターゲティングオプションを提供します:

• 標準属性: デバイスタイプ、ロケーション、ブラウザ
• 行動ターゲティング: Web ブラウジング行動に基づく
• サードパーティ統合: Google Analytics と 6Sense オーディエンス（Sales Segments — SMB、MM、ENT を含む）

トラフィック割り当て

実験がリスクが高いとみなされない限り、デフォルトは 100% です。リスクが高い場合は、徐々に 100% にロールアウトします。

トラフィック分布

• トラフィックの多いページ: 50/50 の手動トラフィック分割を使用
• トラフィックの少ないページ: 統計的有意性により早く到達するために、現在勝っているバリアントにより多くのトラフィックを割り当てる “Stats Accelerator” 分布モードを検討
• 一般ルール: トラフィック分布は常に均等分割であるべき

指標

新しい指標を作成する前に: イベントが既に存在しないかを確認して重複を避けます。

指標タイプ:

• Click Event Metric: クリックベースの指標用
• Page View Metric: ページヒットに基づく（例: 確認ページ）
• Custom Event Metric: その他すべてのイベント用（Google Tag Manager 統合が必要）

命名規則: [指標タイプ] - [ページ／領域名] - [要素名]

例:

• Click - Home - Free Trial
• Custom - /sales/ - Form
• Click - Navigation Menu - Platform

Step 5: QA とパブリッシュ

QA チェックリスト:

• Designer: デスクトップとモバイルのレイアウトを検証
• Designer: モックアップに基づいて視覚的要件が満たされているか検証
• Analyst: すべてのバリアントのトラッキングを検証
• Analyst: Optimizely と Google Analytics で指標が正しくトラッキングされていることを確認

承認プロセス: すべての実験は本番環境にローンチする前に Design Manager、Engineering Manager、Director of DEx、または Marketing Analyst の承認が必要です。

ローンチ時間: 火曜日から木曜日がローンチに好まれることが多く、月曜日（週末後にユーザー行動が不規則になる可能性がある）と金曜日（週末のモニタリング問題を避けるため）は避けます。また、1 日の早い時間（ターゲットオーディエンスの朝の時間帯）にすると、問題をモニタリングし、必要に応じて調整する時間を確保できます。

注意: 実験がパブリッシュ後に編集が必要になった場合、新しい実験を作成する必要があります。そうしないとデータが歪む可能性があります。

Step 6: 分析と次のステップ

実験が統計的有意性に達すると（理想的には 95% の信頼度）、Marketing Analyst が最終結果を提供し、Issue で勝者を宣言します。

任意: チーム可視性のために #digital-experience-team Slack チャンネルで結果を共有します。

結果に基づく次のステップ:

• バリアントが勝った場合: Designer は次を行います:

  • バリアントをトラフィックの 100% にロールアウト
  • 勝者デザインを恒久的に実装するための新しい Engineering Issue を作成
  • 恒久実装が本番に反映された後に実験をオフにする

• コントロールが勝った場合またはデータが結論不能の場合: Designer は実験をオフにします。

Step 7: アナウンス

実験がローンチされたら、チーム可視性のために #digital-experience-team Slack チャンネルでアナウンスします。Designer は結果に基づく次のステップで Issue を更新します。

ページのソースコードを見る - ページの編集 - please contribute.