検証ルールの実装｜不正防止

• インストールの場合：  選択したアクションに応じて、検証ルールはアトリビューションをブロックして最後に有効だったメディアソースへ修正するか、アトリビューションを完全にブロックします。
• アプリ内イベントの場合：検証ルールは、そのアプリ内イベントのアトリビューションをブロックします。

• 検証ルールのブロックタイプごとの結果は、以下の表を参照してください：
   

  	ブロックタイプ	説明	インストールデータを確認できる場所	その後に発生するアプリ内イベント
  インストール	アトリビューションをブロックし、最後に有効だったメディアソースへ修正する	インストール自体は実在すると判断しているものの、ルールの条件に基づき、どの流入元へアトリビューションすべきか、またはすべきでないかを判定する場合に選択します。 アトリビューションは修正され、インストールは最後に有効だったメディアソースへアトリビューションされます。 有効なメディアソースが見つからない場合、インストールはオーガニックとして扱われます。	通常のインストールとして、AppsFlyerのダッシュボードおよびローデータレポートに表示されます。アトリビューション先は、最後に有効だったメディアソースです。 Protect360をご利用の場合： Protect360のインストールダッシュボード Protect360のインストールローデータレポート（ブロックされたメディアソースを含む） Protect360をご利用でない場合： Protect360のインストールローデータレポート（ブロックされたメディアソースを含む）	インストールと同じように、修正後のアトリビューションが適用されます。 Protect360で利用可能なデータ： 通常のアプリ内イベントとして、修正後のアトリビューションでAppsFlyerのダッシュボードおよびレポートに表示されます。 Protect360のアプリ内イベントのダッシュボードおよびProtect360のブロック済みアプリ内イベントローデータレポートには、ブロックされたメディアソースとともに表示されます。
  	インストールを無効として扱い、アトリビューションしない	ルールの条件に基づいて無効と判断されたインストールを、フェイクインストールとみなす場合に選択します。 インストールは、非オーガニックにもオーガニックにもアトリビューションされません。	Protect360をご利用の場合： Protect360のインストールダッシュボード Protect360のインストールローデータレポート（ブロックされたメディアソースを含む） Protect360をご利用でない場合： Protect360のインストールローデータレポート（ブロックされたメディアソースを含む）	ブロックされます。 Protect360では、Protect360のアプリ内イベントダッシュボードおよびブロック済みアプリ内イベントのローデータレポートでデータを確認できます。
  アプリ内イベント	アトリビューションをブロックする	ルールの条件に基づいて無効と判断されたアプリ内イベントを、フェイクイベントとみなす場合に選択します。	Protect360をご利用の場合： Protect360のアプリ内イベントの画面 Protect360のアプリ内イベントのローデータレポート Protect360をご利用でない場合：N/A	Protect360では、Protect360のアプリ内イベントダッシュボードおよびブロック済みアプリ内イベントローデータレポートでデータを確認できます。
  	AppsFlyerから完全に削除する	データ自体が不要なアプリ内イベントがある場合に使用することを推奨します。 AppsFlyerは、これらのイベントを一切記録しません。

• 広告主から必要な権限が付与されている場合に限り、アドネットワークおよび代理店はデータを確認できます。
• インストールのアトリビューションがリアルタイムでブロックされた場合、または有効なメディアソースへ修正された場合は、照合作業を円滑に進められるよう、ブロック対象のアドネットワークへリジェクトポストバックが即座に送信されます。アトリビューションがブロックされ、最後に有効だったメディアソースへ修正された場合は、その最後に有効だったアドネットワークにもポストバックが送信されます。
• アプリ内イベントのアトリビューションがブロックされた場合は、ブロック対象のアドネットワークへリジェクトポストバックが即座に送信されます。
  注意：
  • ポストバックは、送信先となるアドネットワークがAppsFlyerと連携し、ポストバックを受信するよう設定されている場合にのみ送信されます。
  • ポストバックとブロックされたデータのポストバックレポートは、データエクスポートページから利用可能です。
  • 詳細は、ポストバックとブロックされたデータのポストバックをご覧ください。
• インストールおよびアプリ内イベントのアトリビューションブロックは、AppsFlyer上でデータがどのように、どこに表示されるかにのみ影響します。あくまでも成果の紐付け先やアトリビューション計測停止のみであり、データのみに影響し、エンドユーザーのアプリの使用を妨げることは一切ありません。
  • 必要に応じて、ブロック済みインストールおよびブロック済みアプリ内イベントのローデータレポートを使用して、無効化の対象となるアプリユーザーの一覧を取得できます。これらのレポートは、エクスポート、Pull API、Data Lockerから利用できます。
• ブロック済みインストール／アプリ内イベントレポートおよびリジェクトポストバックでは、インストールまたはアプリ内イベントをブロックしたルール名が、ブロック理由として表示されます。ルールが複数ある場合は、「複数ルールの適用」のセクションを参照してください。
  • Protect360の不正防止エンジンによってインストールまたはアプリ内イベントがブロックされた場合は、検証ルールも同時に該当していたとしても、Protect360の判定理由が表示されます。
• Meta広告やGoogle AdwordsなどのSRNは、独自のロジックでインストールを検証しているため、検証ルールの適用によってAppsFlyerとの間にレポート上の差異が生じる場合があります。

• 同じインストールまたはアプリ内イベントに対して、複数の検証ルールが実行される場合があります。これは、そのインストールが複数のルールの条件を満たした場合に発生します。
• インストールまたはアプリ内イベントは、各ルールの条件のいずれか1つでも個別に満たさなかった場合、無効と分類されます。
• ローデータレポートとブロックされたデータのポストバックレポートでは、block reasonの値の項目には、インストールイベントまたはアプリ内イベントを無効として分類した全ルール名が記載されます。
• 同一のインストールに複数のルールが適用される場合、ルールのブロックタイプに基づき、以下の順序で処理されます。

流入元セクションでは、ルールを適用するインストールのトラフィックソースを定義します。

主なオプションは、以下の3つです： 

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

• すべての非オーガニックトラフィック：代理店経由と代理店以外の両方を含む、すべての非オーガニックトラフィックソースに適用されます。今後追加される新しい流入元も含まれます。
  例：UAキャンペーンまたはリターゲティングキャンペーンを実施していない特定の地域から発生した非オーガニックトラフィックをブロックする。

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

Protect360を利用しているお客様は、インストールおよびアプリ内イベントに対して、追加の流入元オプションを利用できます。 

条件セクションでは、インストールのアトリビューションをブロックするか、最後に有効だった流入元へアトリビューションし直すかを判断する条件を定義します。 

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

条件は、以下の表に記載されている条件、演算子、値に基づいて定義します。

一括アップロード

一括アップロードに対応している条件で、演算子としてIn list（リストに含まれる）またはnot in list（リストに含まれない）を選択した場合、新しい項目を追加する際にCSVファイルを一括アップロードできます。

以下の手順を実行します：

1. 「In list（リストに含まれる）」または「not in list（リストに含まれない）」の演算子に対応している条件を選択します。
2. 演算子のドロップダウンリストから「In list（リストに含まれる）」または「not in list（リストに含まれない）」を選択してください。
3. 「新しい項目を追加」のボックスから「CSVファイルをアップロード」を選択します。 

注意：CSVファイルには、最大17,000件の値を含めることができます。

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

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

流入元は、以下の表に記載されているフィールド、演算子、値に基づいて定義します。

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

イベントセクションでアプリ内イベントを選択すると、ルールを適用するアプリ内イベントを定義するための追加条件を利用できます。これらの条件は、前述のProtect360以外の条件と自由に組み合わせて使用できます。

Protect360の条件は、以下の表に記載されている条件、演算子、値に基づいて定義します。

Protect360を利用しているお客様は、通常の流入元オプションに加えて、ルールを適用するインストールを定義するための追加の流入元オプションを利用できます。流入元は、以下の表に記載されているフィールド、演算子、値に基づいて定義します。

Protect360を利用しているお客様は、インストールを検証するための追加条件を利用できます。これらの条件は、前述のProtect360以外の条件と自由に組み合わせて使用できます。

Protect360の条件は、以下の表に記載されている条件、演算子、値に基づいて定義します。

イベントセクションでアプリ内イベントを選択すると、Protect360を利用しているお客様は、ルールを適用するアプリ内イベントを定義するための追加条件を利用できます。これらの条件は、前述のProtect360以外の条件と自由に組み合わせて使用できます。

Protect360の条件は、以下の表に記載されている条件、演算子、値に基づいて定義します。

1つのルールに複数の条件または条件グループを追加する場合は、それらの論理関係として以下のいずれかを選択します：

• AND：インストールが、定義したすべての条件を満たすことを意味します。
• OR：インストールが、定義した条件のうち少なくとも1つを満たすことを意味します。

たとえば、プラットフォームとOSの両方に基づいてインストールを検証する場合は、ANDを選択する必要があります。これにより、指定したプラットフォームと指定したOSが常に同時に満たされる必要があります。一方、プラットフォームまたはOSのいずれかに基づいてインストールを検証する場合は、ORを選択します。

アカウント内で作成された全てのルールを表示する方法：

1. AppsFlyerで、以下の場所に移動します 設定 > 検証ルール
   「検証ルール」ウィンドウが開き、検証ルールの一覧が表示されます。
2. リスト表示 / 詳細表示のトグルを使用して、表示方法を選択してください。
3. 検索とフィルタオプションを使用してリスト内のルールを絞り込んでください。
   • ルール名、メディアソース、条件名、値で検索できます。
   • たとえば、7と入力すると、OSバージョンに7を含む条件が設定されたすべてのルールを検索できます。対象には、2.7.4や7.1などが含まれます。また、Canadaと入力すると、地域条件としてCanadaが定義されているルールを検索できます。  

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

検索およびフィルターは、現在表示しているページにかかわらず、すべてのルールに対して適用されます。

新しいルールを設定する方法：

1. AppsFlyerで、以下の場所に移動します 設定 > 検証ルール
   検証ルール画面が開きます。
2. [ルールの追加] をクリックします。
   「新しいルールを追加」ウィンドウが開きます。
3. まず、ルール名を入力してください。 ルール名には、以下の条件を満たす一意の名前を使用してください：
   • ルールの内容を正確に表している
   • アドネットワークに送信されるブロック済みのインストールレポートとブロックされたデータのポストバックレポートにも表示されるため、アドネットワークに対して失礼ではないルール名であること
4. ルールビルダーの各セクションを完了してください。
5. ［任意］ 必要に応じて、条件や条件グループを追加します。条件または条件グループ間の適切なロジックが選択されていることを確認してください。
6. ［任意］［トラフィックへの影響を推定］をクリックして、ルールがトラフィックに与える影響を確認します。
7. 保存をクリックします。

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

例：

考えられる理由は2つあります。

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

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

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

ユースケースによって異なります。どちらか一方の設定だけで同じ結果を得られる場合もあれば、両方の設定が必要となる場合もあります。

たとえば、米国ではOSバージョン10以降のインストールのみを許可し、ブラジルではOSバージョン7以降のインストールを許可する場合は、以下のようなルールが必要です。

{［地域 = 米国］AND［OSバージョン = 10］} OR {［地域 = ブラジル］AND［OSバージョン = 7］}

いいえ。検証ルールでは、以下の処理を実行できます。 ・インストールをブロックする ・インストールの流入元へのアトリビューションをブロックする ・アプリ内イベントをブロックする インストールの流入元へのアトリビューションをブロックすると、そのクリックまたはインプレッションのメディアソースにはアトリビューションが付与されません。ただし、いずれの処理でも実際のクリック自体がブロックされることはなく、検証ルールを適用してもクリックに関するKPIには影響しません。

これは、そのインストールが検証ルールではなく、Protect360エンジンによってブロックされたことを意味します。併せて、複数のルールセクションをご覧ください。

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

ルールが自動的に適用されない場合は、ルールを編集し、代理店フィールドを以下のいずれかに変更する必要があります。

• ・代理店経由および代理店以外のトラフィック ・対象となる特定の代理店

「Not in last（直近のバージョンに含まれない）」の条件を使用すると、最新のアプリバージョンからのインストールを許可し、それより古いバージョンからのインストールをブロックできます。

• Not in last X versions（直近のXバージョンに含まれない）：選択したアプリの直近のX個のバージョンからのインストールのみを許可し、それ以前のすべてのバージョンからのインストールをブロックします。
   
• Not in last (major) X versions（直近のXのメジャーバージョンに含まれない）：バージョン体系に複数のメジャーバージョン系列が含まれる場合に使用します。たとえば、1.x系列と2.x系列がある場合です。この条件では、各メジャーバージョン系列内の直近X個のバージョンからのインストールを許可し、それぞれの系列におけるそれより古いバージョンからのインストールをブロックします。

例：Not in last (直近のバージョンに含まれない)

以下のアプリバージョンが存在するとします：

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

Not in last 2 versions（直近の2バージョンに含まれない）と設定したルールでは、以下のように処理されます。

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

例：Not in last (major) (直近のメジャーバージョンに含まれない)

上記と同じバージョン一覧を使用し、Not in last (major) 2 versions（直近の2メジャーバージョンに含まれない）と設定したルールでは、以下のように処理されます。

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

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

ルールで複数のアプリを選択した場合、AppsFlyerはNot in last（直近のバージョンに含まれない）の条件をアプリごとに個別に評価します。

たとえば、Not in last 3 versions（直近の3バージョンに含まれない）と設定し、アプリA、アプリB、アプリCを選択した場合は、以下のように処理されます。

• アプリAでは、アプリAのバージョン履歴に基づく直近3バージョンが許可されます。
• アプリBでは、アプリBのバージョン履歴に基づく直近3バージョンが許可されます。

アプリCでは、アプリCのバージョン履歴に基づく直近3バージョンが許可されます。

インプレッションベースのエンゲージメントへのアトリビューションを防ぎ、有効なクリックに対するアトリビューションのみを維持したい場合は、検証ルールを使用します。有効なクリックベースのメディアソースが見つからない場合、インストールはオーガニックとしてアトリビューションされます。この設定は、インストールハイジャックに関連するアトリビューションの問題に対処する際に役立ちます。

ルールは以下のように設定します：

• トラフィックソースで、すべての非オーガニックトラフィックを選択します。

• 条件で、アトリビューションタッチタイプを選択します。

  • 演算子をIn list（リストに含まれる）に設定します。

  • 「インプレッション」を選択します。

• アクションで、［アトリビューションをブロックし、最後に有効だったメディアソースへ修正する］を選択します。

このユースケースでは、［インストールを無効として扱い、アトリビューションしない］を選択しないでください。このアクションは、無効または不正と判断したインストールを対象としています。インストール自体は有効であるものの、インプレッションベースのエンゲージメントにはアトリビューションしたくない場合は、代わりに［アトリビューションをブロックし、最後に有効だったメディアソースへ修正する］を使用してください。

はい。タグ付けモードは、以下を含むすべての検証ルールの演算子とフィールドに対応しています。 ・AND／ORロジック ・地域 ・OSバージョン ・SDKバージョン ・イベント値

いいえ。タグ付けされたデータは、ブロックされたトラフィックには分類されません。タグ付けされたトラフィックはタグ付け済みとして処理され、有効なトラフィックの一部とみなされます。Data Lockerでは、有効なデータのレポート内に表示されます。

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

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

はい。エクスポートデータを確認し、ルールが想定どおりに機能していることを確認したら、ルールを編集し、検知ステータスを適用済みに設定して保存します。保存した時点から、選択したルールの結果に従って、条件に一致するトラフィックが実際にブロックされます。

タグ付けモードは、Premiumプランのお客様が利用できます。タグ付けに設定できるルール数に、厳密な上限はありません。ベストプラクティスとして、タグ付けされたルールの結果を確認し、ルールの精度に問題がないと判断したら、ステータスを適用済みに変更してください。