サーバー側の実験の旅でゼロから 1 に移行する方法

公開: 2022-08-04

あなたの旅を Netflix ユーザーとして考えてみてください。あなたが私のような人なら、朝のコーヒーを飲みながら携帯電話で野生生物のドキュメンタリーを見るかもしれません。夕食には、ラップトップのフォレストガンプのような昔からのお気に入りが伴う場合があります。週末の夜は、できれば大画面で新しい Netflix 番組を試しながら、自分のプロフィールと子供のプロフィールを切り替えて過ごすことになります。

ここで、Netflix が国別の割引キャンペーンを実施しているとします。 Netflix が実施するこの実験キャンペーンに参加している場合、使用しているデバイスやプロファイルに関係なくログインするたびに同じキャンペーンに参加し、どこでも同じプロモーションが表示されるようにするにはどうすればよいでしょうか? 提供されているバリエーションでのエクスペリエンスが毎回シームレスであること、およびバリエーションとの関わり方が一貫して追跡されることをどのように保証しますか?

その答えは、サーバー側テストの典型的なユースケースであるオムニチャネル実験にあります。

クライアント側よりもサーバー側のテストを優先する必要がありますか?

上記の Netflix の例は、クライアント側で実行するのが非常に複雑になり、ユーザーエクスペリエンスを妨げる可能性があります。サーバー側では、実行が比較的簡単で、ユーザーに一貫したエクスペリエンスを保証します. また、ページのパフォーマンスへの影響を最小限に抑えます。これに加えて、ブラウザ自体にアクティビティがないため、プライバシー関連の問題を根絶します。

堅牢性と柔軟性のためにサーバー側のテストが推奨されるユースケースは他にもあります。これらについては、この記事で説明します。しかし、最初に、サーバー側のテストとは正確には何ですか? さらに重要なことに、それは誰のためのものでしょうか?

サーバー側のテストでは、テストのバリエーションは Web サーバー上で処理されます。訪問者がテスト対象のページに到達すると、バリエーションがサーバーから直接取得され、訪問者のブラウザーに配信されます。その後、フロントエンドまたはブラウザで変更が行われることはありません。これとは対照的に、クライアント側のテストでは、元のページが最初に訪問者のブラウザーに読み込まれ、実験プラットフォームが JavaScript を使用してフロントエンド自体でバリエーションを作成します。例を使用して、これら 2 つの形式のテストの範囲を理解しましょう。

マイクとボブが新しい車の仕組みを実験しようとしている 2 人の友人だと想像してください。マイクはハンドルを握り、ブレーキ、アクセル、ダッシュボードなどにアクセスできます。ボブは、エンジン、ラジエーター、バッテリーなどの内部コンポーネントのビューを持っています。どちらも、さまざまな方法で車に影響を与える可能性があります。ボブが車のコンポーネントにアクセスして行うことは、マイクの外側に反映される可能性があります。マイクがテストする変更は、車の視認性に基づいています。車の購入者の観点からすると、ボブとマイクの両方が行った実験の結果は、同じように重要ですが、異なる目的に役立ちます。

したがって、どちらか一方の形式のテストを選択する必要はありません。ユースケースは異なり、ツールを使用するチームも異なります。クライアント側のテストがマーケティング担当者によってより頻繁に使用されるのと同様に、サーバー側のテストは、開発者と製品マネージャーにとって実験手段です。

サーバー側のテストで対処できる問題はどれですか?

製品チームが実行するサーバー側のテストは、e コマースや SaaS から銀行やメディアに至るまで、無数の業界に関する問題を解決します。さまざまな業界でクライアント側のテストよりもサーバー側のテストが推奨されるいくつかの重要な使用例を以下に示します。

製品の推奨事項

訪問者をより多く購入するように誘導する推奨製品のセットはどれですか? サーバー側のテストでは、複数の製品推奨アルゴリズムをテストして、売上と収益の増加につながる選択を決定できます。たとえば、同様の製品を宣伝するレイアウトが、最も人気のある製品を宣伝するレイアウトよりもうまく機能するかどうかをテストできます。サーバー側の実験結果に基づいて、アップセルするかクロスセルするかを決定することもできます。

送料

注文が送料無料の対象となる理想的なカートの値は? さまざまなしきい値をテストして、顧客の購入決定にプラスの影響を与えるしきい値を決定できます。

検索アルゴリズム

検索アルゴリズムを試すには、既存のコードを変更し、詳細にテストできる柔軟性が必要です。訪問者が探しているものをすばやく見つけられるようにする必要があり、これを実現するためにサーバー側で検索アルゴリズムをテストできます。

フォームの長さ

無料の試用版とデモのリクエストフォームは、SaaS ビジネスにとって非常に重要です。しかし、必要な情報をすべて取得しながらドロップオフを少なくするための理想的なフォームの長さはどれくらいでしょうか? クライアント側のテストを介して、必須ではないフィールドをテストできます。フィールドが必須の場合、サーバー側ロジックを使用したフォーム検証が失敗するため、JavaScript を使用してフィールドを非表示にするだけでは機能しません。したがって、フォームの長さと複雑さを最適化するために、必須フィールドを試してサーバー側のテストを行うことをお勧めします。

お得な情報と割引

ホームページ上の取引のスタイル、ルックアンドフィール、および配置は、クライアント側で簡単にテストできますが、割引の価値、期間、または資格基準など、考慮すべき重要な要素が他にもあります。サーバー側でテストして最適な値を決定し、特定の訪問者のチャネル間で一貫性があることを確認できます。

販売インセンティブ

期間限定のオファーや在庫処分などの動的なインセンティブをテストするには、その粒度が関係するため、サーバー側のテストの柔軟性が必要です。

サブスクリプションフロー

サブスクリプションプロセスには、理想的にはいくつのステップを含める必要がありますか? ソーシャルログインを提供する必要がありますか? サブスクリプションフローを試してみると、これらの質問に答えることができます。

ペイウォール

サーバー側のテストでは、さまざまなペイウォール構成を簡単にテストできます。パブリッシャーは、サーバー側のテストを実行して、ゲート付きコンテンツを実験し、収益化できます。クライアント側で同じテストを実行することはお勧めしません。訪問者は Cookie を削除またはオプトアウトすることでペイウォールを回避できるからです。

モバイルバンキング

ローンやクレジットカードのサインアッププロセス内で、複数の要素を最適化できます。しかし、モバイルバンキングに関しては、データセキュリティが最も重要になります。クライアント側のテストでは、銀行や金融機関によって収集された機密データが脆弱性のリスクにさらされる可能性があります。このリスクを回避するために、通常、銀行アプリケーションではサーバー側の実験が推奨されます。

サーバー側で機能テストを実行する方法と、VWO で実行する利点を理解しましょう。

VWO がサーバー側のテストを容易にする方法

上記のサーバー側のユースケースでは、VWO を使用すると、キャンペーンを A/B テストまたは機能テストとして柔軟に構成できます。機能テストは、機能パラメーターの値を検証するために使用され、コードを記述せずに機能をすばやく構成するための制御を提供します。どちらの検索アルゴリズムが優れているかをテストするなどのユースケースでは、キャンペーンを A/B テストまたは機能テストの両方として構成することができます。

たとえば、3 つのベンダーが Web サイト用に構築した検索アルゴリズムを評価したいとします。

機能テストにより、製品マネージャーは、エンジニアリングへの依存を最小限に抑え、構成を最大限に制御して、迅速にテストして結論を出すことができます。 VWO の機能テスト機能を使用すると、面倒な作業のほとんどがプラットフォームによって行われるため、記述するコードが少なくて済む一連のフレームワークが得られます。機能テストでは、アルゴリズムを機能変数として定義し、プラットフォームのセットアップフロー自体から実験の制御とバリエーションで構成して、どの検索アルゴリズムがより効率的かをテストできます。

この実験は、サーバー側の A/B テストでも実行できます。 VWO は、サーバー側の SDK を介して、トラフィック分散と実験統計モデル機能を容易にします。エンジニアリングチームは、同じものを使用して検索アルゴリズムのコードを挿入し、どちらがより影響力があるかをテストできます。

機能テストが役立つその他のシナリオを次に示します。モバイルの再充電を扱うサードパーティベンダーが、再充電ごとにわずかな金額をユーザーに請求するとします。彼らは、同じものに対して適切な量をテストしたいと考えています。または、Airbnb のような施設の料金を所有者が負担する会社は、清掃料金を追加して、それが予約数に影響するかどうかを確認したいと考えています。これは、さまざまな企業が北極星のメトリックに影響を与えずにサービス料金を挿入できるスイートスポットを見つけるための典型的な実験ユースケースです。それは、コンビニエンスフィー、ファシリティフィー、covidフィー、パッケージングフィー、または同様のものの形である可能性があります.

上記のような複雑なユースケースは、VWO で非常に簡単にテストできます。これは、便利な料金機能をすばやく作成し、それに値 (この場合は料金の額) を割り当てる方法を示す説明ビデオです。予約数に影響を与えずに収益を増加させる料金を特定するという仮説を関連付け、テストを実行する環境を選択し、バリエーションを有効にすることができます。これを行うと、サーバーに送信されるキャンペーンコードが提供されます。あとは、追跡する目標を定義し、必要に応じてオーディエンスをセグメント化するだけです。これで、キャンペーンの準備は完了です。

あなたが製品マネージャーで、バリエーション 3 がユーザーに対して機能していないことをダッシュボードで確認した場合。収益に悪影響を及ぼしている場合は、VWO のバリエーションを無効にするだけですぐに解決できます。以下のスクリーンショットに示すように、これはコードに影響を与えず、エンジニアリングチームが変更を加える必要はありません。オフにして [保存] をクリックすると、バリエーションはトラフィックの受信を停止します。

VWO アプリのスクリーンショット — VWO での機能テストキャンペーンのスクリーンショット

基本的に、コードはキャンペーンごとに 1 回だけ実装する必要があります。

サーバー側のテストを実行するためのプラットフォームを構築または購入する必要がありますか?

作るか買うかの議論に終止符を打ちましょう。 VWO は、さまざまなオーディエンスにさまざまなバリエーションを表示し、コンバージョンイベントをキャプチャする単なる乱数ジェネレーターではありません。 VWO は、堅牢な統計モデルを備えた完全な実験プラットフォームです。サーバー側のテストメカニズムを社内で構築するか、VWO のようなプラットフォームに投資するかを検討するには、次の 3 つの主要な要素を考慮する必要があります。

所有コスト

企業が必要なインフラストラクチャを社内で構築できたとしても、それを管理および拡張する必要があります。コアな仕事に集中する代わりに、VWO のような実験エンジンを構築して維持するために開発チームにお金を払うことは、VWO に投資するよりも時間とコストがかかる可能性があります。

使いやすさ

特定の対象者に特定のバリエーションを示すソリューションを構築することはできますが、エンジニアリングチームだけでなくプロダクトマネージャーも制御できる使いやすいインターフェイスはありますか? そうでない場合は、サーバー側のテストを実行するための別のブロッカーです。

直感的なレポート

通常、社内ソリューションでは、訪問者数や特定のバリエーションからのコンバージョンなどの基本的な情報が得られます。しかし、必要なのは統計的に有意な結果です。 VWO SmartStats などのベイジアン統計エンジンを使用してレポートを作成する必要があります。ここにギャップがあります。維持するのが難しい基本的なソリューションを構築でき、p 値の解読に時間とリソースを費やすことができます。または、VWO のようなソリューションを選択することもできます。ここでは、その保守とスケーリングに専念するチームがあり、ベイジアンアルゴリズムに何年も費やして、簡単に解釈可能な結果を得ることができます。 VWO のアプリ内ダッシュボードにより、技術者以外のチームメンバーでも結果を理解できます。分析チームに実験の追跡や結果ダッシュボードの作成を依頼する必要がないため、時間を節約し、実験のコストを削減できます。

エラーのないメカニズム

サーバー側のテストソリューションを社内で構築すると、エラーが発生しやすくなる可能性があり、その規模では、エラーを簡単に発見できない可能性があります。それをグローバルブランドが使用するプラットフォームの品質と比較すると、エラーが忍び寄る可能性はごくわずかであることが保証されます. エラーが発生した場合は、有能なサポートチームができるだけ早くフラグを立てて修正します。

さらに、VWO のようなマネージドプラットフォームに投資すると、重要なベストプラクティスが製品に組み込まれます。結果からの外れ値の除去、データの視覚化、またはバージョンの更新によって発生する問題について心配する必要はありません。

複雑なサーバー側のテストを完全に実行するために必要な機能

サーバー側の実験を正しく実行すると、非常に実り多いものになります。そのためには、適切な一連の機能が必要です。これらのいくつかを以下に示します。

各テストでの訪問者のランダム化– テストでは、オーディエンスをキャンペーンにバケット化する場合、訪問者のランダム化は疑似ランダムではなく真にランダムである必要があります。
一貫したオムニチャネルエクスペリエンス– ユーザーのバケット化はランダムである必要がありますが、使用しているデバイスに関係なく、1 人のユーザーがログインするたびに同じ変化を経験するようにする必要もあります。実験は問題なく続行する必要があります。
相互に排他的なキャンペーン– ユーザーをテストに含めるかどうかを決定する際に考慮すべき 3 つの要素があるとします。これらは、使用の規則性、チャーンの可能性の低さ、タイムゾーンなどです。これらの変数を考慮することとは別に、排他性も決定する必要があります。これらの条件を満たしているユーザーは、いくつのテストに参加できるでしょうか? これは、偏ったデータにつながらず、コンバージョン率の向上を偏りなく適切なキャンペーンに帰することができる方法で決定する必要があります。
標準化された命名規則– テストする新しい機能または機能フラグを設定する場合、混乱や間違った機能またはテストの初期化のケースを避けるために、標準の命名規則に従う必要があります。
一意で手間のかからないキャンペーン識別子– 英数字キーを使用してコード内のテストを一意に識別し、後の段階で手間がかからないようにする必要があります。
適切な環境の選択– テストを実行する環境を指定する必要があります。たとえば、QA チームが実験を検証するためにステージングまたは QA 環境にテストを展開できます。テストのサニティチェックは成功に不可欠であり、適切な環境を選択するオプションが必要です。
論理的なトラフィックの割り当て– たとえば、複数のキャンペーンを実行している場合や、ブラックウィークセールなどの重要なイベントのお知らせがある場合は、ページにランディングするすべての訪問者をテストに含める必要はありません。テストキャンペーンに含めるトラフィックの割合と、このトラフィックをバリエーション間でどのように配分するかを選択する必要があります。
統計的有意性に達するまでの時間の計算– テストが統計的有意性に達するまでの推定時間は、主な目標の現在のコンバージョン率と、バリエーションを通じて達成したい最小の改善によって決定する必要があります。また、ベースラインのコンバージョン率を上回る 95% の確率も考慮する必要があります。

これらは、サーバー側テストのベストプラクティスと必須機能の一部です。実際のリストはもっと長くなります。前述のように、これらの機能を社内で構築することも、VWO を使用して作業を代行することもできます。

結論は

開発者であろうとプロダクトマネージャーであろうと、テストのアイデアを制限する必要はありません。サーバー側のテストでパフォーマンスやプライバシーの問題を心配することなく複雑なテストを実行し、顧客が直面する実際の問題を解決できます。すべてのデジタルタッチポイントを最適化して、顧客が最高のエクスペリエンスだけを体験できるようにします。

VWO のようなプラットフォームを使用している場合、テストの複雑さに圧倒されることはありません。キャンペーンでのすべての入力は直感的であり、テストを強化する優れたプラクティスであるためです。 VWO を使用してサーバー側のテストを簡単に実行する方法を理解するには、製品の専門家によるデモをリクエストしてください。