検証ルールの「イベントの順序・実行間隔を検証するルール」では、実際のユーザーが実行するはずの一連のイベントを、広告主が定義できます。定義した順序やイベント間の実行間隔から外れた場合に、検知してブロックします。
概要
広告主は、アプリ内で実際のユーザーが実行するはずの一連のイベントを定義できます。 AppsFlyerは、ルールを保存した日から始まる判定対象期間を使って、これらのイベントを評価します。判定対象期間は毎日延びて最大30日間となり、その後は毎日1日ずつ更新される直近30日間が対象になります。ルールの作成前に発生したイベントは、判定対象になりません。
イベントの順序や実行間隔がルールから外れると、そのユーザーは架空のユーザーと判定され、次の処理が行われます。
- ルールから外れた時点より後のすべてのアプリ内イベントとセッションが、直ちにブロックされます。
- インストールがポストアトリビューション期間（7日間）内にある場合、そのインストールはポストアトリビューションでブロックされます。
- 判定対象期間内の関連するアプリ内イベントは、ポストアトリビューション処理の一環としてブロックされます。
- アプリ内の他の箇所で発生し、ルールの条件を満たしている他のアプリ内イベントには、影響しません。
注意：アプリの選択、条件、流入元、イベントの順序、有効・無効の切り替えなど、ルールのどの項目を編集しても、判定対象期間は0日目にリセットされます。
利用に適したアプリと流入
この機能は、次の条件を満たす場合にのみ適しています。
- SDKイベント：SDKイベントのみでルールを作成するアプリ。
- 繰り返し発生しないイベント：定義する一連のイベントの中で、同じイベントが複数回発生しないアプリ。同じイベントが複数回発生した場合（たとえば、イベントCが2回送信された場合）、ルール違反として扱われ、関連するイベントがブロックされます。
- 非オーガニック流入：この機能は、非オーガニック流入のみで利用できます。
イベントの順序・実行間隔を検証するルールの設定方法
次の手順で、イベントの順序・実行間隔を検証するルールを設定します。
- ［設定］＞［検証ルール］に移動します。
- ［＋新しいルール］をクリックします。
- ルール名を入力します。
- ［ポストアトリビューション（Post attribution）］タブを選択します。
- ルールを設定するアプリを選択します。
注意：1つのルールで選択できるアプリは1つだけです。 - ルールを適用する流入元を定義します。
- 条件を選択します。現在、次の項目を選択できます。
- 国・地域（Geo）
- デバイスモデル（Device model）
- ユーザーを一意に識別するIDは、選択したアプリに基づいて自動的に設定されます。iOSではIDFA、Androidでは広告ID（Advertiser ID）が設定されます。どちらのプラットフォームでも、代わりにカスタマーユーザーID（Customer User ID）を使用するよう変更できます。
- イベントの順序を定義します。実際のユーザーが実行するはずの順序で、2つ以上のイベントを追加してください。
- 必要に応じて、前後するイベント間の最短実行間隔を設定します。設定しない場合は、デフォルトで最短1秒が適用されます。
- ［ルールの適用結果（Rule outcome）］セクションで、判定対象期間の状態と、一連のイベント全体に必要な最短時間を確認します。
- ［保存］をクリックします。
重要！
アプリのすべてのイベントを選択しないでください。不正が発生する可能性のあるイベントのみを選択してください。
データの確認
このルールによってインストールやアプリ内イベントがブロックされると、詳細がローデータレポートに記録されます。［ローデータ］＞［Protect360と検証ルール（Protect360 & Validation Rules）］に移動してブロックされたイベントを確認し、以下のフィールドを使って、このルールでブロックされたものを特定してください。
| レポート | 主なフィールド |
|---|---|
| ポストアトリビューションで検知されたインストール |
|
| ポストアトリビューションで検知されたアプリ内イベント |
|
| ブロックされたアプリ内イベント |
|
例
以下では、さまざまなイベントの実行例と、それぞれが不正と判定されるかどうかを説明します。
例1
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 1日目：イベントAを送信
- 2日目：イベントBを送信
- 3日目：イベントCを送信
結果：
不正とは判定されません。ユーザーは、定義した順序どおりに一連のイベントを実行しました。
例2
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 1日目：イベントAを送信
- 2日目：イベントCを送信
- 3日目：イベントBを送信
結果：
不正と判定されます。ユーザーは、イベントBより先にイベントCを実行しており、定義した順序から外れています。その結果、次の処理が行われます。
- イベントAは、ポストアトリビューションでブロックされます。
- イベントBは、リアルタイムでブロックされます。
- イベントCは、定義した順序から外れたイベントであるため、リアルタイムまたはポストアトリビューションでブロックされます。
- 以降のすべてのイベントは、リアルタイムでブロックされます。
例3
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB（前のイベントからの最短実行間隔：1時間）
- イベントC（前のイベントからの最短実行間隔：2時間）
実際の動作
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 0日目：イベントAを送信
- 0日目：イベントAの10分後にイベントBを送信
- 0日目：イベントBの2時間後にイベントCを送信
結果：
不正と判定されます。ユーザーはすべてのイベントを正しい順序で実行しましたが、イベントAとイベントBの実行間隔は10分しかなく、設定した最短実行間隔の1時間を下回っています。順序が正しくても、実行間隔の条件を満たしていないため、ルール違反となります。その結果、次の処理が行われます。
- イベントAは、ポストアトリビューションでブロックされます。
- イベントBは、最短実行間隔の条件に違反したため、リアルタイムでブロックされます。
- イベントCは、ルール違反が発生した後のイベントであるため、リアルタイムでブロックされます。
- 以降のすべてのイベントは、リアルタイムでブロックされます。
例4
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 1日目：イベントAを送信
- 2日目：イベントBを送信
- イベントCは送信されていない
結果：
不正とは判定されません。ユーザーはイベントAとイベントBを正しい順序で実行しましたが、イベントCは実行していません。一連のイベントが未完了でも、ルール違反とは判定されません。ブロックされるイベントはありません。ルールは、30日間の判定対象期間内で、今後のイベントを引き続き評価します。
例5
設定したルール
ユーザーは、カスタマーユーザーID（CUID）で識別されていました。
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 1日目：イベントAを送信
- 1日目：アンインストールが発生
- 1日目：インストールが発生
- 2日目：イベントBを送信
- 3日目：イベントCを送信
結果：
不正とは判定されません。ユーザーがカスタマーユーザーID（CUID）で識別され、イベントも順序どおりに実行されたためです。
例6
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは、広告IDで識別されていました。
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 1日目：イベントAを送信
- 1日目：アンインストールが発生
- 1日目：インストールが発生
- 2日目：イベントBを送信
- 3日目：イベントCを送信
結果：
不正とは判定されません。ユーザーが広告IDで識別され、イベントも順序どおりに実行されたためです。
例7
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
ルールは1月1日に作成されました。
実際の動作：
- 1月1日（0日目）：ルールを作成。判定対象期間が始まります。この日より前に発生したイベントは、判定対象から除外されます。
- 1月15日（14日目）：イベントAを送信。判定対象期間は延びている途中で、この時点では過去14日間が対象です。
- 1月30日（29日目）：イベントBを送信。判定対象期間は延びている途中で、この時点では過去29日間が対象です。
- 1月31日（30日目）：判定対象期間が30日間に達し、以降は毎日1日ずつ更新される直近30日間が対象になります。
- 2月20日：イベントCを送信。この時点の判定対象期間は、30日前の1月21日まで遡ります。 1月15日に発生したイベントAは、判定対象期間の範囲外となり、評価されなくなります。
結果：
不正とは判定されません。 2月20日時点では、判定対象期間が1月21日まで遡るため、1月15日のイベントAは判定対象期間の範囲外です。イベントBとイベントCのみが評価され、どちらも正しい順序で実行されているため、ルール違反とは判定されません。
例8
設定したルール
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは次の順序でイベントを実行しました。
- 0日目：インストールが発生
- 1日目：イベントAを送信
- 2日目：イベントBを送信
- 3日目：イベントBを送信
- 4日目：イベントCを送信
結果：
不正と判定されます。同じイベント（イベントB）が2回発生したため、不正とみなされます。一連のイベントの中で、同じイベントを2回実行することはできません。
例9
設定したルール
ユーザーは、カスタマーユーザーID（CUID）で識別されていました。
ユーザーが次の順序でイベントを実行するように設定します。
- イベントA
- イベントB
- イベントC
実際の動作
ユーザーは、同じCUIDを使い、2台のデバイスでイベントを実行しました。
- 0日目：デバイス1でインストールが発生
- 0日目：デバイス2でインストールが発生
- 1日目：デバイス1からイベントAを送信
- 2日目：デバイス2からイベントBを送信
- 3日目：デバイス1からイベントCを送信
結果：
不正とは判定されません。ユーザーがCUIDで識別されていたため、同じCUIDとルールIDに関連付けられたすべてのAppsFlyer IDにまたがって、イベントの順序が評価されます。どのデバイスから送信されたかにかかわらず、イベントA、B、Cは正しい順序で実行されました。
仕様と制限事項
- 各ルールには、最大100個のイベントを定義できます。
- イベントが80個に達すると、警告が表示されます。 100個で上限に達するため、それ以上追加するにはルールを分割する必要があります。
- 連続するイベント間に設定できる最短実行間隔は、1秒です。前後するイベント間の実行間隔を設定しない場合は、デフォルトの1秒が自動的に適用されます。
- イベント間に設定できる最長実行間隔は、判定対象期間に合わせて30日間です。
- 判定対象期間は0日目（ルールの作成日）に始まり、毎日延びて最大30日間となります。その後は、毎日1日ずつ更新される直近30日間が対象になります。ルールの作成前に発生したイベントは、判定対象になりません。
- ルールのどの項目を編集しても、判定対象期間は0日目にリセットされます。
- アカウントごとに、有効なルールを最大10個設定できます。
- イベントの順序・実行間隔を検証するルールは、非オーガニック流入のみで利用できます。
- SDK経由のトラフィックのみが対象です。 S2S経由のトラフィックは、フェーズ1では対象外です。
- 一連のイベントが未完了でも、ルール違反とは判定されません。
- 一連のイベントの中で、同じイベントを2回実行することはできません。
- 複数の条件の組み合わせには、すべての条件を満たすAND条件のみ対応しています。いずれかの条件を満たすOR条件には対応していません。
よくある質問
再インストール後は、どのように判定されますか？
再インストールによって、ユーザーがすでに完了したイベントがリセットされる場合は、ルール違反として扱われます。ユーザーが中断したところから再開する場合は、ルール違反とは判定されません。