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.
Si deseas habilitar Conversion Rules (y las reglas de eventos) en tu cuenta, envía un correo electrónico a sales@adjust.com.
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.
En AppView, abre Eventos y suscripciones y selecciona el evento que desees validar.
Selecciona Editar evento.
Dirígete a la revisión que desees configurar.
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.
Configura una o más revisiones (consulta la sección sobre Revisiones).
Selecciona Save changes (Guardar cambios).
También puedes configurar las revisiones de las reglas de eventos durante el proceso inicial de creación de eventos.
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.
Nivel de campaña
De forma predeterminada, la comprobación se aplica a todos los canales. Elija a qué nivel de la estructura de la campaña desea definir el alcance de la comprobación:
- Channels — Limite la comprobación a uno o más channels.
- Campañas — Limita el alcance de la verificación a un canal y, luego, a una o más campañas dentro de este.
- Grupos de anuncios — Limite la comprobación a un canal y una campaña, y luego a uno o más grupos de anuncios (ID de origen) dentro de ella.
Solo el campo que coincide con el nivel de Campaign seleccionado admite varias selecciones —por ejemplo, en el modo Adgroups elige un solo channel, un solo campaign y uno o más adgroups. Los campos por encima de ese nivel (Channel y Channel + Campaign) son de selección única y solo existen para reducir el alcance al nivel que eligió.
Una selección solo surte efecto en el nivel en el que elijas un valor específico. Si dejas el campo para el nivel elegido en All o sin seleccionar —por ejemplo, si eliges Adgroups pero no seleccionas una campaign—, la configuración se restablece, al guardar, al nivel más cercano donde realmente se haya seleccionado un valor específico (por ejemplo, Adgroups → Campaigns, o Adgroups/Campaigns → Channels, si nunca se seleccionó nada).
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.
La versión de instalación de la app se refiere a la versión en el momento de la instalación, no a la versión actual de la app. Un usuario que actualiza tras la instalación conserva su versión original para fines de evaluación de reglas.
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 su aplicación tiene habilitada la Lista permitida S2S , se aplica a todos los eventos de forma predeterminada. Puede deshabilitarla para eventos específicos y excluirlos de la verificación de IP; por ejemplo, si los eventos provenientes de servidores de socios de confianza solo necesitan autenticación mediante tokens, mientras que los eventos de flujos internos o confidenciales deben mantener la restricción adicional de IP.
Si un evento proviene de un origen no permitido, se rechaza.
Para los eventos originados en el SDK, revisa tu integración con la firma de SDK y tu configuración a fin de garantizar una protección óptima.
Para los eventos originados de servidor a servidor, revisa tu configuración de seguridad S2S.
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.
La condición Evento precedente requerido únicamente funciona para los eventos enviados desde el SDK .
No configures esta revisión para los eventos enviados de servidor a servidor (S2S) , ya que no se evaluará correctamente.
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ó".
Los eventos que ya están vinculados a una regla de exclusión mutua existente se marcan como Ya conectados en el menú desplegable.
Al definir esta condición, se crea automáticamente una regla simétrica sobre el evento especificado con el mismo estado de regla, visible en la interfaz de usuario.
Si utiliza filtros de objetivo , asegúrese de que estén alineados en ambos eventos para evitar un comportamiento de rechazo inconsistente.
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
Verifique los parámetros del SDK del evento con respecto a una o más condiciones —por ejemplo, requerir que exista una clave o que su valor coincida con valores específicos, los contenga o los excluya.
Para cada condición, elige un tipo de condición :
- Existe — Requiere que una o más claves de parámetro estén presentes en la carga útil del evento, independientemente del valor. Puede proporcionar varias claves de parámetro; todas deben estar presentes para que el evento pase la revisión.
- es igual a — Requiere que el valor del parámetro coincida exactamente con uno de los valores que proporcione.
- no es igual a — Requiere que el valor del parámetro no coincida con ninguno de los valores que proporcione.
- contains — Requiere que el valor del parámetro contenga uno de los valores que proporcione, como subcadena.
- no contiene — Requiere que el valor del parámetro no contenga ninguno de los valores que proporcione.
Selecciona + Agregar para agregar más condiciones. Cada condición se evalúa de manera independiente y todas se deben cumplir para que el evento pase la revisión.
Ejemplo: para aceptar el evento solo si es una suscripción premium o gold que incluye un ID de transacción, configure:
- Clave de parámetro:
subscription_tier— Tipo de condición: es igual a — Valor de parámetro:premium,gold - Clave del parámetro:
transaction_id— Tipo de condición: Existe
No hay una condición específica para comprobar que el valor de un parámetro esté vacío; Adjust no puede distinguir de forma fiable entre "el valor está vacío" y "falta el valor". Use Existe para comprobar que un parámetro esté presente en la carga útil, como en la condición transaction_id anterior.
Los nombres de las claves de parámetro no pueden contener un doble guión bajo (__).
Las claves de los parámetros se emparejan con distinción entre mayúsculas y minúsculas — Subscription_Tier y subscription_tier se tratan como claves diferentes. Los valores de los parámetros se emparejan sin distinción entre mayúsculas y minúsculas —un valor subscription_tier de Premium sigue coincidiendo con la condición premium anterior.
Si deseas revisar los parámetros para las instalaciones y las actividades posteriores a la instalación (y no para las instancias de eventos individuales), utiliza el tipo de regla de Parámetro en su lugar.
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_checkpost_install_activity_event_rule_flow_checkpost_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.