Una estrategia promocional con aprendizaje automático

Implementación de una estrategia promocional rentable para Starbucks con aprendizaje automático (Parte 1)

En esta serie, diseñaremos una estrategia promocional para Starbucks y recorreremos todo el proceso desde el preprocesamiento de datos hasta el modelado. Esta es mi solución para el proyecto Udacity Data Scientist Nanodegree Capstone.

En la primera parte de la serie, cubriremos la introducción del proyecto, la descripción de los conjuntos de datos, los tipos de promociones disponibles, la imputación de valores perdidos, la pre- procesamiento y análisis de datos exploratorios.

Enlace a la parte 2 de este artículo.

El código que acompaña a este artículo se puede encontrar aquí .

I. Introducción

En esta serie de artículos, exploraremos datos de la aplicación móvil de Starbucks rewards y emplearemos el aprendizaje automático para diseñar una estrategia promocional. También analizaremos todo el flujo de trabajo de preprocesamiento de datos e idearemos una métrica para probar nuestra estrategia promocional.

La pregunta que nos gustaría responder al final de este artículo será:

¿Podemos ¿Aumentar las ganancias de Starbucks adoptando una estrategia promocional más selectiva?

Como parte del proyecto Nanacegree Capstone de Udacity Data Scientists, Starbucks ha proporcionado amablemente un conjunto de datos simulados que imita el comportamiento del cliente en su aplicación móvil de recompensas. El conjunto de datos también se puede encontrar en mi GitHub repositorio.

Aquí está la situación: una vez cada pocos días, Starbucks enviará promociones a los clientes en la aplicación móvil. Estas pueden ser ofertas de descuento, comprar uno-obtener-uno-gratis (BOGO) u ofertas informativas.

A menudo hay un costo asociado con la promoción. En nuestro caso, una promoción de compra-uno-obtener-uno-gratis o de descuento puede resultar en “ganancias perdidas” para la empresa, ya que la empresa está sacrificando algunas ganancias para otorgar a los clientes incentivos monetarios (producto gratuito o descuento). 19659011] Si los clientes ya están dispuestos a comprar productos de Starbucks sin recibir ninguna promoción, entonces debemos abstenernos de otorgar a este grupo de clientes cualquier promoción.

Además, existe un grupo de personas conocido como “perro durmiente” . Los “perros durmientes” son personas que compran su producto, pero dejarán de hacerlo si están incluidos en su campaña de marketing.

Por lo tanto, no es una estrategia comercial sólida para enviar promociones a cada persona. Idealmente, desearemos enviar las promociones a las personas que estén inclinadas a realizar compras solo cuando se les presenten ofertas, y también queremos evitar enviarlas a “perros durmientes”.

Nuestro objetivo será formular una promoción estrategia que puede identificar a las personas a las que debemos enviar promociones con el objetivo de maximizar los beneficios para la empresa.

Para ayudarnos a abordar este problema, utilizaremos modelos de mejora. Los modelos de Uplift nos permiten modelar el impacto incremental de un tratamiento (esta será la promoción en nuestro caso) en el comportamiento de compra de un cliente.

Si está interesado en obtener más información sobre los modelos de uplift, consulte este artículo .

Si bien los modelos de elevación pueden ser realmente beneficiosos, a veces pueden ser difíciles de implementar. En particular, el mayor desafío es encontrar el método óptimo para modelar el impacto incremental de la promoción en la respuesta del individuo.

No obstante, estos modelos nos ofrecen la mejor oportunidad de mejorar la efectividad de las promociones. Por lo tanto, vamos a intentarlo!

II. Conjunto de datos

Hay 3 archivos de datos proporcionados por Starbucks para este proyecto. Los archivos de datos y su esquema se enumeran a continuación:

portfolio.json

1. id (string) – offer id
2. offer_type (string) – tipo de oferta, es decir, BOGO, descuento, informativo
3. dificultad (int) – mínimo requerido de gasto para completar una oferta
4. recompensa (int) – recompensa otorgada por completar una oferta
5. duración (int) – el período de validez de los canales de la oferta
6. (lista de cadenas) – el medio a través de la cual se envió la oferta

El conjunto de datos de la cartera contiene información sobre 10 variedades de promociones que están disponibles a través de la aplicación.

Existen 3 familias principales de promociones disponibles: informativas, de descuento y de compra de uno en uno – ofertas gratuitas (BOGO).

En el conjunto de datos, el término tipo de oferta se usó para referirse a un paraguas de promociones similares. Por ejemplo, podría referirse a la familia de promociones de descuento.

Me parece confuso este término, por lo que me referiré al paraguas de promociones similares simplemente como el tipo de oferta familiar. Usaré el término tipo de oferta o tipo de promoción para referirme a cada una de las 10 variedades de promoción.

Las ofertas informativas no tienen recompensas monetarias adjuntas. Estas promociones son principalmente anuncios de bebidas.

Las ofertas de descuento generalmente brindan una pequeña cantidad de recompensa monetaria, siempre que el cliente gaste una cierta cantidad de dinero durante la duración de la oferta.

La cantidad necesaria para desbloquear el la recompensa se considerará como la dificultad de la oferta.

Los BOGO son similares a las ofertas de descuento, excepto que ofrecen recompensas monetarias equivalentes a las dificultades de las ofertas.

Los detalles de la oferta se pueden ver a continuación:

Tenga en cuenta que recodifiqué el ID de oferta original de sus valores hash originales a números enteros (0–9) para simplificar el proceso de trabajo.

profile.json

1. age (int) – edad del cliente
2. se convirtió en miembro_miembro (int) – datos cuando el cliente creó una cuenta de aplicación
3. género (str) – género del cliente
4. id (str) – identificación del cliente
5. ingreso (flotante) – ingresos del cliente

El conjunto de datos del perfil contiene información demográfica sobre los clientes.

Hay solo 4 atributos demográficos con los que podemos trabajar: edad, ingresos, género y fecha de inicio de la membresía. Una parte del conjunto de datos del perfil tiene valores faltantes y se tratarán más adelante en este artículo.

transcript.json

1. evento (str): descripción del registro (es decir, transacción, oferta recibida, oferta vista, etc.) [19659028] person (str) – id de cliente
2. tiempo (int) – tiempo en horas. Los datos comienzan en el tiempo t = 0
3. valor (dict de cadenas) – ya sea un id de oferta o un monto de transacción según el registro.

El conjunto de datos de la transcripción registra las marcas de tiempo de las compras realizado en la aplicación, así como las marcas de tiempo de cuándo se recibieron, vieron o completaron las ofertas.

Hay un par de detalles sobre el conjunto de datos que se deben resaltar antes de continuar.

1. Los clientes no necesitan gastar todo el dinero en una sola transacción para activar la oferta. Siempre que alcancen el monto requerido dentro de la duración de la oferta, recibirán las recompensas de la oferta independientemente del número de transacciones que realicen.
2. Las ofertas se pueden registrar como completadas incluso si el usuario no vio el ofrezca, pero gaste la cantidad requerida de dinero.
3. Las ofertas también se pueden registrar como completadas incluso después de que la oferta haya caducado. Por ejemplo, consideremos una oferta que está expirando en el momento 7. Si el cliente gasta la cantidad de dinero requerida en un momento posterior, quizás el tiempo 20, la oferta aún se registrará como completada. En realidad, esta oferta no está “completada” y el cliente no disfrutará de las recompensas de la promoción. Por lo tanto, debemos tener en cuenta esta situación al trabajar con los datos.
4. No hubo un número de serie único asignado a cada oferta, persona y combinación de tiempo. Esto puede causar confusión con respecto a la interpretación del conjunto de datos de la transcripción. Por ejemplo, un cliente podría recibir un descuento de BOGO de $ 10 en el momento 7 y otra oferta idéntica en el momento 31. La aplicación podría registrar una finalización de la oferta en el momento 52. Sin embargo, no sabríamos cuál es la oferta relevante que se completó en tiempo 52 debido a la emisión número 3.

Estas peculiaridades significaban que recuperar los resultados exactos de cada oferta podría ser imposible, aunque deberíamos poder recuperar la mayor parte.

III. Ofertas disponibles

Estas son las ofertas disponibles a través de la aplicación:

Número de identificación de la oferta: Oferta Tipo de familia, Validez, Dificultad, Recompensa

1. Oferta de la oferta 0: Descuento 10/20/5
2. Id. De oferta 1: Descuento 7/7/3
3. Id. De oferta 2: Descuento 7/10/2
4. Id. De oferta 3: Informativo 4/0/0
5. Id. De oferta 4 : BOGO 5/10/10
6. Id. De oferta 5: Informativo 3/0/0
7. Id. De oferta 6: BOGO 7/5/5
8. Id. De oferta 7: BOGO 7/10/10
9. Oferta id 8: BOGO 5/5/5
10. Id. de oferta 9: Descuento 10/10/2

Usaré el mismo sistema de referencia de ofertas en todo el artículo.

Nota: Usaré Id. de oferta 10 para representar Situaciones sin oferta. Esto se aclarará en un momento.

IV. Predicción de valores perdidos

Aproximadamente el 12.8% del conjunto de datos del perfil contiene valores perdidos tanto para el género como para el ingreso. Casualmente, a los individuos les faltan datos sobre la edad y los ingresos, o no les falta ninguno. Además, todos los individuos con información de género e ingresos faltantes comparten edades idénticas de 118.

Es probable que estos individuos no tengan 118 años en realidad.

La explicación plausible es que 118 es la edad de entrada predeterminada de la aplicación cuando se trata de datos demográficos faltantes.

Dado que la edad, los ingresos y el género son los únicos datos demográficos disponibles (aparte de la membresía fecha de inicio), es importante abordar estos datos faltantes.

Una solución será eliminar a las personas con datos faltantes. Sin embargo, eso también significará perder una parte significativa de los datos.

Debido al tamaño del grupo, es probable que estos individuos tengan atributos demográficos diversos. Por lo tanto, decidí usar un enfoque basado en el aprendizaje automático para predecir los valores faltantes, en lugar de imputar los valores faltantes con un solo valor, como media.

Ingeniería de características

Dado que la fecha de inicio de la membresía es la única información demográfica para nuestros modelos de aprendizaje automático, mi esperanza es que existan diferencias en el comportamiento transaccional entre personas de diferentes géneros, niveles de ingresos y grupos de edad.

Las estadísticas de los comportamientos de las transacciones se agregarían de forma individual. Para cada individuo, sigo la pista de:

1. número de ofertas recibidas
2. número de ofertas completadas con éxito
3. número de ofertas que se probaron pero no se completaron
4. porcentaje de ofertas completadas con éxito
5. porcentaje de ofertas intentado
6. gasto total en oferta
7. número total de transacciones realizadas para ofertas
8. gasto medio por transacción en ofertas

Estas cifras se acumularon de forma acumulativa (todas las ofertas más ninguna oferta), cada tipo de oferta ( id 0–9 más id 10 que representa ninguna oferta) y cada tipo de familia de ofertas (BOGO, descuento, informativo).

Nota: Las definiciones para ofertas exitosas / probadas se pueden encontrar en la subsección Definir exitosa / Probada / Ofertas fallidas en la Sección V. Preprocesamiento de datos: Generación de datos mensuales

También se calcularon ratios adicionales, tales como:

1. índice de gasto para el tipo de oferta y tipo de familia de la oferta sobre el gasto total
2. Número de transacciones para el tipo de oferta y el tipo de familia de oferta sobre el número total de transacciones
3. relación del número de tipo de oferta y el tipo de familia de oferta recibido sobre el número total de ofertas recibidas

Debido al número considerable de características creadas, me abstendré de enumerarlos todos en este artículo. Para obtener más detalles, consulte el código en el archivo input_missing_data.ipynb en mi GitHub repositorio.

Cualquier valor nulo se reemplazaría con 0, ya que los valores nulos generalmente indican que no Las ofertas fueron recibidas / vistas / completadas o no se realizaron gastos.

Para diferenciar entre la situación de 1) recibir una oferta y no responderla y 2) no recibir ninguna oferta, el número de ofertas recibidas por se realizó un seguimiento de cada individuo.

Las características de entrada para los modelos serían las características de nueva ingeniería y la fecha de inicio de la membresía.

Debido al alto grado de escasez en las características, en gran parte debido a las bajas tasas de finalización y los bajos gastos para Se realizaron reducciones de dimensionalidad para estas características de entrada.

Para evitar que las características con valores más grandes dominen a otras, se realizó la normalización de las características. Se usó la escala estándar para reducir estas características a una media de 0 y una desviación estándar de 1.

Modelos

Se crearon 3 modelos separados, un modelo para cada uno de los atributos faltantes: edad, ingreso y género. La parte del conjunto de datos del perfil sin valores perdidos se usaría para capacitar a los modelos (aproximadamente el 87.2% de los datos del perfil).

Tanto los modelos de edad como de ingresos son problemas de regresión, mientras que el modelo de género es un problema de clasificación de múltiples clases. . La validación cruzada K-Fold con 5 pliegues se usó en el proceso de búsqueda de cuadrícula para optimizar los modelos.

XGBRegressor y XGBClassifier son los modelos elegidos para las tareas de regresión y clasificación, respectivamente. Estos son modelos no lineales basados ​​en árboles que son relativamente rápidos y precisos.

El único inconveniente importante de estos modelos es que no extraen de manera innata las interacciones de características.

Por ejemplo, si nuestros conjuntos de datos solo registran el gasto total para cada tipo de oferta (por ejemplo, $ 10 para BOGO 5/5/5, $ 30 para BOGO 7/10/10, etc.), pero no para cada tipo de familia (por ejemplo, $ 40 para todas las ofertas de BOGO), el modelo XGBoost tomará decisiones basadas en el modelado Solo en gastos por cada tipo de oferta. No puede extraer ninguna información con respecto al gasto total para la clase de ofertas BOGO y usar esta información en el proceso de modelado.

Por lo tanto, tendremos que diseñar manualmente estas interacciones de características si queremos que nuestros modelos las aprovechen. .

Métricas

El Error cuadrático medio (RMSE) se seleccionó como la métrica de optimización para los modelos de edad e ingreso, ya que quería priorizar las precisiones de las predicciones.

Tenga en cuenta que minimizar el RMSE es lo mismo que minimizar la cuadratura media. Error (MSE), ya que RMSE es la raíz cuadrada (transformación lineal) de MSE.

RMSE se calcula como tal:

Por otro lado, el puntaje de micro-promedio F1 se usó como la métrica de optimización para el modelo de género. El micro-promedio del puntaje F1 se calculará de la siguiente manera:

donde

• TP – Verdaderos Positivos. Número de muestras que se predice que pertenecen al género g y que en realidad pertenecen al género g .
• FP – Falsos positivos. Número de muestras que se predice que pertenecen al género g pero no pertenecen al género g en realidad.
• TN – Verdaderos negativos. Número de muestras que se predice que no pertenecen al género g y en realidad no pertenecen al género g .
• FN – Falsos negativos. Número de muestras que se predice que no pertenecen al género g pero en realidad pertenecen al género g .

F, M, O representa la ‘hembra’, ‘macho’ y ‘otra

Resultados

El modelo para predecir la edad de un individuo alcanzó un RMSE de aproximadamente 16.5, mientras que el modelo para predecir los ingresos del individuo logró un RMSE de aproximadamente 13.500. Estas cifras significaron que, en promedio, las predicciones de edad se redujeron en 16,5 años, mientras que las predicciones de ingresos se redujeron en $ 13,500.

Por otra parte, se registró una puntuación de F1 de 0.6 en el conjunto de pruebas para el modelo de predicción de género (1 es la puntuación para el mejor modelo posible). Una observación interesante fue que los valores pronosticados para el género parecen estar dominados por el género masculino. Si el tiempo lo permite, se podrían llevar a cabo investigaciones adicionales para investigar por qué este era el caso.

Estas métricas modelo estaban lejos de ser ideales. Sin embargo, considerando la cantidad limitada de información disponible, estos resultados fueron aceptables. No obstante, estos números imputados deberían servirnos mejor que el enfoque alternativo de llenar los valores faltantes con números constantes.

V. Preprocesamiento de datos: Generación de datos mensuales

Para transformar los conjuntos de datos en algo útil, tendremos que realizar una cantidad sustancial de limpieza y preprocesamiento de datos.

Al final de esta sección, generaremos un conjunto de datos que se parece a esto:

La tarea principal será identificar a las personas que probablemente gastarán más dinero al recibir ofertas en comparación con no recibirlas. Por lo tanto, necesitamos un conjunto de datos que refleje cómo responden los usuarios en situaciones tanto promocionales como no promocionales.

También nos interesa si los cambios en los comportamientos de los clientes pueden ocurrir con el tiempo.

Por lo tanto, he elegido agregar clientes ” respuesta sobre una base mensual. Como no tenemos fechas reales, estimaré que un mes será de 30 días y trataré el día 0 como el comienzo del mes 0.

De la instantánea de arriba, sabemos que “id. De persona ‘recibió una promoción” Id de oferta 2 ‘en el mes 0. La persona no gastó dinero en esa oferta durante el mes. Del mismo modo, ‘persona id 2’ no gastó dinero en situaciones no promocionales.

Tenga en cuenta que usaré ‘oferta id 10’ para representar gastos no promocionales por simplicidad.

Todos los meses, el conjunto de datos debe seguimiento:

1. Cuánto gastaron los clientes durante la validez de las ofertas si recibieron ofertas. Esta cifra podría ser 0 si no gastaran dinero.
2. Cuánto gastaron los clientes durante los períodos de tiempo en que no hubo oferta. Esta cifra también podría ser 0 si no gastaran dinero.

Los cheques de transacciones individuales seleccionadas al azar sugieren que los clientes generalmente no recibieron más de 1 oferta al mes. Por lo tanto, los clientes estuvieron expuestos a más días no promocionales en comparación con los días promocionales de cada mes.

Se prefería agregar datos mensualmente sobre una base diaria / semanal, ya que la mayoría de los clientes recibían una oferta una vez cada pocos meses. Si los datos se agregaran diariamente / semanalmente, habría demasiados días / semanas sin exposición a ninguna promoción.

Ahora analizaré el proceso de generación del conjunto de datos mensual. Es una larga discusión y es mejor seguirla con el código. Por lo tanto, si desea omitir esta sección, siéntase libre de continuar leyendo en la sección “VI. Análisis de datos exploratorios ‘cerca del final de esta página.

Defina ofertas exitosas / intentadas / fallidas

Antes de poder rastrear cuánto dinero gastaron los clientes durante la validez de las promociones, debemos clasificar las ofertas según sus posibles resultados . Hay 3 posibilidades: exitoso, probado y fracasado.

Para que una oferta se clasifique como exitosa, debe recibirse, verse y completarse antes de que caduque la oferta. Esto significaba que el cliente estaba al tanto de una promoción y estaba realizando transacciones como resultado.

Si el cliente completaba la oferta antes de verla, la oferta no se clasificaría como exitosa, ya que la oferta no influyó en el cliente cuando haciendo transacciones.

En el caso de que un cliente hiciera algunas transacciones antes de ver la oferta, pero no gastara lo suficiente para completar la oferta. Si él / ella vio la oferta mientras aún era válida, y gastó más dinero para completarla antes de que expirara, la oferta también se clasificaría como exitosa.

Por lo tanto, el flujo de eventos para una oferta exitosa es: [19659127] oferta recibida -> opcional: transacciones realizadas -> oferta vista -> transacciones realizadas -> oferta completada -> oferta caducada

Una oferta probada es aquella que un cliente vio, gastó algo de dinero antes de La oferta expiró pero no la completó. Por lo tanto, el cliente no gastó el dinero suficiente para completar el requisito de la oferta.

Dado que la oferta informativa no tiene un evento de finalización de la oferta, se tratará como una oferta probada si el cliente vio la oferta y gastó algo de dinero durante su validez.

El flujo de eventos para una oferta probada es:

• oferta recibida -> opcional: transacciones realizadas -> oferta vista -> transacciones realizadas -> oferta caducada -> opcional: oferta las ofertas fallidas

serán ofertas que no correspondan a las dos categorías mencionadas anteriormente.

Por ejemplo, si una oferta se recibió y se vio pero no se realizaron transacciones antes del vencimiento de la oferta, la oferta sería una oferta fallida.

Si una oferta se recibió pero no se vio antes de su vencimiento, también se clasificaría como una oferta fallida, incluso si el dinero se gastara durante la validez de la oferta. Esto se debe a que el cliente está gastando dinero sin ninguna influencia de la oferta.

El seguimiento de la cantidad de dinero gastada durante las promociones será equivalente a encontrar la cantidad de dinero gastado para ofertas exitosas y probadas.

Conjunto de datos de transcripción dividida [19659091] El primer paso del preprocesamiento consiste en dividir la transcripción original en 4 subconjuntos más pequeños:

1. transcript_offer_received : rastrea cuando los clientes recibieron ofertas y qué tipo de ofertas recibieron
2. transcript_offer_ visto : rastrea cuando los clientes vieron ofertas y qué tipo de ofertas vieron
3. transcript_offer_completed : rastrea cuando los clientes completaron ofertas y qué tipo de ofertas completaron
4. transcript_trans : rastrea todas las transacciones realizado por clientes

Generar datos de transacciones mensuales etiquetados

Para comenzar, identificaremos las ofertas que han sido exitosas o probadas. Comenzamos fusionando transcript_offer_received, transcript_offer_viewed y transcript_offer_completed juntos . El marco de datos resultante se verá así.

En esta etapa, muchas ofertas generadas por el proceso de fusión no tendrán sentido.

Podemos eliminar una gran cantidad de ofertas falsas manteniendo las que cumplen con las siguientes condiciones:

1. oferta de tiempo completada> oferta de tiempo vista> oferta de tiempo recibida
2. (oferta de tiempo vista> oferta de tiempo recibida) y (oferta de tiempo completada es nula)
3. tanto la oferta de tiempo consultada como la oferta de tiempo completada son nulas

Las ofertas falsas aún existen en esta etapa, y se necesita un procesamiento adicional.

Podemos calcular el tiempo de vencimiento de todas las ofertas agregando la duración de las ofertas a los tiempos de recepción de las ofertas.

A continuación, podemos clasificar estas ofertas en sus resultados probables: exitoso, probado o fallido / falso. Tenga en cuenta que las clasificaciones en esta etapa no necesariamente significan que las ofertas sean realmente exitosas o probadas. Necesitaremos la información de la transacción más adelante para averiguarlo.

Las ofertas que cumplan con la siguiente condición se clasificarán como ofertas que probablemente tengan éxito:

1. (oferta de tiempo recibida ≤ tiempo visto) y (oferta de tiempo visto ≤ oferta de tiempo completado) y (oferta de tiempo completada ≤ vencimiento de la oferta de tiempo)

Las ofertas que cumplen con las siguientes condiciones se clasifican como ofertas que probablemente se intentaron:

1. (oferta de tiempo recibida ≤ oferta de tiempo vista) y (oferta de tiempo vista ≤ oferta de tiempo vencimiento) y (tiempo de vencimiento de la oferta <tiempo de finalización de la oferta)
2. (tiempo de la oferta recibida ≤ tiempo de la oferta visto) y (tiempo de la oferta visto ≤ tiempo de vencimiento de la oferta) y la oferta del tiempo completada es nula

no se cumplen estas condiciones. Las ofertas fallidas o falsas se descartarán.

Cualquier oferta con valores duplicados para ‘time_received’, ‘per_id’ y ‘offer_id’ se eliminará con la excepción de la primera aparición. Es poco probable que una persona reciba el mismo tipo de oferta más de una vez, y estas entradas duplicadas son entradas erróneas generadas por el proceso de fusión.

Llamaremos al marco de datos resultante succ_tried_offers .

A continuación, podemos combinar transcript_trans con succ_tried_offers para obtener todos los productos cruzados posibles entre las ofertas y las transacciones probadas. 19659011] Podemos etiquetar cada transacción para ver si ocurrieron durante la validez de la oferta. En otras palabras, verificaremos si el gasto ocurrió después de que se recibieron las ofertas y antes de que expiraran las ofertas.

Cualquier oferta en succ_tried_offers que tuvo transacciones que se produjeron durante su validez es probable que sean ofertas que son realmente exitoso o probado.

Podemos realizar una combinación a la izquierda de las transacciones etiquetadas en la transcripción de la transacción original para evitar cualquier posible doble conteo de transacciones. Esto también nos permitirá identificar qué transacciones ocurrieron durante los tiempos no promocionales también.

A continuación, podemos asignar los meses en que ocurrieron las transacciones y agregar los datos según el número del mes, la identificación de la persona y ofrecer id. Esto generará un resumen mensual de lo que gastan los clientes durante los tiempos promocionales y no promocionales. Nos referiremos a este marco de datos como Monthly_transactions .

Encontrar ofertas sin transacciones mensuales

de succ_tried_offers o intentadas.

Podemos obtener la lista de todas las ofertas que alguna vez fue enviada por Starbucks desde transcript_received.

La diferencia entre Dos nos pueden decir qué ofertas habían fallado. Estas son ofertas que no indujeron ninguna transacción monetaria durante su período de validez.

A continuación, podemos asignar los números de los meses en que se recibieron estas ofertas fallidas y nombrar el marco de datos resultante Monthly_failed_offers.

Buscar meses cuando los individuos no hicieron transacciones sin oferta

Tenga en cuenta que month_transactions ya hace un seguimiento de la cantidad de clientes que pasaron durante los tiempos no promocionales. Nuestro objetivo aquí es descubrir en qué meses los clientes no gastaron dinero durante los tiempos no promocionales.

Primero, generamos todas las combinaciones posibles de número de mes, identificación de persona y id. De oferta 10 (exposición no promocional). Vamos a referirnos a este marco de datos como non_offer_trans .

Luego podemos combinar Monthly_transactions marco de datos a non_offer_trans para descubrir qué combinaciones individuales de mes no tenían Transacciones monetarias durante períodos no promocionales.

Por lo tanto, obtendremos una cuenta mensual de cuando los clientes no gastaron dinero en situaciones no promocionales. Llamemos a este marco de datos no_offer_no_trans .

Recopilación de las opiniones de las personas, por ejemplo, por la naturaleza de las situaciones, por parte de las situaciones, por parte de cada una de las situaciones, por parte de las personas, por la naturaleza de las situaciones, por la naturaleza, por la naturaleza de las situaciones, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza, por la naturaleza de las condiciones, por la naturaleza de las situaciones, por la naturaleza de las situaciones, por la naturaleza de las situaciones, por la naturaleza de las situaciones, por la naturaleza de las condiciones. Monthly_failed_offers y no_offer_no_trans juntos . El conjunto de datos resultante registra mensualmente, cuánto gastó cada individuo en las diferentes promociones que se le enviaron, así como la cantidad de gastos no promocionales que realizaron.

Calcular los beneficios y generar etiquetas

A continuación, debemos calcular la cantidad de beneficios generados para cada instancia del conjunto de datos. Primero tendremos que calcular la cantidad de ofertas a las que cada individuo estuvo expuesto cada mes. Esto nos permite calcular el costo asociado con las ofertas.

Una forma fácil de hacerlo es verificar si los individuos estuvieron expuestos a más de 1 oferta de cada tipo en un mes. Al inspeccionar transcript_received notamos lo siguiente:

1. Ningún individuo recibió el mismo tipo de oferta más de una vez en el mismo mes.
2. Si una persona recibió una oferta que vence el próximo mes, / Ella no recibió una oferta de tipo similar durante el próximo mes. Por ejemplo, si un individuo recibió una “oferta id 2” en el mes 16 y la oferta vence durante el mes 17. No recibirá otra “oferta id 2” en el mes 17.

Por lo tanto, podemos concluir que los clientes fueron solo expuesto a un máximo de 1 aparición de un tipo de oferta cada mes.

Esto significa que el costo en mensual_datos es simplemente la recompensa de la promoción si se completó.

Podemos calcular el Cantidad de ganancias que cada individuo generó para cada tipo de oferta cada mes siguiendo las 3 reglas:

1. Si la oferta fue exitosa, la ganancia sería el ingreso mensual menos el costo de la oferta. Tenga en cuenta que las ofertas informativas no tienen costo.
2. Si la oferta no tuvo éxito, el beneficio sería el ingreso generado en esa instancia.
3. Si las transacciones no se realizaron como parte de una oferta, el beneficio sería el ingreso since there are no cost involved.

The uplift model that we will be using, involves modelling the probabilities of profits for a given person and month in two situations:

1. If the person receives an offer.
2. If the person did not receive an offer.

Because we want to predict the probability of profits, our labels (has_profit) will simply be an indicator variable indicating if there was a profit for that instance.

VI. Exploratory Data Analysis

Most Offers were not Attempted by Customers

From the chart above, we note that the vast majority of offers were not attempted by customers.

A general observation is that offers with longer validities, higher rewards and lower difficulties tend to have a higher success/try rate.

Note that informational offers cannot be completed since they lack a difficulty. Hence they are either tried or failed.

Only a Minority of Customers Successfully Completed or Tried More Than One Offer

Most customers received between 3 to 6 offers during the period of study.

However, the vast majority of customers did not successfully complete any offers. Only a small proportion of them completed 1 offer, and an even smaller proportion completed 2 or more offers.

The same is true for offers that are attempted (but not successfully completed). Very few customers responded (spend money) when presented with offers. Responding to 2 or more offers was extremely rare.

In general, offers seem to have limited effectiveness.

Monthly Profit Trend

The charts on the left plot the number of individuals who received promotions every month. In addition, the charts will show how many of these individuals generated promotional profits and non-promotional profits each month. A profitable instance can also be defined as a data point from the monthly_data dataset with has_profit label of 1.

The charts on the right plot the total monthly profits generated from individuals who received the promotion, as well as the total profits from their promotional and non-promotional spending.

From these charts, we can gauge the effectiveness of the promotions and evaluate whether these promotions’ effectiveness changed with time.

Discount 10/20/5 (Offer ID 0)

Discount 7/7/3 (Offer ID 1)

Discount 7/10/2 (Offer ID 2)

Informational 4/0/0 (Offer ID 3)

BOGO 5/10/10 (Offer ID 4)

Informational 3/0/0 (Offer ID 5)

BOGO 7/5/5 (Offer ID 6)

BOGO 7/10/10 (Offer ID 7)

BOGO 5/5/5 (Offer ID 8)

Discount 10/10/2 (Offer ID 9)

A recurring observation was that among individuals who received promotions each month, it was far more likely that they made purchases during days when they were not exposed to any prom otions as opposed to days when they were exposed to promotions. Hence, the number of non-promotional profit instances generally outnumbered the number of promotional profit instances.

Similar observation was noted in the total amount of profits generated during promotional and non-promotional periods, with non-promotional profits frequently exceeding promotional profits.

Granted, the number of days an individual was exposed to an offer was typically lower than the number of days an individual was not exposed to any offer.

Every month, the number of days an individual was subjected to the influence of an offer were bounded by the offer’s validity period, which could be anywhere from 3 to 10 days. Note that no individual received the same offer more than once in a month.

However, even if we did account for the disparity between exposure periods, non-promotional profits would still exceed promotional profits in most occasions.

Hence, this suggests that promotions have generally limited effectiveness in inducing customers to spend more than they normally do.

If the customers are generally willing to purchase Starbucks’ products without being given any promotions, it will not be in Starbucks’ best interest to send more of these promotions, since doing so will likely erode the profitability of the firm due to the promotions’ cost.

Our hope is that we will be able to identify individuals who spend only when given promotions. Restricting the sending of promotions to these individuals will help minimize cost and maximize profits.

In part 2 of the series, we will cover feature engineering, implementation of the uplift model, additional adjustments made to the model and data, results, and conclusion of the project. Link to Part 2 of the article.

The code accompanying this article can be found here.

---

Implementing a Profitable Promotional Strategy for Starbucks with Machine Learning (Part 1) was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.