[AEM Sites]{class="badge positive" title="AEM Sitesに適用）。"}

AEM as a Cloud Serviceのコンテキスト実験 contextual-experimentation

実験とは、パフォーマンスを向上させ、サイトをより効果的かつ合理化するために、サイトのデザイン、機能、コードをテストする手法です。 これを実現するには、コンテンツまたは機能を変更し、結果を以前のバージョンと比較し、測定可能な効果がある改善を選択します。

正しく完了すると、コンバージョン、エンゲージメント、訪問者エクスペリエンスを向上させる強力なパターンになります。 一般的に、この手法の採用を検討する際に避けるべき問題がいくつかあります。

Adobe Experience Managerで動作するサイトの場合は、開発者がサイトに実験機能を追加できる、「標準 ​​実験プラグイン」があります。 このアプローチは、他の実験フレームワークとは次の 3 つの点で異なります。

開始する前に before-start

実験プラグインは Edge Delivery Servicesのコンテキスト内で使用されるので ​Github アカウント、SharePointやGoogle Drive などのコンテンツリポジトリおよび 2}AEM Sidekick} が必要です。 ​ ​ はじめに – ユニバーサルエディター開発者チュートリアルページ ​ および ​ はじめに – 開発者チュートリアル ​ も参照してください。

すべての設定が完了したら このビデオをご覧ください​​ インスタント実験 ​ と題して、実験プラグインの仕組みを示す短いデモを行います。

よく使用される用語 frequently-used-terms

ガイドの残りの部分に従って最初の実験を設定する前に、よく使用する用語をいくつか理解しておく必要があります。

実験のバリエーションと一般的なワークフロー experiment-variants-workflow

一般的に、実験を設定する場合、既存のページをコントロールページとして使用します。 次に、一部の訪問者のコントロールページを置き換えるチャレンジャーページを作成します。 挑戦者ページでは、コンテンツのバリエーション、ページレイアウト、call-to-action（CTA）など、様々なものをテストできます。 コントロールページにメタデータパラメーターを追加することで、これらの実験バリアントを設定できます（以下を参照）。

次に、​ 運用上のテレメトリサービス ​ がデータを収集します。例えば、コントロールページとチャレンジャーページの訪問者数が収集されます。 その後、このデータを使用して、サイトに必要な改善点を選択します。 確立された web サイトのデザイン言語を使用し、既存のブロック機能を使用する限り、実験バリアントを設定して、数分で実稼動環境に送信できます。

実験識別子 experiment-identifier

開始する前に、トラッキングと分析を目的とした独自の識別子をすべての実験に指定する必要があります。 良い出発点は、実験の優れた一意の ID を見つけることです。これは「実験 ID」になります。 実験は、多くの場合、イシュートラッカーまたは管理システムで、イシュー ID に対して線形番号または相関しています。 実験 ID には多くの場合、プロジェクトのプレフィックス（OPT-0134、EXP0004、CCX0076 など）を使用します。

チャレンジャーページの作成 create-challenger-page

慣例により、/experiments/ folder ールに小文字の実験 ID （例：/experiments/ccx0076/）を含むフォルダーを作成することをお勧めします。 チャレンジャーのバリエーションのページはすべて、このフォルダーにあります。 このフォルダーは、ローカルリポジトリ（SharePoint や Goggle Drive など）に作成します。

実験フォルダーは次のようになります。

フォルダーを作成したら、そのフォルダーにコントロールページのコピーを配置し、実験バリアントの一部としてテストするページに変更を適用します（上記のビデオを参照）。 例として、実験を実行する web サイトに次のページがあるとします。

experiments/<experiment-id> フォルダーに配置された挑戦者のコピーは次のようになります。

サイドキックを使用して、挑戦者ページのオーサリングが完了したら、挑戦者ページをプレビューして公開します。 公開されたチャレンジャーの URL は、次の節の実験の設定で使用されます。

実験の設定 configure-experiment

チャレンジャーページの準備が整ったら、すぐにコントロールページに戻り、ページがテストに含まれていることを示すメタデータを追加する必要があります。

実験バリアントには、追加する必要があるメタデータ行が 2 つあります。

以下の例を参照してください。

実験ごとに、トラフィックはすべてのバリアント（コントロールチャレンジャーとチャレンジャー）に分割され、自動的に偶数分布に設定されます。 したがって、1 人の挑戦者がいる場合、自動的に制御と挑戦者の間で 50/50 の均等な分割が行われます。 2 人の挑戦者がいる場合は、制御に割り当てられたトラフィックの 3 分の 1 が自動的に表示され、各挑戦者などが表示されます。

メタデータを設定することで、トラフィックの分割を上書きできます。 実験で使用されるメタデータをカスタマイズする方法について詳しくは、次の ​ ページ ​ を参照してください。

実験のバリアントのプレビューとステージング preview-stage-experiment

実験をプレビューしてステージングする準備が整ったら、左上のサイドキックから「プレビュー」をクリックします。 実験が実行されているページをプレビューする場合は常に、.aem.page のプレビュー環境に実験のオーバーレイが表示されます。 実験オーバーレイを使用すると、実験のバリエーションを切り替えることができ、トラフィックデータも提供できます。

各バリアントの効果を測定するためのデータ収集は、AEM as a Cloud Serviceでの運用上のテレメトリサービス ​ に基づいています。

実験バリアントを実稼動環境に送信 production-experiment

実験ページを選択し、サイドキックから「公開」をクリックして、コントロールと挑戦者バリアントの両方をライブにプッシュします。

ユースケースの例 use-case-examples

実験のバリアントのユースケースの例をいくつか以下に示します。 一般的に、基本的なワークフローは上記のワークフローと似ていますが、ユースケースごとに特定の変更（挑戦者ページの数やメタデータの変更など）が行われます。

完全ページの実験 full-page

完全なページ実験を使用して、同じページの 2 つのバリアントをテストします。 これは、コントロールと挑戦者ページを持つ a/b テストの完全なページバリアントです。 チャレンジャーバリアントの「オリジナル」コントロールページのコンテンツ全体を別のタイプのコンテンツに置き換えます。 デフォルトでは顧客トラフィックは均等に分割（50/50）されていますが、必要に応じてカスタム分割を作成できます。

その他の注意点 other-considerations

コンテキスト実験を使用する際に考慮すべきその他の側面を以下に示します。

コンバージョン conversion

実験は、コンバージョンに対処するように設定されます（ページ上のクリック可能な要素を追跡します）。 すべての実験は、次の目的で定義する必要があります。

実験バリアントのインデックスが作成されていないことを確認します experiment-not-indexed

実験を実行する場合、通常は、サイトマップからバリアントを除外し、検索エンジンでインデックスが作成されないようにします。 これは、バリアントページが重複したコンテンツと見なされ、SEO に悪影響を与える可能性があるためです。

これを行うには、次の 2 つの方法のいずれかを使用します。

開発者向けリソースとテクニカルリソース dev-resources

Adobe Experience Managerは [ 運用上のテレメトリ ] （/help/sites-cloud/administering/operational-telemetry-for-aem-as-a-cloud-service.md

）、Adobe Experience Managerを利用したサイトで機能とパフォーマンスの問題を検出および修正するために不可欠なオペレーションデータを収集します。 運用上のテレメトリデータを使用して、パフォーマンスの問題を診断できます。 運用テレメトリでは、サンプリングを通じて訪問者のプライバシーを保持します（すべてのページビューのごく一部のみが監視されます）。

プライバシー privacy-experimentation

AEM as a Cloud Serviceの運用上のテレメトリサービス ​ は、訪問者のプライバシーを保護し、データ収集を最小限に抑えるように設計されています。 つまり、Adobeは、お客様の個人情報や、お客様に遡って追跡できる情報の収集を試みません。 サイトオペレーターは、以下に収集したデータ項目を確認し、同意が必要かどうかを把握します。
AEM Operational Telemetry では、使用状況指標を収集するために、cookie や localStorage、sessionStorage など、クライアントサイドのステートや ID を使用しません。 データは、ピクセルや同様の手法ではなく、Navigator.sendBeacon 呼び出しを通じて透過的に送信されます。 サンプリングされたデータを取得する目的で、IP アドレス、ユーザーエージェント文字列、その他のデータを介したデバイスや個人の「フィンガープリント」は行われません。

運用上のテレメトリデータ収集に個人データを追加することは許可されておらず、また、運用上のテレメトリデータは、厳密に必要な範囲を超えるユースケースに使用することもできません。

よくある質問 faq

よくある質問のリストを以下に示します。

Q：実験のバリエーション間の分割率（例えば、コントロールで 10%、挑戦者で 90%）を調整することはできますか？

はい、分割率は ​ メタデータ ​ で設定できます。

Q：テキストと画像の両方を試すことはできますか？

はい、バリアントは完全に異なるページになる可能性があるので、レイアウトの変更をテストすることもできます。