Cómo configurar reglas de eventos

Las reglas de eventos amplían las capacidades de Conversion Rules para validar los eventos posteriores a la instalación con base en ciertas condiciones personalizadas definidas por ti.
Cuando un evento no cumple con estas condiciones, nuestro sistema lo rechaza y documenta el rechazo en los callbacks, las exportaciones de archivos CSV y los informes.

Antes de comenzar

Esto es lo que debes saber antes de comenzar.

Requisitos

• Usuarios con permisos de administrador, editor o editor personalizado en Adjust.
• Una aplicación de una sola plataforma o multiplataforma en Adjust.

Cómo configurar una regla de evento

Para configurar una regla de evento, sigue estos pasos.

1. En AppView, abre Eventos y suscripciones y selecciona el evento que desees validar.

2. Selecciona Editar evento.

3. Dirígete a la revisión que desees configurar.

4. Elige una de las siguientes opciones de estado:

   • Activa : cuando guardas la regla, esta se activa en nuestro sistema. Los eventos que no cumplen con la revisión se rechazan.
   • Prueba : cuando guardas la regla, esta se activa en nuestro sistema. Los eventos que no cumplen con la revisión no se rechazan , pero se marcan y se agregan a los informes.
   • Pausa : la regla no se aplica a ningún evento. Utiliza este estado para guardar tus cambios sin activar las reglas.

5. Configura una o más revisiones (consulta la sección sobre Revisiones).

6. Selecciona Save changes (Guardar cambios).

Cómo eliminar la revisión de una regla de evento

Para eliminar una revisión, solo tienes que cambiar su estado a Desactivada.

Revisiones

Puedes aplicar varias revisiones a tu regla de evento.
Si cualquier revisión con estado Activa tiene algún error, el evento se rechaza.

Filtros de objetivo

Utilice filtros de destino para reducir el tráfico al que se aplica cada verificación. Los filtros se configuran por comprobación y no afectan a otras comprobaciones en la misma regla.

Canales

Limite la comprobación solo a canales de tráfico específicos. Por defecto, la comprobación se aplica a todos los canales.

Instalar la versión de la aplicación

Limite la comprobación a usuarios que instalaron una versión específica de la app. Empléelo para cerciorarse de que la lógica de la regla solo se aplique a usuarios para quienes sea válida y significativa — por ejemplo, aquellos que instalaron una versión en la que todos los eventos y flujos referenciados por la regla ya formaban parte de la aplicación.

Revisión del origen

Use esto para controlar qué origen de eventos se acepta y para gestionar eventos que ya no estén activos en su app.

Origen aceptado del evento

Restringir el origen de evento que se acepta.

• SDK : aceptar únicamente los eventos originados en el SDK.
• S2S : aceptar únicamente los eventos de servidor a servidor.

Si un evento proviene de un origen no permitido, se rechaza.

Evento obsoleto

Rechace el evento si fue eliminado de la App y ya no se activa. Use esto para invalidar cualquier activador restante de eventos que ya no formen parte del flujo de eventos de tu App.

Revisión del flujo

Utiliza esta opción para controlar la secuencia esperada, los tiempos y los parámetros obligatorios de los eventos.
Puedes seleccionar varias condiciones. En este caso, todas las condiciones seleccionadas se deben cumplir para que el evento pase la revisión. De lo contrario, se rechaza el evento.

Tiempo después de la instalación

Requiere que el evento se presente durante o después de un período específico después de la instalación.
Ejemplo: "Mayor que o igual a 5 minutos después de la instalación".

Evento precedente requerido

Requiere que se complete un evento específico (por ejemplo, Nivel 1 ) antes de este evento. Como condición adicional, puedes especificar una ventana de tiempo mínima o máxima entre el evento precedente requerido y el evento actual.

El evento no puede ocurrir si... - exclusión mutua de eventos específicos

Rechace el evento si ya se activó otro evento especificado para este usuario. Use esto para imponer la exclusión mutua entre dos eventos; si uno ha ocurrido, el otro está bloqueado.
Ejemplo: " compra no puede ocurrir si el reembolso ya ocurrió".

El último disparador del evento ocurrió como mínimo antes — supresión de eventos basada en el tiempo

Rechace el evento si se activó hace menos del tiempo especificado. Use esto para limitar la frecuencia con la que se puede aceptar el mismo evento para un usuario determinado.
Ejemplo: "El último disparo de compra ocurrió al menos hace 5 minutos ".

Parámetros requeridos

Requiere que ciertos parámetros del SDK específicos (por ejemplo, user_id, transaction_id) estén presentes en la carga útil del evento. Puedes proporcionar varios parámetros. Si defines varios parámetros, todos ellos deberán estar presentes para que el evento pase la revisión.

Revisión de los ingresos

Utiliza esta revisión para validar que los eventos monetizados estén completos y que se haya realizado la verificación de compras.
La revisión se completa con resultado positivo o negativo según el resultado de la verificación de compras .
Activa el indicador para rechazar también los eventos en los que falten datos de transacciones.

Configuración de la revisión de ingresos

La configuración de la verificación de compras se administra en AppView → Protección → Verificación de compras .
Para utilizar los resultados de la verificación de compras en el flujo de revisión de ingresos, primero debes cambiar del modo clásico al modo de evento.

• Verificación de compras no configurada para las reglas de eventos

• Ejemplo de configuración de la verificación de compras

Envío de datos

Los eventos rechazados se agregan a los informes de las siguientes maneras:

• Como callbacks y exportaciones de archivos CSV , cuando se configura un activador de Evento rechazado. El placeholder {rejection_reason} se informa con valores granulares por comprobación:

  • post_install_activity_event_rule_source_check
  • post_install_activity_event_rule_flow_check
  • post_install_activity_event_rule_pv_status_check

• Eventos rechazados y métricas de tasa de eventos rechazados en los reportes, con un desglose del motivo del rechazo :

  • rejected_events_post_install_activity_event_rule_source_check (Comprobación del origen de la regla de evento)
  • rejected_events_post_install_activity_event_rule_flow_check (Comprobación de flujo de reglas de eventos)
  • rejected_events_post_install_activity_event_rule_pv_status_check (Comprobación de estado PV de reglas de evento)
  • rejected_events_post_install_activity_rule (Filtros de actividad posterior a la instalación) — preservados para compatibilidad hacia atrás

Resultados en modo de prueba

Las reglas presentes en el estado Prueba no rechazan los eventos, incluso si no se cumple la regla. Los resultados rechazados se comparten únicamente con los clientes; no se reenvían a los socios.

Para distinguir los resultados de prueba de los resultados en vivo, agregue el placeholder {conversion_rule_status} a su configuración de callbacks o exportación CSV. El placeholder devuelve test cuando la regla está en estado de prueba y live cuando la regla está en estado activo.