イベントルールの設定

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

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

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

事前準備

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

要件​

イベントルールの設定

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

  1. AppViewで イベントとサブスクリプション（Events & subscriptions）​ を開き、検証したいイベントを選択します。

  2. イベント編集（Edit event）​ を選択します。

  3. 設定するチェックに移動します。

  4. 次のステータスオプションから1つ選択します。

    • ライブ（Live）​ - ルールが保存されると、Adjustシステムでチェックが有効になります。チェックを満たしていないイベントは 拒否​ されます。
    • テスト（Test）​ - ルールが保存されると、Adjustシステムでのチェックが有効になります。チェックを満たさないイベントは 拒否されません​ が、フラグが付けられ、レポートされます。
    • 一時停止（Pause）​ - ルールはどのイベントにも適用されていません。このステータスを使用して、変更を有効化せずに保存します。

  5. 1つ以上の チェック​ を設定します（チェックを参照）。

  6. 変更を保存（Save changes）​ を選択します。

注意:

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

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

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

***​ ** * **​ ***​

チェック

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

ターゲットフィルター

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

チャネル

チェックを特定のトラフィックチャネルのみに制限します。デフォルトでは、チェックは全てのチャネルに適用されます。

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

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

注意:

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

***​ ** * **​ ***​

ソース確認

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

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

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

  • SDK​ - SDK発信のイベントのみを受け入れます。
  • S2S​ - サーバー間イベントのみを受け入れます。

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

ヒント:

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

非推奨イベント

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

***​ ** * **​ ***​

フロー確認

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

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

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

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

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

重要:

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

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

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

注意:

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

重要:

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

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

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

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

特定のSDKパラメーター（user_id、transaction_idなど）がイベントのペイロードに存在している必要があります。複数のパラメーターを指定できます。複数のパラメーターを定義する場合、イベントに全てのパラメーターが存在しないとチェックを通過できません。

関連記事:

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

注意:

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

***​ ** * **​ ***​

収益確認

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

収益チェックの設定

購入認証の設定は、 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を返します。

***​ ** * **​ ***​