Configurer des règles d'événement

Les règles d'événement renforcent les règles de conversion afin de valider les événements de post-installation sur la base de conditions personnalisées que vous définissez.
Lorsqu'un événement ne remplit pas ces conditions, Adjust le rejette et signale le rejet dans les callbacks, les exports CSV et les rapports.

Avant de commencer

Voici ce que vous devez savoir avant de commencer.

Prérequis

• Utilisateurs avec des autorisations Administrateur, Éditeur ou Éditeur personnalisé dans Adjust.
• Une application monoplateforme ou multiplateforme dans Adjust.

Configurer une règle d'événement

Pour configurer une règle d'événement, procédez comme suit :

1. Dans AppView, ouvrez Événements et abonnements et sélectionnez l'événement que vous souhaitez valider.

2. Sélectionnez Modifier l'événement .

3. Accédez au contrôle que vous souhaitez configurer.

4. Choisissez l'un des statuts suivants :

   • Live - Lorsque la règle est enregistrée, le contrôle devient actif dans le système Adjust. Les événements qui ne satisfont pas au contrôle sont rejetés .
   • Test - Lorsque la règle est enregistrée, le contrôle devient actif dans le système Adjust. Les événements qui ne satisfont pas au contrôle ne sont pas rejetés , mais sont signalés et déclarés.
   • Pause - La règle n'est appliquée à aucun événement. Utilisez ce statut pour enregistrer vos modifications sans les activer.

5. Configurez un ou plusieurs contrôles (voir Contrôles).

6. Sélectionnez ENREGISTRER MODIFICATIONS .

Supprimer un contrôle de règle d'événement

Pour supprimer un contrôle, définissez son statut sur Désactivé .

Contrôles

Vous pouvez appliquer plusieurs contrôles à votre règle d'événement.
Si un contrôle avec le statut Live échoue, l'événement est rejeté .

Filtres cibles

Utilisez des filtres de ciblage pour affiner le trafic auquel chaque vérification s'applique. Les filtres sont configurés par vérification et n'affectent pas les autres vérifications de la même règle.

Canaux

Limitez la vérification aux canaux de trafic spécifiques. Par défaut, la vérification s’applique à tous les canaux.

Installer la version de l'application

Limitez la vérification aux utilisateurs ayant installé une version spécifique de l’application. Utilisez cela pour vous assurer que la logique de la règle ne s’applique qu’aux utilisateurs pour lesquels elle est valide et significative — par exemple, les utilisateurs ayant installé une version où tous les événements et flux référencés par la règle faisaient déjà partie de l’application.

Vérification de la source

Utilisez-le pour contrôler quelle source d'événement est acceptée et pour gérer les événements qui ne sont plus actifs dans votre application.

Source d'événement acceptée

Restreint la source d'événement acceptée.

• SDK - Accepte uniquement les événements provenant du SDK.
• S2S - Accepte uniquement les événements serveur à serveur.

Si un événement provient d'une source non autorisée, il est rejeté.

Événement obsolète

Rejetez l'événement s'il a été supprimé de l'application et il n'est plus déclenché. Utilisez-le pour invalider tous les déclencheurs restants pour des événements qui ne font plus partie du flux d'événements de votre application.

Vérification du flux

Utilisez cette option pour contrôler la séquence attendue, le calage temporel et les paramètres requis des événements.
Vous pouvez sélectionner plusieurs conditions. Dans ce cas, toutes les conditions sélectionnées doivent être remplies pour que l'événement réussisse. Si ce n'est pas le cas, l'événement est rejeté.

Délai à partir de l'installation

Requiert que l'événement se produise pendant ou après une période spécifique à partir de l'installation.
Exemple : « 5 minutes ou plus après l'installation. »

Événement précédent requis

Requiert qu'un événement spécifique (par exemple Niveau 1 ) se produise avant cet événement, À titre de contrainte supplémentaire, vous pouvez spécifier une durée minimum ou maximum entre l'événement antérieur requis et l'événement actuel.

L'événement ne peut pas se produire si... - exclusion mutuelle d'événements spécifiques

Rejetez l’événement si un autre événement spécifié a déjà été déclenché pour cet utilisateur. Utilisez-le pour appliquer l'exclusion mutuelle entre deux événements : si l'un s'est produit, l'autre est bloqué.
Exemple : «  l’achat ne peut pas avoir lieu si le remboursement a déjà eu lieu ».

Le dernier déclencheur de l'événement s'est produit au plus tôt avant — suppression de l'événement basée sur le temps

Rejetez l'événement s'il a été déclenché il y a moins d'une durée spécifiée. Utilisez cette option pour limiter la fréquence à laquelle le même événement peut être accepté pour un utilisateur donné.
Exemple : « le dernier déclencheur d' achat s'est produit au moins il y a 5 minutes ».

Paramètres requis

Requiert des paramètres spécifiques du SDK (par exemple, user_id, transaction_id) soient présents dans la charge utile de l'événement. Vous pouvez fournir plusieurs paramètres. Lorsque plusieurs paramètres sont définis, ils doivent tous exister pour que l'événement satisfasse au contrôle.

Vérification des revenus

Utilisez ce contrôle pour valider les événements monétisés afin d'assurer la complétude et la vérification des achats.Le contrôle réussit en fonction du résultat de la vérification des achats .
Activez l'option pour rejeter également les événements avec des données de transaction manquantes.

Configuration du contrôle des revenus

La configuration de la vérification des achats est gérée dans AppView → Protection → Vérification des achats .
Pour utiliser les résultats de la vérification des achats dans la flux de contrôle Revenus, vous devez d'abord passer du mode legacy au mode événement .

• La vérification des achats n'est pas configurée pour les règles d'événement.

• Exemple de configuration de vérification des achats

Partage des données

Les événements rejetés sont déclarés comme :

• Des callbacks et des exports CSV lorsqu'un déclencheur Événement rejeté est configuré. L'espace réservé {rejection_reason} est indiqué avec des valeurs granulaires par vérification :

  • post_install_activity_event_rule_source_check
  • post_install_activity_event_rule_flow_check
  • post_install_activity_event_rule_pv_status_check

• Les événements rejetés et les métriques d'événements rejetés dans les rapports, avec une répartition des raisons du rejet :

  • rejected_events_post_install_activity_event_rule_source_check (Vérification des sources des règles d’événement)
  • rejected_events_post_install_activity_event_rule_flow_check (Contrôle du flux des règles d’événement)
  • rejected_events_post_install_activity_event_rule_pv_status_check (Vérification de l'état PV des règles de l'événement)
  • rejected_events_post_install_activity_rule (Filtres d’activité post-installation) — préservés pour la rétrocompatibilité

Résultats en mode test

Les règles avec le statut Test ne rejettent les événements même si la règle échoue. Les résultats rejetés sont partagés uniquement avec les clients — ils ne sont pas transmis aux partenaires.

Pour distinguer les résultats des tests des résultats réels, ajoutez l'espace réservé {conversion_rule_status} à vos callbacks ou à votre configuration d'exportation CSV. L'espace réservé renvoie test lorsque la règle est en statut de test et live lorsqu'elle est en statut actif.