クリック洪水の検出：誤検知の課題

執筆者 Tal Florentin

不正（フラウド）は悪いことです。正当なものを不正とするのは、もっと悪いことかもしれません。

しかし、正当なものを不正と判断すること（False Positive）は悪いことなのでしょうか？

不正を不正と判断してブロックするTrue Positiveのケースとは異なり、正当を不正と判断するFalse Positiveのケースは、正当なソースにとって不利に働くことになります。不正を不正と検知できなければ、悪質なメディアパートナーから広告主を守ることができないからです。それどころか、質の高いメディアパートナーと広告主の関係が損なわれてしまう可能性があります。

不正ソリューションを提供する上での責任は、このような間違った判断を可能な限り低減して顧客の最善の利益を守ること、そしてソリューションの完全性と信頼性を維持することです。

簡単に思えますよね？

実際は、そう簡単ではないのですが…。

False Positiveテストとは

「False Positive」（フォールスポジティブ）とは、前述のとおり「正当なものを不正と判断する」という誤検知を意味するステータスのことです。

False Postiveテストとその影響を理解するには、まず、データ分析において重要なKPIである「精度」と「リコール」の概念を理解する必要があります。これらの概念は、不正検知において重要な役割を担っています。フォールスポジティブテスト図

False Positive テスト図
Fraud：不正、Legitimate activity：正当なアクティビティ、False Negative：不正だが不正と検知されない、True Negative：正当で不正と検知されない、True Positive：不正で不正と検知される、False Positive：正当だが不正と検知される、Precision：精度

不正検出アルゴリズムの精度は、False Positiveテストを行って設定されます。精度が高いほど、不正検出は厳格になります。

一方、精度が低ければ、トラフィックの総量は増加する結果になるかもしれませんが、False Positiveの発生率が高くなってしまいます。

不正ルールや機械学習アルゴリズムには、False Positiveに対するしきい値が設定されています。このしきい値は複数の変数で構成されていて、ニーズに合わせて高低を調整できます。

重要なのは、精度を高くしすぎず、できるだけ多くの不正を検出するためのバランスを見つけることです。

ご都合主義的な見解

ほとんどのマーケティング活動には制約と自省がともない、そこから信頼が成立します。しかし残念ながら、それが不正にとって付け入る隙として映ります。

モバイルアプリ市場が、不正の標的となっているのは周知の事実です。不正を働こうとする者が、一儲けするための抜け道を常に狙っています。不正にとっての抜け道とは、多くの場合、技術的な脆弱性を指しますが、モラルによって、その不正行為を防げる場合が大いにあることも忘れてはいけません。

不正を働こうとする者は、不正防止対策に変更や更新があれば、その変更内容を調査します。そして、新しい検出ロジックやしきい値を回避して不正が検知されないように手口を最適化していきます。

比較的単純な手口に、False Positiveテストの制限の範囲で、意図的に正当なインストールと不正インストールを混在させるものがあります。

ここで重要なのが、この手口をトラフィック改善手段と混同せず、この手口による影響を正しく理解することです。この手口の目的は、質の悪いトラフィックをごまかすことです。混在している正当なトラフィックやインストールは、他の不正行為がブロックされた時に、その正当性を主張するための材料として利用されることになります。

ハイパーアクティブなデバイス

クリック洪水（クリックフラッディング）とは、ネットワークが多数の不正クリックを生成し、その後クリック情報と紐づくオーガニックインストールがあれば、それを非オーガニックインストールに見せかけようとする不正行為のことです。

クリック洪水を起こすには、1つのデバイスで1日に複数回（場合によっては数千回）のクリックを送信します。次の例では、レポートされたすべてのアクションに同じIDFAが表示されているので、同じデバイスが使用されていることがわかります。event_time列を見れば、すべてのクリック（合計1,645回）が同じ日にレポートされていることがわかります。似たIPアドレスが繰り返し利用されているので、これが同じ物理デバイスであると判断できるにも関わらず、OSのバージョンとユーザーエージェントがすべてのクリックで異なっています。これは、誰かが人工的にこれらの値を偽造したことを意味します。同一デバイスのクリックレポート

同一デバイスによるクリックのレポート

このようなソースによって生成された「正当」なインストールは、本当に正当だと言うことができるのでしょうか？

一般的にクリック洪水では、実際にあるデバイスの詳細情報を含む大量のクリックが生成されます。利用される詳細情報の多くは、実際に使用されているデバイスからマルウェアなどにより違法に取得されたものや、ダークネットを通じて購入されたものです。

この偽クリックの情報に紐づくインストールがあれば、それは「正当」なインストールであるように見えますが、実際は広告主が獲得に費用を使っていないオーガニックインストール（広告を見ていないユーザーによるインストール）であることが多くあります。

こういった場合に、どのようなアプローチをとるのが良いでしょうか？同じIPアドレスから来るクリックをブロックすれば良いでしょうか？それとも、そのIDFAでのアトリビューションを今後行わないのが良いでしょうか？

どのようなアプローチをとっても、エラーがなくなることはありません。なんらかのリスクが伴うことになります。

進化するクリック洪水

他のクリック洪水の手口には、一定のクリック数あたりのコンバージョン率を示す統計モデルに基づいた保守的なものもあります。

その手口により、広告主は、アプリインストールのコンバージョンに繋がる可能性がゼロに等しい大量のクリックを浴びせられることになります。不正クリックでは、偽の情報をクリックで送信するので、広告主に届く情報は、クリックしたと見せかけるために自分の情報が悪用されていることを知らないユーザーのものになります。クリック洪水

クリック洪水

もう1つのクリック洪水の手口に、すべての広告インプレッションでクリックURLを実行するというものがあります。広告がユーザーに表示されただけで、実際のクリックはなくても、クリックがあったと偽装します。同じユーザーに同じ広告が何度も表示されるので、偽のクリックを多く稼ぐことができ、コンバージョンの確率も上がります。そのユーザーがアプリを実際にダウンロードすれば、それがオーガニックインストールであったとしても、そのインストールに対するアトリビューションを不正に獲得できます。

このような偽クリックの生成にはコストも手間もかかりません。コンバージョン率は低いですが利益性が高いので、クリック洪水はメジャーな不正の手口として横行しています。

監視の目を掻い潜る不正

より高度なクリック洪水に、複数の小規模サイトに対し分割したクリック洪水をしかけるという手口があります。この手口では、それぞれのサイトでのクリック数が少なくなります。

個別に事象を見れば、そのサイトが不正行為とは無関係であるように見えます。

しかし、視野を広げて見ると、先述のクリック洪水と何も変わりません。

それぞれの小規模サイトでのクリック数は、不正でBI（データ）を活用している良い例だと言えます。不正対策のしきい値をテストし、怪しまれない数でトラフィックを分散させて、監視の目を掻い潜ります。マイクロサイト - クリック洪水

マイクロサイトでのクリック洪水

こういったクリック洪水が発生している小規模サイトのコンバージョン率は非常に低い値になります。しかし、不正のないコンバージョンを推進するサイトであれば、潜在的なコンバージョン率が高くなるので、最適化のためのライフラインとして利用され、アクティビティの継続にとって「良い」チャネルとして扱われるようになります。

メディアパートナーが1つのサイトID名を何千の無意味な名前に分割すると、AppsFlyerへの印象が悪くなるだけでなく、広告主にとっても悪影響を与えます。キャンペーンの正確な計測が難しくなり、最適化も難しくなります。そして、パフォーマンスが悪いと評価されたソースは利用されなくなります。こういったサイトでインストールが生成されるのは、サイトのライフタイム全体を通してもわずか数回であり、不正手口を調査するのは至難の技と言えます。

このような小規模サイトでの不正をリアルタイムでブロックすることは不可能に近いですが、ここで役に立つのがAppsFlyerのポストアトリビューションです。アクティビティを過去に遡ってトレースし、リアルタイム検知ができない不正傾向にそのアクティビティを高い精度で割り当てます。

意図的にパラメーターを操作しているという評判があるネットワークの場合は、トラフィックの粒度を荒くして調査を行います。サイト名のプレフィックス（接頭辞）を使って小規模サイトのデータを集約します。他の類似のパラメーターについても同様に集約します。こうすることで、小規模サイトをまとめて判断することが可能になり、リアルタイムでの不正のブロックが可能になります。

不正を行っていないサイトであるにも関わらず、不正小規模サイトのクラスターに入れられてしまったことで、この方法による影響を被るサイトが出てくる可能性があります。AppsFlyerは、そのようなエッジケースの低減に日々取り組んでいます。また同時に、上記のような対応が現状必要であるということをご理解いただきたいと考えています。

不正を容認しない

ここまで読んでいただいて、False Postitive テストは不要と思われていないでしょうか？

もちろん、必要です。

先述のように、False Positiveテストは、エコシステムの完全性と、信頼できる不正防止メカニズムの維持に不可欠です。だからといって、有害なソースの活動を許す口実として、質の悪いトラフィックのごまかしや不審な使用を、AppsFlyerが受け入れることはありません。これは、AppsFlyerが、精度基準を下げ寛容な姿勢で、より多くの不正インストールをブロックしたいという考えの現れです。

クリック洪水はすぐにブロックできるものではありません。他のタイプの不正に比べても、対策に時間を要します。そして、すべてのパブリッシャーをそれぞれ慎重に調査する必要があります。大きな規模で実現するために、AppsFlyerではクラスターブロッキングのメカニズムの改良を常に行い、インストールレベルで十分な情報が収集されない場合に不正を検知できるようにしています。

エコシステムとお客様にとって有害なメディアソースによる不正行為をAppsFlyerが容認することはありません。

AppsFlyerの目標は、さまざまなソースからの不正を早期に速やかに効率的に検知することです。