> For the complete documentation index, see [llms.txt](https://help.impact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.impact.com/brand/ja/what-would-you-like-to-learn-about/platform-features/protect-and-monitor-your-performance-program/event-risk/understanding-and-interpreting-event-risk-data.md). # イベントリスクデータの理解と解釈 この [パートナー別リスク](/brand/ja/what-would-you-like-to-learn-about/platform-features/protect-and-monitor-your-performance-program/event-risk/risk-by-partner-report.md) このレポートは、無効なトラフィック（IVT）の指標、特に実在するエンドユーザー（例：ボット）や真の意図を伴わないコンバージョンイベントを分析します。リスクの初期兆候を早期に可視化することで、コンバージョンアクションが確定する前に迅速に対応できます。 ベストプラクティスとして、変化するリスク率を把握できるよう、このレポートを定期的（毎日または毎週）に確認してください。これらの割合を初期指標として、調査の優先順位付けに活用します。クリックレベルで高リスクが検出された場合は、クリックフィルタリング設定を見直して、低品質トラフィックが下流のパフォーマンスに影響しないよう予防的に対応できます。 ### リスクしきい値のガイダンス 下の表では、リスク率の解釈と、どこに注目するのが最も有益かについて初期推奨を示しています。ただし、独自のビジネス目標とリスク許容度に基づいて、社内独自のガイドラインを策定することをおすすめします。これらのリスク区分を、トラフィック品質を検証する際の評価の土台として活用し、その知見を自社の意思決定プロセスに取り入れてください。
リスク %推奨される注目点定義
0-5%監視リスクレベルは低いままで、誤検知や軽微な異常に起因することが多いです。上昇したリスクの背景を把握するために、理由コードを確認してください。コンバージョンスプーフィングなどの重大度の高いフラグは、非常に少ない件数でも懸念材料であり、直ちに調査すべきです。
5-10%より詳しく確認するこのレベルのリスクは、より詳しい確認が必要かもしれません。まず［Partner別リスク］レポートで理由コードを確認し、Reason Codeガイドを参照して、どの理由コードが発生しているのか、またリスクが特定のサブソースに集中しているかを理解してください。トラフィックをどのように生成しているのか把握するために、パートナーへ連絡することも検討してください。
10-20%調査する無視できないレベルのリスクです。トラフィックソースやプロモーション方法について、パートナーと話し合う価値があります。内部データを確認して、フラグ付きイベントの大半が少数のソースに起因しているかを判断してください。たとえば、リードがコンバージョンしている、販売商品の返品が発生している、または注文額が不審である、といった場合です。
20-30%真剣に受け止めるこのレベルのリスクは、パートナーのトラフィックのかなりの部分に問題がある可能性を示しています。プログラムの方針に応じて、契約条件の見直しや、フラグ付きイベントへの支払い取消しなどを検討するとよいかもしれません。
30%+関係性を評価するこのレベルで一貫して高いリスクが続く場合、品質面で重大な懸念があることを示しています。そのパートナーシップがプログラムに必要な価値を提供しているか、またさらなる投資が妥当かを検討してください。
{% hint style="warning" %} **10% 以上のレベルでは**：理由コードを確認し、プロモーション手法を把握し、内部シグナル、取消率、その他の不審な活動と照合してください。 これらのしきい値はあくまで目安です。適切な対応は、個々のプログラム目標、リスク許容度、そしてパートナーとの関係性の文脈によって異なります。 {% endhint %} #### ボリュームが重要 非常に少ないボリュームのパートナーによる高リスク率は、統計的に意味を持たない場合があります。明確な結論を導くには、外れ値に惑わされないよう、イベント件数が統計的に十分な規模であることを確認してください。 たとえば、15件のイベントでリスクスコアが33%（5件のフラグ）のパートナーは、単なる軽微な異常かもしれません。逆に、5,000件のイベントでリスクスコアが95%のパートナーは、直ちに介入が必要な深刻かつ構造的な問題を示しています。 {% hint style="info" %} **ヒント**：以下を使用してください `アクション >=` レポート内のフィルターを使用して、イベント件数がプログラムの有意性しきい値を下回るパートナーを除外してください。基本的な推奨として、リスクレベルを評価する前に、少なくとも10アクションあるパートナーで絞り込むことを検討してください。 {% endhint %} #### 理由コードを確認する 対応する前に、以下を確認してください [理由コード](/brand/ja/what-would-you-like-to-learn-about/platform-features/protect-and-monitor-your-performance-program/event-risk/reason-codes-reference.md) フラグ付きイベントに関連する理由コードです。イベントにフラグが付けられた理由の文脈を示します。理由コードを理解することで、そのフラグが本当の懸念を示しているのか、正当な理由があるのかを判断しやすくなります。 **例**: * **重大度の高いパターン**：パートナーに、コンバージョンスプーフィングのような重大コードに起因するフラグ付きイベントがかなりの件数（例：100アクション超）ある場合、全体の割合に関係なく直ちに調査する必要があります。 * **多層的なリスク**：1つのイベントに複数の理由コード（例：「Proxy」と「Abnormal Activity」の両方）が付いている場合、誤検知の可能性は大幅に低くなります。こうした複数フラグ付きのセグメントは、優先的に確認してください。 * **ボリュームと妥当性**：フラグ付きトラフィックの量が増えるほど、将来的にパフォーマンスの問題や「ゴミ」コンバージョンが発生する可能性も高まることを忘れないでください。これらのコードを使って、パートナーのトラフィックがコンバージョンデータに対する長期的なリスクに見合うものかを判断してください。 ### パートナーの調査 リスクレベルを詳しく確認すべき場合は、次の点を検討してください。 * **このパートナーとは、どのくらいの期間取引していますか？** 実績のある既存パートナーには、いきなり大きな対応を取る前に、まず話し合う価値があります。 * **最近やり取りしましたか？** 相手がテストしている新しいトラフィックソースなど、見落としている背景があるかもしれません。 * **フラグが付いた理由コードには、正当な理由がありますか？** 一部のビジネスモデルでは、特定のフラグが自然に高い割合で発生します（例：特定の業界でのVPN利用）。 * **社内の不正対策チームやコンプライアンスチームは、何を把握していますか？** Event Riskデータを自社の内部シグナルと照合してください。 さらに不正に関する懸念が生じた場合は、 [サポートにお問い合わせください](https://impact.com/contact/support/) 可能な限り詳細（パートナーID、期間、データセット、リスク懸念の理由）を含めてください。 #### プログラムを長期的に健全に保つためのヒント * **サブソースの透明性を促進する**：より正確にリスクへ対処するために、パートナーがサブソース識別子（多くの場合、Shared IDのようなパラメータ経由）を送信していることを確認するよう協力してください。これは、さまざまなレポート指標に利用できる公開フィールドですが、詳細なデータがあれば、パートナーのトラフィック全体にペナルティを科すことなく、問題のある特定のソースを切り分けることができます。 * **定期的に確認する**：少なくとも週1回はこのレポートを確認し、パートナー別リスクの洞察を社内の不正チェックに取り入れてください。リスク管理を受け身の作業として捉えるのではなく、 [レポートをスケジュール設定する](/brand/ja/what-would-you-like-to-learn-about/platform-features/multi-program-reports/report-management/schedule-reports.md) 通知を自動的に受信トレイへ配信するように設定してください。 * **契約上の保護策を活用する**：フラグ付きイベントの取り扱い方法を定める文言を契約に含めることを検討してください。法務チームと相談して [条項を作成する](/brand/ja/what-would-you-like-to-learn-about/platform-features/protect-and-monitor-your-performance-program/event-risk/understanding-and-interpreting-event-risk-data.md) 自社のビジネスに適したものにしてください。 * 作成する [カスタム不正通知](/brand/ja/what-would-you-like-to-learn-about/account-administration/account-settings/notifications/manage-your-brand-notification-settings.md)、このレポートの提供内容を超えて。 [アクションを取り消す](/brand/ja/what-would-you-like-to-learn-about/platform-features/submit-and-modify-conversion-data/batch-modify-conversion-data/batch-modifications-and-reversals-reference.md) 高リスクレベルに関連するものを、 `CONS_FRAUD` 理由コード。 詳細については、 [不正防止](https://impact.com/affiliate/preventing-affiliate-fraud/). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.impact.com/brand/ja/what-would-you-like-to-learn-about/platform-features/protect-and-monitor-your-performance-program/event-risk/understanding-and-interpreting-event-risk-data.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.