SPA や動的 Web サイトでの AB テストが失敗する理由とその危機を救う方法!

JavaScript を使用した Web サイトで AB テストの実行を検討している場合、多くの間違いが発生する可能性があります。 テストは SPA、SSG、または SSR を利用したサイト内で可能ですが、見落とされやすいいくつかの重要な機能がなければ、AB テストは不可能になる可能性があります。

これらの機能のないツールを選択すると、開発チームにすべてのテストを手動でコーディングすることを余儀なくされたり、実験データが無効になって成功率に影響を与えたり、最悪の場合、次のようなツールを購入することになる可能性があります。あなたの会社では使用できません（私はこれを何度も見ました）

AB テストを始めようと考えている方で、React、Vue、Angular、NextJS、Astro、Svelte などを使用している方には必読の記事です。 このガイドでは、AB テストが失敗する 2 つの大きな理由と、AB テストを確実に成功させるためにできることについて説明します。

バケット化

本題に入る前に、Web サイトにクライアント側の AB テストを実装する場合は、通常、AB テスト ツールとその JavaScript スニペットをサイト内にインストールする必要があることに注意する必要があります。

この JavaScript スニペットは、編集者が AB テスト ツール内で変更を加え、サイトに適用できるようにする魔法です。

テスト作成の一環として、人々を追加する資格を与える方法のルールを決定する必要があります。 このプロセスは、実験内のユーザーのバケット化として知られています。 ユーザーをバケット化する場合、次の 2 つのチェックを行う必要があります。

これら 2 つの問題は異なるソリューションで解決されますが、どちらも成功には非常に重要です。

従来の Web サイト内では、ユーザーがサイト内を移動するときにリンクをクリックします。 リンクをクリックすると、サーバーに対してリクエストが行われ、リクエストされたページを取得します。 そのリクエストの一部として、サーバーはそのページを最初から生成するか、キャッシュからバージョンを取得してユーザーのブラウザに返します。

従来の Web サイト内でユーザーをバケット化するのは簡単です。 Web ページが読み込まれたときと、実験スニペットが読み込まれた後に、その人を実験に追加する必要があるかどうかを確認するだけで済みます。

SPA 内でテストを実行する場合、これは機能しません。 SPA 内では、最初の HTML と JavaScript がサーバーからダウンロードされた後、ユーザーは再度サーバーと通信する必要がない場合があります。 従来の方法を使用すると、ユーザーを実験に追加できるのは、そのユーザーが最初にページにアクセスしたときのみであり、それで終わりです。

ツールが従来のバケット化方法のみをサポートしている場合、そのツールはゴミです。 優れた AB テスト ツールであれば、動的 Web サイト内で人々がどのように対話するかの性質をサポートするテストに誰かをバケットに入れる方法を提供する必要があります。 私が最もよく使っている AB テスト ツールは Optimizely Web です。 このツールでは、次のような動的 Web サイト バケット化オプションをいくつか利用できます。

これらのオプションをカバーするために、次のものがあります。

• URLが変更になった場合: ページ全体がリロードされない場合でも、ブラウザ内で URL が変更されるたびにアクティベーションがトリガーされます。
• DOM が変更されたとき: ページ上の要素が変更される (追加、編集、削除など) たびにアクティベーションをトリガーします。
• 手動で: このモードは主に、Optimizely 内の Optimizely Edge と呼ばれるパフォーマンス モードを使用するときにアクティブ化するためのものです。
• コールバックが呼び出されたとき: コールバック関数と作成したカスタム JavaScript に基づいてアクティベーションをトリガーします
• JavaScript 条件が true の場合: ページに対して実行されるカスタム コードに基づいてアクティベーションをトリガーします。

ツールがいつチェックするかを定義したら、次は満たす必要のあるルール/基準を定義します。 Optimizely lingo 内のこれらのルールは「条件」と呼ばれます。 Optimizely は次の条件をサポートします。

• URLターゲティング: ページの URL を使用します。 ここでは、単純な一致に一致するようなルールを追加できます。
• 要素がページ上に存在します: ページ上に 1 つ以上の CSS セレクターが存在する場合、誰かの参加を許可します。 この機能では、 document.querySelectorAll() 要素が存在するかどうかを判断するには
• カスタムJavaScript: これにより、開発者は JavaScript を使用してカスタム ルールを作成し、ページ上の特定の条件 (データ レイヤー オブジェクトの値など) をチェックすることができます。

ツールがこれらのタイプのバケット化オプションをサポートしている限り、問題はありません。 これを読んでいる Optimizely Web 顧客でこれが機能しない場合は、この設定が有効になっていることを確認する必要があります。

ターゲティング

動的な JavaScript を使用した Web サイト内でクライアント側の AB テストを成功させるための次の重要な考慮事項は、ターゲティングです。 クライアント側ツール内で、ビジュアル エディターにアクセスできるようにする必要があります。 このエディタを使用すると、技術者以外の人でもテストを作成できます。 これは、開発者が他の作業に集中できるようになるため、便利です。

エディター内で変更が行われると、各変更は Web ページ上の位置に関連付けられます。 その位置を決定する方法は、通常、サイトの HTML 構造を介して行われます。 通常、AB テスト ツールは要素の位置を使用して、変更を適用する必要がある場所を決定します。 この選択プロセスはターゲティングとして知られています。

ビジュアル エディターの要素セレクターは、変更を適用する場所を決定するために、ページ上の HTML 要素の位置、要素のクラス名、または要素 ID を使用することがあります。 サイトで CSS モジュールのようなものを使用している場合、ビルド時にクラス名がフレームワークによって動的に生成されるため、これが一部の AB テスト ツールがサイトで正しく動作するための障害となる可能性があります。

サイトで動的クラス名を使用している場合は、テスト ツールがこれをサポートできることを確認する必要があります。 そうしないと、ビジュアル エディター ツールを使用できなくなります。

考えてみてください。この設定では、コードを運用環境にリリースするたびにクラス名が変更される可能性があります。 これが発生すると、古いクラス名に依存する既存のテストは、コードが変更されるとすぐに機能しなくなります。 これが発生すると、テスト データが無効になり、テストの変更が正しく適用されなくなり、ページが破損する可能性があり、少なくともサイトがプロフェッショナルではないように見えます。

これを修正する方法は、代わりに追加の ID または属性をコンポーネントに適用することです。 Optimizely では、詳細タブ内から使用する属性を有効にすることができます。 ここで属性の名前を追加できます。

この機能を有効にした後、コード内でコンポーネントごとに対応する属性を追加し、決して変更されない一意の値を与える必要があります。

ダイナミック ターゲティング モードがアクティブ化されると、スニペットは最初にこの属性を検索します。 見つからない場合は、代わりにクラスまたは HTML 構造を使用するようにフォールバックします。 このタイプのモードは、動的クラス名を使用するサイトには不可欠です。

このような機能がないとABテストはできません！

要約すると、Web サイトでクライアント側のテストを実行したい場合は、ユーザーを正しくバケット化できること、および動的クラス名を使用している場合でもビジュアル エディターが HTML 内で動作することを確認する必要があります。 これをサポートできないツールを選択すると、テストを正常に実行できなくなります。 コーディングを楽しんでください 🤘