イベントルールの設定

イベントルール はコンバーションルールを拡張し、定義したカスタム条件に基づいて インストール後のイベント を検証します。
イベントがこれらの条件を満たさない場合、Adjustはそれを拒否し、コールバック、CSVエクスポート、レポートで拒否を報告します。

グロースソリューション:

アカウントでコンバーションルール（およびイベントルール）を有効にするには、sales@adjust.comまでお問い合わせください。

事前準備

はじめに、以下の設定手順をご覧ください。

要件

Adjustの管理者、編集者、またはカスタム編集者のユーザー権限。
Adjustにシングルまたはマルチプラットフォームアプリを設定。

イベントルールの設定

イベントルールを設定するには、以下の手順に従ってください。

AppViewで イベントとサブスクリプション（Events & subscriptions） を開き、検証したいイベントを選択します。
イベント編集（Edit event） を選択します。
設定するチェックに移動します。
次のステータスオプションから1つ選択します。
- ライブ（Live） - ルールが保存されると、Adjustシステムでチェックが有効になります。チェックを満たしていないイベントは拒否されます。
- テスト（Test） - ルールが保存されると、Adjustシステムでのチェックが有効になります。チェックを満たさないイベントは 拒否されません が、フラグが付けられ、レポートされます。
- 一時停止（Pause） - ルールはどのイベントにも適用されていません。このステータスを使用して、変更を有効化せずに保存します。
1つ以上の チェック を設定します（チェックを参照）。
変更を保存（Save changes） を選択します。

注意:

初期イベント作成プロセス中にイベントルールチェックを設定することもできます。

イベントルールチェックを削除

チェックを削除するには、ステータスを OFF に設定します。

*** ** * ** ***

チェック

イベントルールに複数のチェックを適用することができます。
ライブ ステータスのチェックが失敗した場合、イベントは 拒否されます 。

ターゲットフィルター

ターゲットフィルターを使用して、各チェックが適用されるトラフィックを絞り込みます。フィルターはチェックごとに設定され、同じルール内の他のチェックには影響しません。

キャンペーンレベル

デフォルトでは、チェックは全てのチャネルに適用されます。チェックの対象とするキャンペーン構造のレベルを選択してください。

チャネル — チェックの対象を1つ以上のチャネルに設定します。
キャンペーン — チェックの対象をチャネルに設定し、さらにその中の1つまたは複数のキャンペーンに絞り込みます。
アドグループ — チェック対象をチャネルとキャンペーン、さらにその中の1つ以上のアドグループ（出典ID）に絞り込みます。

注意:

選択したキャンペーンレベルに一致するフィールドのみが複数選択に対応しています。例えば、 アドグループ モードでは、1つのチャネル、1つのキャンペーン、1つ以上のアドグループを選択します。そのレベルより上のフィールド（チャネル、チャネル + キャンペーン）は単一選択であり、選択したレベルに絞り込むためだけに存在します。

特定の値を選択したレベルでのみ、選択内容が反映されます。選択したレベルのフィールドを すべて のままにするか、未選択のままにした場合（例： アドグループ を選択してもキャンペーンを選択しない場合）、保存時に設定は、実際に特定の値が選択された最も近いレベルに戻ります（例：アドグループ → キャンペーン、または何も選択されていない場合はアドグループ/キャンペーン → チャネル）。

アプリバージョンをインストール

アプリの特定のバージョンをインストールしたユーザーのみにチェックを制限します。この機能を使用すると、そのルールを適用することが適切なユーザーに対してのみルールが実行されます。例えば、ルールで使用しているイベントやユーザーフローがアプリの特定バージョン以降で追加された場合、そのバージョン以降をインストールしたユーザーのみを対象にルールを適用できます。これにより、ルールの前提となる機能が存在しないユーザーにはルールが適用されません。

注意:

アプリバージョンをインストールは、現在のアプリバージョンではなく、インストール時のバージョンを参照します。インストール後にアップグレードするユーザーは、ルール評価のために元のインストールバージョンを保持します。

*** ** * ** ***

ソース確認

これを使用すると、どのイベントソースが受け入れられるかを管理し、アプリで無効になったイベントを処理することができます。

受け入れられたイベントソース

受け入れ可能なイベントソースを制限します。

SDK - SDK発信のイベントのみを受け入れます。
S2S - サーバー間イベントのみを受け入れます。
- アプリで S2S許可リスト登録 が有効になっている場合、デフォルトではすべてのイベントに適用されます。特定のイベントではこれを無効にして、IPチェックの対象から除外できます。たとえば、信頼できるパートナーのサーバーからのイベントにはトークン認証のみが必要である一方、内部または機密性の高いフローからのイベントには追加のIP制限を維持する必要がある場合です。

許可されていないソースからイベントを受信した場合、拒否されます。

ヒント:

SDK発信のイベントでは、最適に保護されるようにSDKシグネチャーの連携と設定を確認します。
S2S発信のイベントでは、S2Sセキュリティ設定を確認してください。

非推奨イベント

イベントがアプリから削除され、トリガーされなくなった場合は、イベントを拒否します。これを使用すると、アプリのイベントフローの一部でなくなったイベントの残りのトリガーを無効にすることができます。

*** ** * ** ***

フロー確認

これを使用して、イベントの期待される順序、タイミング、および必要なパラメーターを制御します。
複数の条件を選択できます。この場合、イベントを渡すには、選択された全ての条件を満たす必要があります。そうでない場合、イベントは拒否されます。

インストールからの時間（Time from install）

イベントはインストール後の特定の期間内またはその後に発生する必要があります。
例：「インストール後5分以上経過」

先行イベントが必要（Preceding event required）

このイベントの前に特定のイベント（レベル1など）が発生する必要があります。追加の制約として、必要な先行イベントと現在のイベント間の最小または最大の時間枠を指定できます。

重要:

先行イベントが必要（Preceding event required） 条件は、 SDK から送信されたイベントにのみ適用されます。
サーバー間（S2S） で送信されたイベントに対しては、正しく評価されないため、このチェックを設定しないでください。

イベントは...の場合に発生しない - 特定のイベントを相互に排除する

このユーザーに対して指定された他のイベントがすでにトリガーされている場合、イベントを拒否します。これを使用して、2つのイベント間で相互排他を強制します。片方のイベントが発生した場合、もう一方はブロックされます。
例：「返金がすでに発生した場合は、購入は発生しません。」

注意:

既存の相互除外ルールにすでにリンクされているイベントは、ドロップダウンで Xに接続済みです とマークされています。

重要:

この条件を定義すると、指定されたイベントに対して、同じルールステータスを持つ対象ルールが自動的に作成され、UIに表示されます。
ターゲットフィルター を使用する場合、拒否の動作に一貫性がなくなることを避けるため、両方のイベントでフィルターが一致するようにしてください。

イベントの最後のトリガーは少なくとも前回発生しました — 時間ベースのイベント抑制

指定した時間より小さい間隔でトリガーされたイベントをは拒否します。これを使用して、特定のユーザーが同じイベントを受け付ける頻度を制限します。
例：「購入の最後のトリガーが少なくとも 5分前に発生」

必須パラメーター（Required parameters）

イベントのSDKパラメーターを1つ以上の条件と照合して確認します。例えば、キーが存在することを必須とする、あるいはその値が特定の値に一致する、特定の値を含む、または特定の値を除外するなどです。

各条件について、 条件タイプ を選択します。

存在する — 値に関係なく、1つ以上のパラメーターキーがイベントペイロードに存在している必要があります。複数のパラメーターキーを指定できます。イベントがチェックを通過するには、全てのパラメーターキーが存在している必要があります。
これに等しい — パラメーターの値が指定した値のいずれかと完全に一致する必要があります。
これと等しい — パラメーターの値が、指定したいずれの値とも一致しない必要があります。
以下を含む — パラメーターの値に、指定した値のいずれかが部分文字列として含まれている必要があります。
以下を含まない — パラメーターの値に、指定した値のいずれも含まれないように指定します。

+ 追加 を選択して、さらにコンディションを追加します。各条件は個別に評価され、イベントのチェックを通過するにはすべての条件を通過する必要があります。

例：トランザクションIDを含むプレミアムまたはゴールドのサブスクリプションの場合にのみイベントを受け入れるには、次のように設定します。

パラメーターキー： subscription_tier — 条件タイプ： これに等しい — パラメーター値： premium、gold
パラメーターキー： transaction_id — 条件タイプ： 存在する

注意:

パラメーター値が空であることを確認するための専用の条件はありません。Adjustでは「値が空」と「値が存在しない」を確実に区別できません。上記のtransaction_id条件のように、パラメーターがペイロードに存在することを確認するには、 存在する を使用します。

注意:

パラメーターキー名にはダブルアンダースコア（__）を含めることはできません。

パラメーターキーの照合では大文字と小文字が区別されます。Subscription_Tierとsubscription_tierは異なるキーとして扱われます。パラメーター値の照合では大文字と小文字が区別されません。subscription_tierの値がPremiumであっても、上記のpremium条件と一致します。

カスタムコールバックパラメーターの追加

注意:

個々のイベントインスタンスではなく、インストールとインストール後のアクティビティのパラメーターをチェックしたい場合は、パラメータールールタイプを使用してください。

*** ** * ** ***

収益確認

このチェックを使用すると、収益化されたイベントの完全性と購入認証を検証できます。
購入認証 の結果に基づいて、チェックが合格または不合格になります。
トグルを有効化すると、トランザクションデータのないイベントも拒否されます。

収益チェックの設定

購入認証の設定は、 AppView → プロテクション（Protection） → 購入認証（Purchase verification） で管理されます。
収益チェックフローで購入認証の結果を使用するには、まず レガシーモード（Legacy mode） から イベントモード（Event mode） に切り替える必要があります。

イベントルールに購入認証が設定されていない

購入認証の設定例

アプリの購入認証を設定

*** ** * ** ***

データ共有

拒否されたイベントは以下のようにレポートされます。

拒否されたイベント のトリガーが設定された場合の コールバック と CSVエクスポート 。 {rejection_reason} プレースホルダーは、チェックごとに粒度の高い値と共にレポートされます。
- post_install_activity_event_rule_source_check
- post_install_activity_event_rule_flow_check
- post_install_activity_event_rule_pv_status_check
レポートにおける 拒否されたイベント と 拒否されたイベントの評価 指標、および 拒否理由の内訳 ：
- rejected_events_post_install_activity_event_rule_source_check（イベントルールのソースチェック）
- rejected_events_post_install_activity_event_rule_flow_check（イベントルールのフローチェック）
- rejected_events_post_install_activity_event_rule_pv_status_check（イベントルールのPVステータスチェック）
- rejected_events_post_install_activity_rule（インストール後のアクティビティフィルター） — 後方互換性のために保持

テストモードの結果

テスト（Test） ステータスのルールは、ルールが失敗してもイベントを拒否しません。拒否された結果は顧客のみに共有されます。パートナーには転送されません。

テスト結果と公開結果を区別するには、コールバックまたはCSVエクスポート設定に{conversion_rule_status}プレースホルダーを追加してください。プレースホルダーは、ルールがテスト状態の場合はtest、ルールが公開状態の場合はliveを返します。

*** ** * ** ***