• インストール：選択した処理に応じて、アトリビューションをブロックして最後の有効なメディアソースに付け替えるか、アトリビューションを完全にブロックします。
• アプリ内イベント：アプリ内イベントのアトリビューションをブロックします。 

• ブロックの種類ごとの処理は、次の表をご覧ください。
   

  	ブロックの種類	説明	インストールデータの確認先	その後に発生したアプリ内イベント
  インストール	アトリビューションをブロックし、最後の有効なメディアソースに付け替える	インストール自体は実際に発生しているものの、条件に基づいて成果を紐づける流入元を指定したい場合に選択します。 アトリビューションが修正され、インストールは最後の有効なメディアソースに紐づけられます。 有効なメディアソースが見つからない場合は、オーガニックインストールとして扱われます。	AppsFlyerのダッシュボードとローデータレポートに、通常のインストールとして表示されます（最後の有効なメディアソースに紐づけ）。 Protect360プレミアムプランをご利用の場合： Protect360インストールダッシュボード Protect360インストールローデータレポート（ブロックされたメディアソースを表示） Protect360プレミアムプランをご利用でない場合： Protect360インストールローデータレポート（ブロックされたメディアソースを表示）	インストールと同じ、修正後のアトリビューションが適用されます。 Protect360プレミアムプランで確認できるデータ： AppsFlyerのダッシュボードとレポートに、通常のアプリ内イベントとして修正後のアトリビューションで表示 Protect360アプリ内イベントダッシュボードと、Protect360のブロックされたアプリ内イベントのローデータレポートに、ブロックされたメディアソースを表示
  	インストールを無効として扱い、アトリビューションしない	ルールの条件に基づいて無効と判定したインストールを、偽のインストールとみなす場合に選択します。 インストールはアトリビューションされません（非オーガニックにもオーガニックにも分類されません）。	Protect360プレミアムプランをご利用の場合： Protect360インストールダッシュボード Protect360インストールローデータレポート（ブロックされたメディアソースを表示） Protect360プレミアムプランをご利用でない場合： Protect360インストールローデータレポート（ブロックされたメディアソースを表示）	ブロック Protect360プレミアムプランをご利用の場合、Protect360アプリ内イベントダッシュボードと、ブロックされたアプリ内イベントのローデータレポートで確認できます。
  アプリ内イベント	アトリビューションをブロック	ルールの条件に基づいて無効と判定したアプリ内イベントを、偽のイベントとみなす場合に選択します。	Protect360プレミアムプランをご利用の場合： Protect360アプリ内イベントダッシュボード Protect360アプリ内イベントローデータレポート Protect360プレミアムプランをご利用でない場合：利用不可	Protect360プレミアムプランをご利用の場合、Protect360のアプリ内イベントダッシュボードと、ブロックされたアプリ内イベントのローデータレポートで確認できます。
  	AppsFlyerから完全に除外	データを一切必要としないアプリ内イベントがある場合に推奨されます。 AppsFlyerはこれらのイベントを記録しません。

• アドネットワークと代理店は、広告主から必要な権限を付与された場合にのみデータを閲覧できます。
• インストールのアトリビューションがリアルタイムでブロックされるか、有効なメディアソースに付け替えられると、ブロックされたアドネットワークに拒否ポストバックが即座に送信されます。これにより、広告費の精算を円滑に進められます。アトリビューションをブロックして最後の有効なメディアソースに付け替えた場合は、その有効なアドネットワークにもポストバックが送信されます。
• アプリ内イベントのアトリビューションがブロックされると、ブロックされたアドネットワークに拒否ポストバックが即座に送信されます。
  注意：
  • ポストバックは、受信先のアドネットワークがAppsFlyerと連携し、ポストバックを受信できる場合にのみ送信されます。
  • ポストバックと拒否ポストバックのレポートは、レポート出力ページで確認できます。
  • 詳しくは、ポストバックと拒否ポストバックをご覧ください。
• インストールやアプリ内イベントのアトリビューションをブロックしても、影響するのはAppsFlyer上でのデータの表示方法と表示先のみです。エンドユーザーによるアプリの利用は妨げられません。
  • 必要に応じて、ブロックされたインストールとアプリ内イベントのローデータレポートから、利用を停止するアプリユーザーの一覧を取得できます。これらのレポートは、レポート出力、Pull API、Data Lockerで利用できます。
• ブロックされたインストールやアプリ内イベントのレポートと拒否ポストバックには、ブロック理由として、ブロックを行ったルールの名前が含まれます。ルールが複数ある場合は、複数のルールをご覧ください。
  • 検証ルールも存在する場合でも、Protect360の不正対策エンジンがインストールやアプリ内イベントをブロックしたときは、Protect360のブロック理由が表示されます。
• Meta広告やGoogle AdwordsなどのSRNは、独自のロジックでインストールを検証します。このため、検証ルールによってAppsFlyerとSRNのレポートに差異が生じる場合があります。

• 同じインストールやアプリ内イベントに対して、複数の検証ルールを実行できます。これは、インストールが複数のルールの条件に該当する場合に起こります。
• いずれかのルールの条件を満たさない場合、そのインストールやアプリ内イベントは無効と判定されます。
• ローデータレポートと拒否ポストバックのブロック理由の値フィールドには、インストールやアプリ内イベントを無効と判定したすべてのルール名が含まれます。
• 同じインストールに複数のルールを適用する場合、ブロックの種類に応じて次の順序で実行されます。

流入元セクションでは、ルールを適用するインストールの流入元を指定します。

主に次の3つの選択肢があります。 

• すべてのトラフィック：オーガニックと非オーガニックの両方のインストールを含みます。オーガニックインストールには流入元の情報がありません。今後追加するものも含め、すべてのメディアソースが対象です。
  例：アプリバージョンがX未満のすべてのトラフィックにルールを適用します。

• すべての非オーガニックトラフィック：代理店経由・代理店を経由しない流入元を含む、すべての非オーガニックトラフィックに適用します。今後追加する流入元も対象です。
  例：ユーザー獲得（UA）やリターゲティングのキャンペーンを実施していない地域からの非オーガニックトラフィックをブロックします。

• 選択した非オーガニックトラフィック：特定の代理店やメディアソースにのみルールを適用します。ルールの編集時に、メディアソースを手動で選択または追加する必要があります。
  例：CTIT（クリックからインストールまでの時間）がX日を超える場合に、特定のメディアソースからのインストールをブロックします。

Protect360をご利用のお客様は、インストールとアプリ内イベントの流入元について追加の条件を利用できます。 

条件セクションでは、インストールのアトリビューションをブロックする条件や、最後の有効な流入元に付け替える条件を設定します。 

各ルールに、複数の条件や条件グループを追加できます。

次の表に記載されている条件項目、比較条件、値を使って設定します。

一括アップロード

対応する条件項目でリストに含まれるまたはリストに含まれないを選ぶと、新しい項目の追加時にCSVファイルを一括アップロードできます。

手順は次のとおりです。

1. リストに含まれるまたはリストに含まれないを使用できる条件項目を選択します。
2. 比較条件のドロップダウンから、リストに含まれるまたはリストに含まれないを選択します。
3. 新しい項目を追加欄で、CSVファイルをアップロードを選択します。 

注意：CSVファイルには最大17,000件の値を含められます。

Protect360をご利用のお客様は、インストールとアプリ内イベントについて追加の条件を利用できます。 

イベントセクションでアプリ内イベントを選択すると、通常の流入元の条件に加えて、ルールを適用するアプリ内イベントを指定するための追加項目を利用できます。 0>

次の表に記載されているフィールド、比較条件、値を使って設定します。

注意：その他のアプリ内イベントの流入元の条件は、そのイベントに紐づくインストールの流入元に基づきます（代理店、メディアソース、キャンペーン、キャンペーンID、サイトIDなど）。

イベントセクションでアプリ内イベントを選択すると、ルールを適用するアプリ内イベントを指定するための追加の条件を利用できます。これらの条件は、Protect360専用ではない前述の条件のいずれとも組み合わせられます。

Protect360の条件は、次の表に記載されている条件項目、比較条件、値を使って設定します。

Protect360をご利用のお客様は、通常の流入元の条件に加えて、ルールを適用するインストールを指定するための追加項目を利用できます。次の表に記載されているフィールド、比較条件、値を使って設定します。

Protect360をご利用のお客様は、インストールの検証に追加の条件を利用できます。これらの条件は、Protect360専用ではない前述の条件のいずれとも組み合わせられます。

Protect360の条件は、次の表に記載されている条件項目、比較条件、値を使って設定します。

イベントセクションでアプリ内イベントを選択すると、Protect360をご利用のお客様は、ルールを適用するアプリ内イベントを指定するための追加の条件を利用できます。これらの条件は、Protect360専用ではない前述の条件のいずれとも組み合わせられます。

Protect360の条件は、次の表に記載されている条件項目、比較条件、値を使って設定します。

ルールに複数の条件や条件グループを追加した場合は、次のいずれかで組み合わせを指定します。 

• かつ：指定したすべての条件をインストールが満たす場合に該当します。
• または：指定した条件のうち、少なくとも1つをインストールが満たす場合に該当します。

例えば、プラットフォームとOSの両方を使ってインストールを検証する場合は、かつを選択します。これにより、指定したプラットフォームとOSの両方を必ず満たすことが条件になります。プラットフォームまたはOSのいずれかでインストールを検証する場合は、またはを選択します。

アカウント内で作成したすべてのルールを確認するには：

1. AppsFlyerで、設定 > 検証ルールに移動します。
   検証ルール画面が開き、ルールの一覧が表示されます。
2. 一覧表示／詳細表示の切り替えで、表示形式を選択します。
3. 検索とフィルタを使って、一覧のルールを絞り込みます。
   • ルール名、流入元、条件名、値で検索できます。
   • 例えば、7と入力すると、OSバージョンに7を含む条件が設定されたすべてのルールが見つかります。例：「2.7.4」「7.1」など。また、Canadaと入力すると、地域の条件にカナダが設定されたルールが見つかります。 

検証ルールの表には、デフォルトで1ページあたり25件のルールが表示されます。 1ページの表示件数は、10件、25件、50件に変更できます。

検索とフィルタは、表示中のページに関係なく、すべてのルールに適用されます。

新しいルールを設定するには：

1. AppsFlyerで、設定 > 検証ルールに移動します。
   検証ルール画面が開きます。
2. ルールを追加をクリックします。
   新しいルールの追加画面が開きます。
3. ルール名を入力します。 次の条件を満たす、一意の名前を付けてください。
   • ルールの内容が正確に分かる名前。
   • アドネットワークに不快感を与えない名前。ルール名は、ブロックされたインストールのレポートと、アドネットワークへの拒否ポストバックに表示されます。
4. ルール作成画面の各セクションを設定します。
5. ［任意］必要に応じて、条件や条件グループを追加します。条件間・条件グループ間の組み合わせを適切に選択してください。
6. ［任意］トラフィックへの影響を推定をクリックして、ルールがトラフィックに与える影響を確認します。
7. 保存をクリックします。

タグ付けモードを使うと、アトリビューションをブロックする前に、実際のトラフィックで検証ルールをテストできます。タグ付けモードのルールは、条件に一致するインストールやアプリ内イベントに目印を付けます。アトリビューションには影響しません。

タグ付けモードは、インストールとアプリ内イベントにのみ対応しています。

タグ付けモードは、次の目的に使用できます。

• アトリビューションをブロックする前に、実際のトラフィックで複雑なルールをテストします。
• 正常なデータを不正と誤判定する可能性を確認します。
• ルールを適用する前に、どのような理由でルールの対象になるかを確認します。
• ルールのステータスを「適用」に変更する前に、実際のトラフィックへの影響を把握します。

推奨手順：まずタグ付けモードでルールを作成し、Data Lockerでタグ付けされたトラフィックを確認します。判定の正確性を確認できたら、ルールのステータスを「適用」に変更します。不正に対する保護を有効に保つため、この確認は7日未満で完了することを目指してください。

タグ付けモードの仕組み

検証ルールを作成・編集する際は、「ルール適用時の処理」セクションで検知ステータスを選択します。

• タグ付け：条件に一致するデータに、レポート・分析用の目印を付けます。アトリビューションには影響しません。
• 適用：選択した処理に従って、アトリビューションを実際にブロックします。

注意：タグ付けモードは、ルールを保存した時点以降の実際のトラフィックにのみ適用されます。過去のデータにはタグ付けしません。

ルール適用時の処理の設定

「ルール適用時の処理」セクション（旧称「処理」）では、ルールの条件に一致するトラフィックの扱いを指定します。ルール設定の概要も表示されるため、保存前に想定される影響を確認できます。

ルール設定時に確認できる内容

ルールの設定中は、次の設定に応じて、想定される動作が情報パネルに随時表示されます。

• 「条件に一致」または「条件に一致しない」の判定
• アプリの選択
• 検知ステータス

検知ステータスが「タグ付け」の場合、ルールは対象データを確認するための機能として動作します。 AppsFlyerには、条件に一致するデータがData Lockerを含む出力レポートでタグ付けされ、アトリビューションはブロックされないことを知らせる通知が表示されます。

検知ステータスが「適用」の場合、条件に一致するインストールやアプリ内イベントは、選択した処理に応じてアトリビューションがブロックされるか、成果の紐づけ先が変更されます。情報パネルには、保存前に現在の設定による処理の概要が表示されます。

例：「条件に一致」の場合

選択したアプリでルールの条件に一致したインストールについて、情報パネルには次のような処理が表示されます。

• アトリビューションをブロック、またはポストアトリビューションで検知。
• 最後の有効な非オーガニックまたはオーガニックの流入元に成果を付け替え。
• 出力レポートで確認可能。

例：「条件に一致しない」の場合

今後追加するアプリを含む選択したアプリで、ルールの条件に一致しなかったインストールについて、情報パネルには次のような処理が表示されます。

• アトリビューションをブロック、またはポストアトリビューションで検知。
• アトリビューションを修正せず、不正として扱う。
• 出力レポートで確認可能。

これらのアプリでルールの条件を満たすその他のインストールは、ブロックされません。

ルールをタグ付けモードに設定

タグ付けモードで検証ルールをテストするには：

1. AppsFlyerで、設定 > 検証ルールに移動します。
2. 既存のルールを選択するか、「ルールを追加」をクリックします。
3. ルールの詳細、トラフィックの流入元、条件を設定します。
4. 「ルール適用時の処理」セクションで、検知ステータスを「タグ付け」に設定します。
5. 「保存」をクリックします。

保存後、AppsFlyerは条件に一致する実際のトラフィックに、レポート・分析用の目印を付けます。アトリビューションは通常どおり行われます。

タグ付けされたデータの分析

タグ付けされた検証ルールのデータは、Protect360ダッシュボードやFraud Protection Suiteには表示されません。

タグ付けしたルールの影響を分析するには、Data Lockerまたはローデータの出力レポートを使用します。インストールとアプリ内イベントのタグ付けデータを利用できるため、有効なアトリビューションと比較できます。

タグ付けデータの対応表：

タグ付けデータのフィールド

Data Lockerとローデータの出力レポートの次の列で、検証ルールによってタグ付けされたトラフィックを確認できます。

タグ付けしたルールを適用モードに変更

タグ付けされたデータを確認し、ルールが想定どおりに動作していることを確認したら、ステータスを「適用」に変更します。

ルールを「タグ付け」から「適用」に変更するには：

1. AppsFlyerで、設定 > 検証ルールに移動します。
2. ルールを選択します。
3. 「ルール適用時の処理」セクションで、検知ステータスを「適用」に設定します。
4. 「保存」をクリックします。

ルールを保存した時点から、AppsFlyerは選択した処理に従って、条件に一致するトラフィックを実際にブロックします。

ルールを編集、削除、有効化、無効化するには：

• ルール一覧で、対象のルールに対して行う操作を選択します。
  • 有効欄：ルールを有効または無効にします。
  • 操作欄：ルールを編集または削除します。

正規表現のパターンは、一致する文字列を検索するための文字で構成されます。単純なパターンでは、直接一致させたい文字をそのまま指定します。単純な文字の一致だけでは検索できない場合は、パターンに特殊文字を含められます。

例：

次の2つの原因が考えられます。

• 該当するアプリが選択されていることを確認してください。アプリが選択されていない場合、値は検索結果に表示されません。
• 検索している値が過去30日間のトラフィックに含まれている場合にのみ、結果が表示されます。また、コンバージョンが発生してから、流入元や条件の値がメニューに表示されるまでに、最大1日の遅れがあります。

検索結果に値が表示されない場合は、値を自由入力し、キーボードのEnterキーを押してください。

メディアソースフィールドの選択肢は、代理店の選択内容によって変わります。

用途によって異なります。どちらか一方の指定で同じ結果になる場合もあります。両方の指定が必要になる場合もあります。

例えば、米国ではOSバージョン10以降のインストールのみを認め、ブラジルではバージョン7以降を認める場合は、次のようなルールが必要です。

{[Geo = US] and [OS version = 10]} OR {[Geo = Brazil] and [OS version = 7]}

いいえ。検証ルールでは、インストールのブロック、インストールの流入元へのアトリビューションのブロック（クリックやインプレッションのメディアソースへの成果の紐づけを防止）、アプリ内イベントのブロックが可能です。ただし、いずれもクリック自体はブロックしません。検証ルールを実行しても、クリックのKPIには影響しません。

検証ルールではなく、Protect360エンジンによってブロックされたことを示しています。複数のルールもご覧ください。

次の表のとおり、流入元の設定によって異なります。

自動的に適用されない場合は、ルールを編集する必要があります。

• 代理店フィールドを代理店経由と代理店を経由しないトラフィックに変更するか、対象の代理店を選択してください。

最新の指定バージョン数に含まれないを使うと、最新のアプリバージョンからのインストールを許可し、古いバージョンからのインストールをブロックできます。

• 最新のXバージョンに含まれない：選択したアプリの最新Xバージョンからのインストールを許可し、それ以前のすべてのバージョンからのインストールをブロックします。
   
• 各メジャーバージョン内の最新のXバージョンに含まれない：複数のメジャーバージョン系列（例：1.xと2.x）がある場合に使用します。この条件は、各メジャーバージョン系列内の最新Xバージョンからのインストールを許可し、各系列のそれ以前のバージョンをブロックします。

例：最新の指定バージョン数に含まれない

次のアプリバージョンが存在するとします。

• 1.0.01
• 1.0.02
• 1.0.03
• 2.0.01
• 2.0.02
• 2.0.03

最新の2バージョンに含まれないを指定したルール：

• 許可： 
  • 2.0.02
  • 2.0.03
     
• ブロック： 
  • 1.0.01
  • 1.0.02
  • 1.0.03
  • 2.0.01

例：各メジャーバージョン内の最新の指定バージョン数に含まれない

上記と同じバージョン一覧で、各メジャーバージョン内の最新の2バージョンに含まれないを指定したルール：

• 許可： 
  • 1.0.02
  • 1.0.03
  • 2.0.02
  • 2.0.03
     
• ブロック： 
  • 1.0.01
  • 2.0.01

複数のアプリを選択した場合の動作

ルールで複数のアプリを選択した場合、AppsFlyerは最新の指定バージョン数に含まれない条件を、アプリごとに個別に判定します。

例えば、最新の3バージョンに含まれないを指定し、アプリA、B、Cを選択した場合：

• アプリAは、アプリAのバージョン履歴に基づく最新3バージョンを許可します。
• アプリBは、アプリBのバージョン履歴に基づく最新3バージョンを許可します。

アプリCは、アプリCのバージョン履歴に基づく最新3バージョンを許可します。

インプレッションによる広告接触へのアトリビューションを防ぎ、有効なクリックへのアトリビューションのみを維持したい場合は、検証ルールを使用します。有効なクリックに基づくメディアソースが見つからない場合、インストールはオーガニックに紐づけられます。この設定は、インストールハイジャックに関連するアトリビューションへの対処に役立ちます。

ルールの設定手順：

• トラフィックの流入元で、すべての非オーガニックトラフィックを選択します。
• 条件で、アトリビューション対象の広告接触の種類を選択します。
  • 比較条件をリストに含まれるに設定します。
  • インプレッションを選択します。
• 処理で、アトリビューションをブロックし、最後の有効なメディアソースに付け替えるを選択します。

この用途では、インストールを無効として扱い、アトリビューションしないを選択しないでください。この処理は、無効または偽のインストールと判断した場合に使用するものです。インストール自体は実際に発生していても、インプレッションへの成果の紐づけを避けたい場合は、アトリビューションをブロックし、最後の有効なメディアソースに付け替えるを使用してください。

はい。タグ付けモードは、「かつ／または」の組み合わせ、地域、OSバージョン、SDKバージョン、イベント値など、検証ルールのすべての比較条件とフィールドに対応しています。

いいえ。タグ付けされたデータは、ブロックされたトラフィックには分類されません。タグ付けされたトラフィックは「タグ付け」として扱われ、有効なトラフィックの一部に分類されます。 Data Lockerの有効なデータのレポートで確認できます。

検証ルールのタグ付けデータは、Data Lockerまたはローデータの出力レポートで確認できます。タグ付けされたインストールはタグ付けされたインストールのレポート、タグ付けされたアプリ内イベントはタグ付けされたアプリ内イベントのレポートで確認できます。

タグ付けされたデータは、Protect360ダッシュボードやFraud Protection Suiteには表示されません。

はい。出力したデータを確認し、ルールが想定どおりに動作していることを確認したら、ルールを編集して検知ステータスを「適用」に設定し、保存します。その時点から、ルールは選択した処理に従って、条件に一致するトラフィックを実際にブロックします。

タグ付けモードは、プレミアムプランをご利用のお客様が利用できます。タグ付けモードに設定できるルール数に厳密な上限はありません。タグ付けしたルールを確認し、判定の正確性を確認できたら「適用」に変更することを推奨します。