クライアント側のテストとサーバー側のテスト：両方が勝ちます。

実験の実行に関しては、オプティマイザーはクライアント側とサーバー側のテストを選択できます。

サーバー側でほぼすべてのクライアント側テストを実行でき、クライアント側テスト（分割URLまたはリダイレクト実験を使用）を介していくつかの軽量バックエンドテストを実行できますが、実行することは、実行可能または堅牢ではありません。 d like…どの仮説でも、2つのうち1つだけが最適に機能するためです。

そして、適切なものを選択するには、慎重に検討する必要があります。 この選択を行う際に考慮すべき多くの側面があります。 セットアップが速度とSEOに与える影響、実験のライフサイクルに必要な労力と時間、実験の目標などを確認してください。

これらの要因を調べて、クライアント側のテストがサーバー側のテストとどのように異なるか、およびそれぞれの長所と短所を見てみましょう。

クライアント側のテストとサーバー側のテスト

ただし、それはクライアント側のテストを割り引くことになります。

クライアント側のテストは単純に見えるかもしれませんが、それは強力です。

クライアント側のA/Bテストは、誰でもできる「簡単なテスト」として簡単に却下できます。 同意しました：実装は簡単です。 また、別のCTAボタンの色やコピーをテストするのと同じくらい小さい場合もあります。

しかし、これであろうと、再設計や刷新されたページのテストと同じくらい大きなものであろうと、クライアント側のテストはビジネスの収益に影響を与えます。

このケーススタディでは、SaaS企業がクライアント側のA / BテストツールとしてConvertExperiencesを使用して、ホームページでリードの成長を61％増加させました。

これは、同じSaaS企業のクライアント側テストツールとしてConvertExperiencesを使用した別のA/Bテスト実験で、価格設定ページでリードが57％増加しました。

オンラインで見られるコンバージョン最適化の成功事例のほとんどは、表面レベルでのエクスペリエンスの最適化に成功し、大きな成果を上げたクライアント側のテストです。

しかし、サーバー側のテストでは、実際にさらにテストすることができます。

フロントエンドよりも深くテストする必要がある場合は、サーバー側のテストを行う必要があります。

いくつかのシナリオでこれを見通しに入れましょう。

eコマースビジネスの場合は、クライアント側のA / Bテストの実験を使用して、再設計された検索バーが店舗での検索を増やすことができるかどうかを知ることができます（結果として売上が増加します）。

ただし、より関連性の高い検索結果を表示できる（長期的には売上が増える）新しい検索アルゴリズムをテストする場合は、サーバー側のA/Bテスト実験を実行する必要があります。 。

代わりにB2BSaaSビジネスの場合は、クライアント側の実験を実行して、特定のUVPがホームページでより適切に機能するかどうかを判断できます。 または、長い形式のコピーが短い形式のコピーを打ち負かす可能性がある場合。

ただし、より高速なバックエンドをテストして、保持やエンゲージメントを改善できるかどうかを確認したい場合は、サーバー側の実験を実行する必要があります。 新しいオンボーディングシーケンスをテストする場合も、サーバー側の実験に進む必要があります。 新しいオンボーディングワークフローをサポートするだけでなく、サーバー側のテストでは、さまざまなデバイスで行われる電子メール、SMSなどにまたがるマルチチャネル実験を調整することもできます。

同様に、B2C SaaSビジネスの場合は、クライアント側の実験を実行して、特定の料金プランが他のプランよりもうまく機能するかどうかを確認できます。

ただし、より優れたレコメンデーションエンジンをテストする場合は、サーバー側のテストを行う必要があります。

サーバー側のテストのさまざまなユースケースから理解できるように、すぐにコンバージョンを獲得するのではなく、より優れた製品を構築することを目的としています。 即時の販売またはコンバージョンに焦点を当てたクライアント側の実験とは異なり、サーバー側の実験は、生涯の顧客価値が高まるように製品またはソリューションを最適化することに焦点を当てています。

クライアント側のテストがマーケター向けである場合、サーバー側のテストは主に製品チームとエンジニアリングチーム向けであると言えます。 また、ConvertExperiencesなどのA/ Bテストツールは、マーケティングチームとエンジニアリングチームの両方に対応するために、クライアント側とサーバー側の両方のテストを提供します。

このような製品レベルの大幅な変更のテストには、単純なブラウザーベースのJS操作よりもはるかに多くの時間がかかるため、ブラウザー内で行うことはできず、サーバーレベルで取り組む必要があります。

サーバー側のテストには独自の使用例がありますが、一部の企業は、外観テスト（クライアント側でも完全にグリッチなしで実行されるテスト）を実行するためにそれを使用しています。

多くの場合、「ちらつき」や「オリジナルコンテンツのフラッシュ」現象を回避するためにそうします。 ちらつきは、実験ツールが、エンドユーザーがすでに見た後にサーバーによって提供される元のコンテンツを変更したときに発生します。 ユーザーが特定の見出しを見て、それがあっという間に別の見出しに変わるのを想像してみてください。 （はい、ちらつきはユーザーエクスペリエンスを著しく損なう可能性があります！）

それ以外の場合は、速度を向上させるためにそうします。 テストによってWebサイトの速度が低下したり、深刻なパフォーマンスの問題が発生したりすることはありませんが、Webサイトで認識される読み込みエクスペリエンスに1〜2秒追加されます。 サーバー側はこれをより高速にすることができます。

プライバシーやセキュリティ上の懸念から、企業がクライアント側の実験の代わりにサーバー側の実験を実行する場合があります。 オーディエンスターゲティングはサーバーで行われ、実験コードはサーバー側のテストでサーバー上に存在するため、企業はプライバシーとセキュリティの側面をより適切に制御できます。

ただし、サーバー側の実験を実装することが常に実行可能であるとは限りません。特に、クライアント側でも同様に実行できる場合はそうです。

サーバー側の実験の実装

クライアント側のテストでは、実験を構築して実行するために必要な設計および開発リソースは限られています。 テキストを変更したり、ボタンの色を変更したりするだけの場合は、これらは必要ありません。 あなたがする必要があるのは：

1.Convertなどのツールにログインします。

2. WYSIWYGエディターを使用して、バリエーションを作成します。

3.実験を設定します（オーディエンスのターゲティング条件、実験期間、サンプルサイズと分割、信頼水準などを設定します）

JSコードを取得して、Webサイトに追加します。

そして完了。

次に、コントロールが失われた場合に、勝者のバージョンを展開するための開発支援を求めます。

ただし、サーバー側のテストはそれほど単純ではありません。

ここでは、次のことを行う必要があります。

1.ConvertExperiencesで実験を作成します

2.実験のすべてのバリエーションを開発し、サーバーにデプロイします。

3.カスタムコードを使用して（実験のID、実験ツールで設定されたバリエーションのIDなどを使用して）サーバーでデプロイされたエクスペリエンスをConvertExperiencesにマッピングします。

このようなサーバー側の実験では、コードはサーバーに現在のユーザーに表示するバリエーションを指示する必要があります。 これを容易にするためにCookieを使用できます。 たとえば、Convertを使用してA / Bサーバー側テストを実装するには、次のデータを使用してCookieを設定する必要があります。

その後、サーバーはCookieを読み取り、
それに応じてバージョン（および後続のすべてのセッション）を提供します。

サーバーがユーザーに送信するバージョンを決定するため、ターゲティングはサーバーで行われます（クライアント側のテストのようにブラウザー内では行われません）。 テストの精度は、サーバーでターゲティング条件をどれだけうまくコーディングできるかによって異なります。 クライアント側のテストでは、すべてのエクスペリエンスについて視聴者をレーザーターゲットにすることができます。

また、サーバー側のテストは、マルチサーバーのセットアップやCDNを統合する必要がある場合にさらに複雑になる可能性があります。

4.実験を実行します。

5.勝者バージョンをロールアウトし、敗者をロールバックします。

また、サーバーをクリーンアップして、最終的なロールアウト/ロールバックを投稿する必要がある場合もあります。

ご覧のとおり、サーバー側の実験のライフサイクルは、クライアント側の実験とは異なり、長く複雑です。 そのため、サーバー側のテストを行うには、ある程度の検討が必要です。

一般に、クライアント側の実験が実行される場合、サーバー側の実験は実行されません…

サーバー側の実験を1つでも実行することは困難です。これは、実験の開発と展開がより多くのリソースと時間のかかるプロセスであるためです。

さらに、サーバー側のテストを使用して、クライアント側で簡単に検証できる変更をテストする場合、適切なテスト速度と堅牢な実験プログラムを達成することは困難です。

また、このような実験では、SEOや速度に影響を与えることなくちらつきのない実行を可能にする優れたクライアント側A / Bテストツールがいくつかある場合にサーバー側の実験を選択しても、テストの最適な使用は約束されません。帯域幅。

サーバー側の実験は、与えられた仮説に対して強力な主張をする場合にのみ優先されるべきです。 また、ビジネスの収益指標に影響を与える多くの実験はサーバー側でのみ発生する可能性があるため、これはかなりの回数行われます。

では、教えてください…サーバー側のテストを実行しましたか？ もしそうなら、プロセスの最も難しい部分は何でしたか？ ああ、サーバー側のA / Bテストを実行したい場合は、Convertをチェックしてください（15日間無料です！）