Badooでの分割テストの仕組み

Googleでクエリ「ab testing」を入力すると、トピックに関する多くの記事が除外されますが、より多くの理論があり、マネージャーに焦点を当てており、 Google Analyticsなどの既製のクライアント実装がツールとして提供されています。 非常に単純なサーバー実装に関する記事もあります（著者の現実では、これで十分だと思います）。



今日は、世界中の膨大な数のユーザーを抱えるBadooでこれがどのように発生するかについてお話します。



A / Bフレームワークが主導する分割テスト用のツールの全体的な「動物園」があり、その一部は他の目的のために開発されました。 その他の欠点の中でも、これらのツールはすべて、ユーザーをオプションに分割するためにほぼ同じ方法を使用しました。これは、ユーザーIDと「塩」のハッシュです。 このアプローチは私たちを満足させるものではなく、古いバージョンの欠点を回避できる新しいバージョンを開発することが決定されました。



分割テストツールの新しいバージョンの主な要件は次のとおりです。

• 大規模なプロジェクトと大規模なチームがあるため、同時に多くのテストを実施する必要があります。
• 同時に実行されるテストは、ユーザーとの交差が最小限である必要があり、他のテストとの交差がある場合は、これに関する情報がマネージャーに表示される必要があります。
• テストを作成するとき、テストの各バージョンに何人の人が入るかを理解したいと思います。
• 分析中に、テストのKPIインジケーターが突然ジャンプした理由が疑問にならないように、テスト条件の変更をレポートに表示する必要があります。
• 開発者向けのソフトウェアAPIはシンプルで、エラーの可能性を減らす必要があります。
• 開発者を巻き込まずにテスト条件を変更する機能が必要です。
• QAには、ユーザーがテスト条件に該当するかどうかに関係なく、ユーザーにオプションを指定できる便利なツールが必要です。
• ユーザーがテストに参加しているかどうかを確認するのは、ページの復帰時間に影響を与えないように十分に高速でなければなりません。
• これは時間の経過とともにテストの交差点の評価を非常に複雑にし、コードにエントロピーを導入するため、テストは無限であってはなりません。

これらの要件に基づいて、BIチームの推奨事項を考慮に入れて、新しいツールには以下が登場しました。

• フィルターの形式でテストに入るための条件を指定する機能。
• 必須フィールドにテストの開始日と終了日を示す機能。
• テストのオプションとオプションの割合を指定する機能。
• 保存するときに、テストバリアントにアクセスするユーザーの評価、および他のテストとの交差（パーセンテージで）が計算されます。
• テストが変更されるたびに、いわば、テスト設定のグループが作成されます。これには、フィルター、テストの開始日と終了日、オプションが含まれます。これにより、BIレポートでテストレポートを表示し、グラフでジャンプする理由を理解できます。
• その場でユーザー数を推定します。 すべてのユーザーは分割グループに分割され、オプションによるユーザーの分布はオプションによる分割グループの分布に縮小されました。

A / Bフレームワークの新しいバージョンは、 UserSplit Toolまたは単にUserSplitと呼ばれていました 。 開発は徐々に進みました。 最初は、ツールをすぐに使用できるように、可能な限り最小の機能が作成されました。 そして、新しい機能が追加され、バグが修正されました。



ここで、現在の時点でUserSplitをより詳細に調べ、なぜこれを行う必要があるのか​​を理解することを提案します。

テストの主な特性

このページは次のとおりです。







ここでは、主に情報フィールドです。ただし、 キー 、 Jira issue 、 テストマネージャー 、およびHipchatルームの作成ボタンは除きます。



Keyフィールドは、テストを一意に識別する意味のある文字列です。 開発者のソフトウェアAPIは、テストIDではなくキーを使用します。 より読みやすく、テストIDに結び付けられないようにすることもできます。

試験条件とオプション

このページでは、テストの日付範囲（アクティブな場合）、テストに参加するための条件（国がロシアなど）、およびオプションを指定できます。 各オプションについて、それに含まれるユーザーの名前と割合が示されます。 この名前は、ユーザーが取得したテストのバージョンを理解するために、開発者が（バリアントIDではなく）使用します。 これはテスト固有のものです。 コントロールのオプション自体は存在しない場合がありますが、コントロールの1つのみがコントロールになります。







このページにあるすべて-日付の範囲、テスト条件、オプション-は、前述のテスト設定のグループを表します。 このような設定グループは複数存在できますが、一度にテストに直接接続できるグループは1つだけです。これが現在の設定グループです。 テスト設定のグループが変更されるたびに、実際には変更されませんが、新しい設定が作成されます。 ただし、すぐにテストにアタッチされるのではなく、準備が整った後にのみアタッチされます。 設定のグループを準備するには、オプションにランダムな分割グループを割り当て、テストスコアと他のテストとの交点を計算する必要があります。

オプション

良い方法では、どのテストにも少なくとも2つの比較オプションが必要です。 さらに、ほとんどのテストでは、何が起こったのかを比較するときに、コントロールバージョンが使用されます。 ただし、新しい「機能」が起動され、2つの設計オプションがある場合、制御オプションはありません。 それがまったくない前に、それで比較するものは何もありません。 現在、制御オプションは削除できませんが、不要な場合は0％を設定できます。 将来、インターフェースは少し変更される予定ですが、現在のところ変更されています。



コントロールケースでは、テストが非アクティブの場合と変わらないように、追加のロジック（ヒットのログ記録を除く）がないことが重要です。 そうでない場合、これは制御オプションではなく、テスト済みのオプションの1つであることがわかります。

ユーザーグループの分割

要件に基づいて、ユーザーIDとソルトのハッシュの使用は、ユーザーの分割には適していません。 オプションのユーザーのヒットをすばやく評価することはできません（オンザフライでは、データベースはソルトを使用してハッシュをかなりゆっくり計算します。テストごとに、異なるソルトを持つすべてのユーザーのハッシュを再計算するのは明らかにかなり高価な操作です）。 また、ハッシュを使用すると、テスト間で可能な限り多くのユーザーの「非交差」を実現できません。



代わりに、分割グループ（split_group）を使用することにしました。 これは、1〜2400の範囲の新しいユーザー（登録中）と既存の分割グループをランダムに提供するという考え方です。



2400は、5％刻みで簡単に分割できるという点で便利です。 5％ごとに120のグループが該当します。 そして、これらの120のグループは、残りなしで2、3、4、5、6、8、10、12のオプションに分割されます。 7、9、11のオプション-非常にまれなケースであり、私たちは会いませんでしたが、これが発生した場合は、2番目の制御オプションを追加し、統計で考慮しないことができます。



ゲスト（許可されていない）ユーザーの場合、Web上の分割グループはCookieに入れられ、ログイン後にユーザー分割グループと一致しない場合があります。 これは、最後にログインしたユーザーがどの分割グループを持っているかに関係なく、同じブラウザーでゲストユーザーが同じバージョンのサイト（承認フォームや登録フォームなど）を見るために特に行われます。 しかし、現在、ゲストユーザーに関する情報はBIにアップロードされていないため、このようなテストを実行するときの統計は完全ではありません。 現在、このパートの最終段階にあります。



テストのオプションを追加する場合、オプションは（割合に応じて）分割グループにランダムに割り当てられます。 つまり オプションがユーザーの10％用に予約されている場合、240のランダムな分割グループがそれに対応します。 開発プロセス中に、ユーザーを等しいグループに分割する機能を認識していませんでしたが、各オプションのパーセントを示しましたが、1つのオプションがパーセントを変更すると、他のすべてのユーザーに対しても変化します。 おそらく後でテスト全体のパーセンテージの数を示すことができるようにし、このパーセンテージに対応する分割グループがオプション間で均等に分割されるようにします。

テストスコア

評価には、Exasolデータベース（同僚のwildraidが最近書いた記事 ）を使用しているため、テストと設定グループ（テストバリアントとそのスプリットグループを含む）に関する情報がアップロードされます。



実際、分割グループはまったくランダムに発行されるわけではありません。 現在の日付と交差する（ただし、分割グループの100％を占有しない）すべてのテストがデータベースから抽出されます。 次に、これらのテストでは、フィルター条件（分割グループを除く）に基づいて、Exasolデータベースを介してチェックが行われ、テストと現在のテストの間に実際の交差があるかどうかが確認されます。 実際に重複するテストのうち、忙しい分割グループが使用されます。 したがって、現在のテストに分割グループを割り当てる場合、最初の選択肢は無料の分割グループであり、十分な空きグループがない場合にのみ使用中の分割グループになります。 さらに、選択したグループがオプションにランダムに割り当てられます。 これにより、オプション間で対象者の均一性を維持しながら、テスト間で可能な限り最小の交差を実現できます。

	1	2	3	4	5	6	7	8	9	10
Test1	A					B		B		A
Test2		A	B		A	A			B	B
	-	-	-	+	-	-	+	-	-	-
テスト				A	B		B		A

最初の行は、分割グループの可能な数を示しています（わかりやすくするために、10個のみを取りました）。 2行目、3行目、5行目には、テストケースと対応する分割グループが表示されます。 表の4行目では、無料の分割グループはプラス記号でマークされ、ビジーな分割グループはマイナス記号でマークされています。 Test Test1およびTest2と交差するTestというテストがあるとします。 テストテストに4つの分割グループが必要だとしましょう。 まず、フリースプリットグループ4と7を選択し、次に5と9などの占有グループからランダムに選択します。その後、オプションに従って混合して分配します。 実際、結果は表の最後の行にあります-他のテストで最大の「非交差」を達成しました。



バリアントに分割グループが発行された後、他のテストとの交差点（ユーザーの何パーセントがどのテストと交差するか）がカウントされます。



次に、テスト自体を評価します。どのオプションに何人のユーザーが含まれているか、ユーザーにとって正確です。 これらの数値を使用すると、 統計的に有意な結果を得るためにこれらの条件でテストを実施する価値があるかどうか、および交差テストが結果を歪める可能性があるかどうかを理解できます。



テストスコアと他のテストとの交点を計算した結果は次のとおりです。







*すべての数字は架空のものであり、現実とのつながりはランダムです。



同じタイプの赤いテストが目立ちます。 たとえば、モバイルテストがWeb上のテストに影響を与える可能性は低いため、これは説明のために行われます。



交差点のカウントの最初の実装はそれほど高速ではなく、最初に計算が数秒で実行された場合、同時に実行されるテストの数が増加すると、30分に達し始めたことに注意する価値があります。 いくつかの最適化が行われ、現在、交差点のカウントには1分半しかかからず、完全な交差点のカウントと評価は最大2分です。

試験条件

UserSplitインターフェイスを使用すると、ある程度の柔軟性を備えたテスト条件を指定できます。 ANDおよびOR演算子を使用できます。条件を括弧で囲むことができます。 すべてのテストユーザーとロシアの新しいユーザーがテストを利用できるようにしたいとします。 次に、次のようなフィルターを作成できます。









インターフェースで使用可能なすべてのフィルターは、簡単に条件を確認できます。 これらのフィルターのすべてのデータは、原則として、すでにメモリ内にあります。 そうでない場合は、簡単にダウンロードできます。



ユーザーがどのように、どこから来たかを示す環境フィルターもあります。 たとえば、これはユーザーエージェント、ユーザーが現在いる国（ユーザーがプロファイルに持っている国と混同しないでください）、およびユーザーのプラットフォーム（Web、iOS、Androidなど）です。 ゲストユーザーの場合、環境フィルターのみが使用可能です。

試験条件を変更する

同時に多くのテストを実施したいのですが、すべての国でテストを一度に実行すると、テストは重複し、場合によっては相互に影響を及ぼします。 これを回避するには、さまざまな国でテストを実行できます。 この場合、別の問題が発生する可能性があります。テストは、ある国ではうまくいき、他の国ではひどく見えることがあります。 これを回避するには、国を追加してテスト条件を変更します。 したがって、より信頼性の高い結果を取得し、正しい判断を下すことができます。 前に述べたように、テストレポートを調べるときにテストに対するこのような変更が誤解を招かないように、レポートにはテストのいくつかのバージョンのデータが表示されます。

QAツール

問題の原因を開発、テスト、および発見するために、QAツールが作成されました。

テスト変更ログ

フローテスト

フローテストは次のとおりです。







テストが作成された直後は、ドラフトステータスになっています。 この状態では、製品マネージャーは彼と「遊ぶ」ことができます（彼のスコアと他のテストとの交点を参照）が、誰も（彼とスーパーユーザーを除く）テスト自体を見ることはできません。



テストの準備ができたら、プロダクトマネージャーは開発者にテストを公開する必要があります（公開アクション）。 これで、テストは開発中ステータスになります。 このステータスでは、テストの日付範囲は無視され、テストユーザーのみが使用できます。 本番環境からのヒットを追跡し、到着し始めるとすぐに、テストマネージャーはテストの準備ができて開始できるという通知を受け取ります。



実際のユーザーに対してテストを実行するには、実行中ステータスに移行する必要があります。 一時的なシャットダウンの場合-一時停止（一時停止状態）。

テスト完了

テストの最後（完了）に、結果のバージョンを取得し、それをすべての場所（世界中）に適用するか、テストの条件に応じてのみ適用するかを決定できます。

古いバージョンを残す場合は、拒否することもできます。 同時に、拒否は制御オプションを選択することと同じではありません。 それはそうではないかもしれず、選択肢の一つも満たされていない。







将来的には、終了後にコードからテストを「切り取る」ようにタスクを自動的に設定する予定です。

テストレイアウト

データベースまたは他のリポジトリからテストに関する情報を取得して、ユーザーに対してどのテストのどのオプションがアクティブであるかを確認するだけでもかなりの費用がかかります。 したがって、テスト構成を各サーバーにローカルに保存することにしました。 配列を持つPHPファイルが設定形式として選択されました（テストごとに個別のファイル）。 この選択により、バイトコードキャッシュを使用して、構成の処理に最小限の時間を費やすことができます。 テストはすべてのサーバー（開発、テスト、および実稼働）で同時に行われるため、開発環境と「戦闘」マシンで何かが異なる動作をすることはありません。 レイアウトには、残りの構成と同じツールを使用します。



なぜなら 多くのサーバーがあり、レイアウトは瞬間的ではありません（数分程度）が、解決される問題にとってこれは重要ではありません。 さらに、レイアウトは、最初からかなり迅速に開発環境に渡されます。 つまり 何かを修正する必要がある場合、その変更はすぐに確認できます。



分解する必要のあるテストは簡単に気付くことができます。一般的なリストでは赤で強調表示されています。

統計

分割テストのフレームワークでは、統計を収集することが重要です。 主要なKPIインジケータは、ユーザーへのバインドとともにBIにすでに送信されているため、ほとんどの分割テストでは、追加の統計を送信する必要はありません。 ユーザーがテストの1つまたは別のバージョンに陥ったことに注意するだけで十分です。 このアクションはヒットを送信しています。 ここでの主なことは、ユーザーがテストで測定する必要のあるアクションを実行したという事実と混同しないことです。 たとえば、緑のボタンがあり、色が赤に変わった場合にボタンがより頻繁にクリックされるかどうかを確認します。 緑（コントロールオプション）または赤（テストオプション）ボタンが表示された時点でヒットを送信する必要があることがわかりました。 ボタンのクリックはすでにBIに送信されていると想定されており、そうでない場合はそのような送信を追加する必要があります。そうしないと、実験の結果を評価できません。

ソフトウェアインターフェース

開発者向けに、古いA / Bフレームワークは次のメソッドを提供しました。

 // ,       \ABFramework\Utils::matchPercentage( $user_id, // ID ,   ( )   $from_percent, $to_percent, $salt //  ,   ,                  ); //  , ..   ,       \ABFrameworkAPI::addHit($user_id, $test_id, $experiment_id, $variation_id);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

A / Bテストのロジック全体の実装が開発者の負担になったことがわかりました。 また、ロジックには、ヒットの条件（どの国など）と、このオプションまたはそのオプションに該当するユーザーの割合が含まれています。 同時に、開発者は簡単に間違いを犯す可能性があります（不注意または視聴者の均一性を理解していないため）。



たとえば、ロシアのすべてのユーザーを選択し、半分に分割する必要があります。

開発者が次のコードを書いたとしましょう：

 if ($country_id == \Country::RUSSIA && \ABFramework\Utils::matchPercentage($user_id, 0, 50, 'salt')) { $variation_id = static::VARIATION_ID_TEST; } else { $variation_id = static::VARIATION_ID_CONTROL; } \ABFrameworkAPI::addHit($user_id, static::TEST_ID, static::EXPERIMENT_ID, $variation_id);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり コントロールバリアントには、別のセグメント（他の国）のユーザーを含むより多くのユーザーが含まれ、結果が混在する可能性があります（他の国のユーザーの動作は異なる場合があります）。



プログラミングインターフェイスの新しいバージョンでは、一貫性のために定数を持つクラスに特別な名前空間\ UserSplit \ Testsが割り当てられました。 テストに追加のロジックがない場合は、\ UserSplit \ Tests \ Commonクラスを使用できます。



バリアント内のヒットの確認は次のとおりです。

 $Environment = \UserSplit\CheckerEnvironment::byGlobals(); //   environment-, .  $Checker = \UserSplit\SplitTests\Checker::getInstance(); // DI       ,  , ..         $variant = $Checker->getActiveVariant(\UserSplit\Tests\Common::MY_SPLIT_TEST_KEY, $User, $Environment); if ($variant === \UserSplit\Tests\Common::MY_SPLIT_TEST_VARIANT_TEST) { //   } else { //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

\ UserSplit \ SplitTests \ Checker :: getActiveVariant（）メソッドが呼び出されると、ヒットは自動的に記録されます。 追加のロジックがない場合、古いバージョンのように不均等にヒットをデポジットすることはできません。



ヒットの自動ロギングを無効にするには、4番目のパラメーターfalseを渡す必要があり、後でヒットを予約することを忘れないでください。

 $variant = $Checker->getActiveVariant(\UserSplit\Tests\Common::MY_SPLIT_TEST_KEY, $User, $Environment, false); // -  $Checker->logHit(\UserSplit\Tests\Common::MY_SPLIT_TEST_KEY, $variant, $User);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、たとえば、手紙を送信するときに必要になる場合があります。 この場合、ユーザーのテストは、ユーザーが手紙を読んだときにのみ行われます（原則として、これを確認する方法があります）。



ユーザーがテストケースに該当するかどうかを判断するための追加のロジックがある場合は、独自のクラスを作成する必要があります。 次のようになります。

 namespace UserSplit\Tests; class MySplitTest { const KEY = 'my_split_test'; const VARIANT_CONTROL = 'control'; const VARIANT_TEST = 'test'; public static function getInstance() { //  } public function getActiveVariant(\User $User, $is_log_hit = false) { $Environment = \UserSplit\CheckerEnvironment::byGlobals(); $Checker = \UserSplit\SplitTests\Checker::getInstance(); $variant = $Checker->getActiveVariant(static::KEY, $User, $Environment, false); //  :           ,     if (!$variant) { return $variant; } if (!$this->checkSomeAdditinalCondition($User)) { return false; } if ($is_log_hit) { //  :           ,   $Checker->logHit(static::KEY, $variant, $User); } return $variant; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、コメントに記載されている重要なポイントに注意を払う必要があります。 ここで間違いを犯しやすいので、例外的な場合にのみこのアプローチを使用する必要があります。 それらの2つがあります。

• ある種の困難な条件（たとえば、データベースへの追加要求）があるため、可能なテスト条件に追加したくありませんが、最後に確認することをお勧めします。
• 他のテストで必要になる可能性が低いいくつかのユニークな条件があります。

顧客テスト

追加のサーバーロジックを必要としないテストは、クライアント（モバイルアプリケーションまたはブラウザーのJS）で完全に実行できます。 たとえば、特にサーバーではなくJSでテンプレートが描画されるため、ボタンの色はクライアントで完全にテストできます。 このため、モバイルAPIの実装とJSとのやり取りが完了しました（実際、同じAPIがそこで使用されています）。 クライアントは、サポートされているテストのリスト（数字の形式-文字列形式のテストID）を送信し、サーバーはアクティブなオプション（同じ形式）を含むテストのリストを応答として送信しました。 なぜなら 新しいテストでは、テストキーとオプション名を使用し始め、数字と文字列を区別するのは簡単でしたが、新しいテストでは、それらを使用して操作を開始しました。



混合タイプのテストもあります（私はそれらをクライアントサーバーと呼びます）。サーバーとクライアントの両方で、どのオプションがアクティブであるかを知る必要があります。 この場合、テストに入るだけでなく、クライアントがこのテストをサポートしているかどうかも確認する必要があります。



クライアントテストとクライアントサーバーテストに追加条件の検証を追加することはできないという事実に問題がありました。 このようなインターフェイスを作成すると、このチェックを自動化できます。

 namespace UserSplit; interface AdditionalConditions { /** * @param \User $User * @param \UserSplit\CheckerEnvironment $Environment * @return boolean */ public static function checkAdditionalConditions(\User $User, \UserSplit\CheckerEnvironment $Environment); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

条件を確認した後、追加のチェックを行います：テストにPHPクラス（\ UserSplit \ Tests名前空間にあり、テストキーと同じ名前ですがCamelCaseにあるクラス）があり、このインターフェイスを実装している場合、それを呼び出しますメソッドcheckAdditionalConditions（）。 結果が偽の場合、ユーザーはテストに参加していません。 私たちはまだこのアイデアを実現することができていませんが、そうするつもりです。

ユーザーグループ

請求チームは、「ユーザーグループ」ツールを開発しました。 最初は、ユーザーの機能の可用性を制御するために作成されました。



次のように使用されました。たとえば、クリスマスには季節の贈り物がありますが、イスラム教徒の国でそれらを表示する意味はありません。 彼らはそこで祝いません この場合、クリスマスを祝う国のリストを登録するユーザーグループを作成し、クリスマスプレゼントを表示する前にユーザーが参加することを確認できます。 したがって、このユーザーグループは、開発者を介さずにWebインターフェースを介して変更（たとえば、国の追加）できます。 この場合、分割テストを使用するのは間違っているでしょう。なぜなら、 オプションを比較する必要はありません。特定のユーザーサークルに対してのみ機能を有効にする必要があります。



しかし、直接使用に加えて、このツールは分割テストに使用されました。 たとえば、エンティティとしてのテストは存在せず、バリアントを表す複数のユーザーグループの形式で作成されました。



一般に、分割テストとユーザーグループのツールは非常に似ており、2つの類似したツールを保持することはあまり良くありません。 そのため、UserSplitに基づいてユーザーグループを作成し、UserSplitの請求チームにユーザーグループを転送することにしました。



インターフェイス（ソフトウェアとWebの両方）は、分割テストインターフェイスとほとんど同じように見えますが、オプションがないため単純化されています。 これは、プログラムインターフェイスの外観です。

 $Environment = \UserSplit\CheckerEnvironment::byGlobals(); //   environment-, .  $Checker = \UserSplit\UserGroups\Checker::getInstance(); // DI    ,   ,  , ..         $is_in_group = $Checker->isInGroup(\UserSplit\Groups\Common::MY_USER_GROUP_KEY, $User, $Environment); if ($is_in_group) { // ,     }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UserSplitイテレーター

何らかのアクションを実行するために、特定の条件を満たすすべてのユーザーを調べることが必要になる場合があります。 UserSplit Iteratorは、分割テストおよびユーザーグループ用に作成されました。 テストまたはユーザーグループのすべての条件を含むデータベースで正しいSQLクエリを生成し、テストまたはユーザーグループに分類されるユーザーのみを取得できます。

計画

すでに表明されている問題と計画に加えて、さらにいくつかのアイデアがあります。

• トークンテスト;
• 予備スケジュール。

トークンテスト

有料機能の1つが名前変更された語彙素（テキスト）のテストの1つでは、利益が大幅に増加しました。 しかし、そのような変更には多くの開発者リソースが必要です。 なぜなら トークンの独自の翻訳システムがあるため、それにスプリットテストを組み込むことにしました。そのため、開発者を引き付ける必要はありませんでした。 現在、この機能はバックオフィスチームによって開発されています。

予備グラフ

テストページでは、テストにトラフィックがあるかどうか、およびオプション間のトラフィックの均一性を確認できるように、どのオプションに何人のユーザーが該当するかのグラフを表示する予定です。

結果

その結果、非常に強力なツールを開発できます。 6か月間、正常に使用されています。 現在、約40のテストが実施され、約30のテストが開始されています。 リクエストごとの平均的なテストでのユーザーのヒットの確認は、約0.5ミリ秒です。

このトピックについて質問がある場合は、コメントでお気軽にお問い合わせください。



そして、UserSplitの開発に参加したすべての人に感謝します！



PHP開発者のRinat Akhmadeev氏。