Funcionalidad del Jugador - Canal de Salida Más Rentable

Una mirada en profundidad al Canal de Salida Más Rentable, una Funcionalidad del Jugador del sistema: cómo se puede usar, el objetivo de usarla y la lógica de cómo se ha configurado.

Most Cost-Efficient Outbound Channel es un sistema Funcionalidad del Jugador.
✅ Esto significa que ha sido creado por FT y está disponible para usar como parte del Singularity Model.
🧠 Ten en cuenta que las Funcionalidades del Jugador del sistema no se pueden editar ni eliminar. Si quieres hacer cambios, debes crear tu propia versión de la Funcionalidad del Jugador.

⚙️ Tipo de Funcionalidad

Todas las Funcionalidades del Jugador deben estar conectadas a un Tipo de Funcionalidad. Piensa en los Tipos de Funcionalidad como los ajustes que definen el lenguaje que usamos para hablar sobre piezas importantes de información. La Funcionalidad del Jugador usa estos ajustes y los relaciona con un jugador.
La Funcionalidad del Jugador: Canal de Salida Más Rentable se crea en base al Tipo de Funcionalidad: Outbound Channels.
La clases y slugs que son requeridos por la Funcionalidad del Jugador, se crean y definen en el Tipo de Funcionalidad.
📚 Lectura adicional:
​Tipos de Funcionalidad​
​Configuración de Funcionalidades del Jugador​
​Movimientos​

🚀 Objetivo

El objetivo de la Canal de Salida Más Rentable La Funcionalidad del Jugador consiste en poder dirigirse a los jugadores con su canal de comunicación preferido para una conversión óptima al mismo tiempo que se minimizan los costes. Priorizar Email o SMS según la preferencia del jugador.
Tiene en cuenta los consentimientos del jugador para los diferentes canales, además de asegurar que se alcanza la entregabilidad mientras se prioriza el coste más bajo.

Resultados posibles (Clases)

Los resultados posibles (Clases del Tipo de Funcionalidad) a los que un jugador puede pertenecer son:
  1. Correo Electrónico
  2. SMS
Valor Predeterminado
Por defecto, los jugadores serán asignados a la clase Email.
Esto significa que si no hay suficientes datos disponibles el jugador será asignado a la clase Email.
Veamos más de cerca cómo se calculan estas clases y cómo los jugadores pueden calificar para pertenecer a una determinada clase 👇

↔ Movimientos

Los movimientos definen la forma en que los jugadores pueden moverse de un estado a otro.
Pueden ser movimientos en tiempo real, que ocurren cuando se produce una acción en tiempo real (como un pago o un registro), o una consulta basada en tiempo. Las consultas basadas en tiempo ocurren a una hora establecida del día y evalúan la base de jugadores para determinar si un jugador debe cambiar de clase.
​
📚 Leer más:
​Movimientos​
​Movimientos en Tiempo Real​
​Consultas Basadas en Tiempo ​
Para Canal de Salida Más Rentable, hay un Proceso Activo, o movimiento, que se ha configurado para gestionar los movimientos de los jugadores entre estados:
Procesos Activos
Procesos Activos

Evaluar Canal Más Rentable

  1. Este movimiento es una Consulta Basada en Tiempo que está configurada para ejecutarse a una hora establecida de 'Todos los días a las 03:00 UTC'.
  2. El objetivo de la consulta es encontrar el canal más coste-efectivo. Normalmente será Email.
    1. En primer lugar, la consulta comprobará consentimiento del jugador y solo considerará los canales con opt-in.
    2. Si ambos canales tienen opt-in, se priorizará Email a menos que las tasas de entregabilidad de SMS sean más de 5 veces mejores que Email.
  3. Como regla general, se seleccionará Email a menos que el jugador esté en opt-out o si las tasas de entregabilidad de Email son bajas; en ese caso se enviará un SMS.
  4. Por defecto, los Jugadores serán asignados a la clase Email.
  5. Los jugadores bloqueados y excluidos también están incluidos.
🤔 ¿Por qué un factor de 5 al evaluar la entregabilidad?
Usamos el factor de 5 para asegurarnos de que hay una tasa de entregabilidad significativamente mejorada.
Si tanto SMS como Email tienen bajas tasas de entregabilidad para un jugador, no querríamos gastar dinero enviando un SMS que probablemente no se entregue en primer lugar. En ese caso, tendría más sentido enviar un Email, que no contribuye a costes adicionales.
Evaluar Canal de Salida
Evaluar Canal de Salida

🧠 Consultas

La mayoría de las Funcionalidades del Jugador en el Singularity Model hacen uso de consultas basadas en tiempo. Las consultas son buenas para determinar estados de inactividad del jugador, algo que un movimiento en tiempo real no puede determinar.
Nuestras consultas se crean usando ClickHouse y están incluidas en el Singularity Model para que las uses.
🧠 Ten en cuenta que el slug desde el Tipo de Funcionalidad clase debe coincidir dentro de la consulta.
Si quieres escribir tus propias consultas, puedes usar el Editor de Consultas o pedir ayuda a Fast Track. Puedes encontrar el editor de consultas en: menú Insights & Analytics - Data Studio - Query Editor.
Evaluar computación de canal de salida
Evaluar computación de canal de salida

🏁 ¿Qué sigue?

Dashboards

Después de algún tiempo, una vez que los Disparadores de cálculo se hayan activado, podrás ver que los jugadores han sido asignados a una de las clases de la Funcionalidad del Jugador. Puedes ver esto en el panel de Distribución de Jugadores dentro de la Funcionalidad del Jugador:
Distribución de jugadores
Distribución de jugadores

Segmentación

A continuación, puedes usar Canal de Salida Más Rentable al crear segmentos para Actividades y LifeCycles. Podrás encontrar Canal de Salida Más Rentable entre los campos de segmentación cuando estás creando un Segmento.
Campo de Segmento
Campo de Segmento

Usar dentro de una Actividad

Cualquier Funcionalidad del Jugador que se haya configurado usando el Tipo de Funcionalidad Canal de Salida, puede seleccionarse desde dentro de una Actividad o LifeCycle para determinar qué canal se enviará a cada jugador.
🚀 Aprende cómo:
Continuar leyendo aquí para aprender cómo usar la Canal de Salida Más Rentable funcionalidad del jugador desde dentro de una Actividad.