Criar novos públicos-alvo com base no valor atual da vida útil do cliente

Saiba como prever o valor de vida útil do cliente (CLV) e, em seguida, use esses dados para identificar novos clientes em potencial criando públicos-alvo semelhantes no Google Ads.

Visão geral

Neste tutorial, mostramos como prever o provável valor monetário por cliente em um período especificado usando como base o histórico de transações do cliente. Para fazer isso, siga estas etapas:

  • Importe dados de transações e clientes para o BigQuery.
  • Processe os dados para uso com um modelo de machine learning (ML).
  • Crie o modelo de ML usando o BigQuery ML.
  • Confira as previsões do modelo para identificar os principais clientes por CLV.
  • Consiga o e-mail desses clientes a partir de uma tabela de dados de clientes.
  • O uso desses dados combinados para criar uma lista de remarketing para uso no Google Ads.
  • O uso dessa lista de remarketing como base para gerar um público-alvo semelhante para o uso da segmentação de anúncios.

Neste tutorial, você verá como criar um notebook do AI Platform para atender a esses objetivos, com orientações prescritivas e procedimentos passo a passo. Se você quiser um notebook concluído para começar, use bqml_automl_ltv_activate_lookalike.ipynb no servidor de notebook de sua escolha.

Este tutorial é destinado a engenheiros, cientistas e analistas de dados que criam conjuntos de dados e modelos de ML para ajudar na tomada de decisões de negócios. Pressupomos que você tenha conhecimentos básicos sobre os seguintes tópicos:

  • Compreensão básica de Python e dos conceitos de machine learning
  • SQL padrão

Neste tutorial, reduzimos o exemplo usado em Como prever o valor de vida útil do cliente com o AutoML Tables, que é a quarta e última parte de outra série de tutoriais sobre como prever o CLV. Leia o primeiro tutorial desta série, Como prever o valor de vida útil do cliente com a AI Platform: introdução, se você quiser entender melhor os principais pontos de decisão específicos da engenharia de atributos e desenvolvimento de modelos para a descoberta de CLV.

O exemplo neste tutorial é diferente do que consta em Como prever o valor de vida útil do cliente com o AutoML Tables, das seguintes maneiras:

  • Ele cria vários registros por cliente que serão usados no treinamento do modelo. Para fazer isso, ele segmenta as transações dos clientes em períodos sobrepostos.
  • Ele permite que você use o modelo para prever o CLV em períodos diferentes, por exemplo, um mês ou um trimestre, simplesmente alterando os parâmetros de entrada do modelo.
  • Ele minimiza o tempo de desenvolvimento usando o AutoML diretamente do BigQuery ML.
  • O exemplo usa conjuntos de dados diferentes para os dados de vendas e dos clientes.
  • Ela mostra como usar as predições de CLV para criar públicos-alvo semelhantes no Google Ads.

Conjuntos de dados

Para criar uma lista de clientes com CLV altos da qual é possível estabelecer um público-alvo semelhante, você precisa de dois conjuntos de dados:

  • Transações dos clientes que você quer avaliar: use cálculos com base nesses dados para treinar o modelo de CLV. Em um caso de uso de produção, você extrairia essas informações do seu sistema de processamento de pedidos.
  • Endereço de e-mail dos clientes: em um caso de uso de produção, você extrairia essas informações do sistema de gestão de relacionamento com o cliente (CRM).

Este tutorial fornece dados de amostra em dois arquivos CSV que você carrega nas tabelas do BigQuery. Esses dois conjuntos de dados contêm um ID do cliente usado para unir tabelas para associar o endereço de e-mail do cliente às informações do CLV.

Modelo

Neste tutorial, mostramos como criar um modelo de regressão a ser usado para prever o valor monetário futuro dos clientes, porque esse tipo de modelo é bom para prever uma variável contínua, também chamada de valor contínuo, como o valor do CLV.

Mais especificamente, ele será usado com o BigQuery ML para criar um modelo de regressão do AutoML. O uso do AutoML ajuda a minimizar a sobrecarga de desenvolvimento das seguintes maneiras:

  • Engenharia de atributos: o AutoML processa automaticamente várias tarefas comuns de engenharia de atributos.
  • Integração com o BigQuery ML: crie modelos do AutoML usando instruções SQL do BigQuery ML, o que limita a necessidade de alternar entre diferentes contextos de desenvolvimento.
  • Divisão do conjunto de dados de treinamento: ao treinar um modelo, a prática recomendada é dividir os dados em três conjuntos de dados não sobrepostos: treinamento, validação e teste. O AutoML lida com isso por padrão, mas você também pode especificar uma divisão específica se quiser.

Como calcular atributos e rótulos

Neste tutorial, você usa datas limite para segmentar as transações dos clientes ao longo do tempo em várias janelas sobrepostas. Uma data limite separa as transações de entrada das transações de destino. As transações de entrada ocorrem antes da data limite e são usadas para calcular os recursos inseridos no modelo. As transações de destino ocorrem após a data limite e são usadas para calcular o CLV referente a esse período, que é usado como o rótulo para o qual o modelo está sendo treinado para prever.

Atributos de RFM

Três atributos importantes usados em modelos CLV são os valores de tempo transcorrido desde a última visita, frequência e valor monetário (RFM), que você calcula dos dados do histórico de transações do cliente:

  • Tempo transcorrido desde a última visita: quando foi o último pedido do cliente?
  • Frequência: com que frequência eles compram?
  • Monetário: que quantia eles gastam?

O diagrama a seguir mostra uma série de vendas de um conjunto de quatro clientes.

Histórico de vendas para quatro clientes

O diagrama ilustra os valores do RFM dos clientes, com um índice de cada cliente para:

  • Tempo para retorno: o tempo entre a última compra e a atual, representado pela distância entre o círculo mais à direita e a linha pontilhada vertical rotulada Now (agora).
  • Frequência: o tempo entre as compras, representado pela distância entre os círculos em uma única linha.
  • Monetário: a quantia de dinheiro gasto em cada compra, representada pelo tamanho do círculo.

Requisitos para a integração do Google Ads

O código de exemplo nas seções deste tutorial sobre a integração do Google Ads requer acesso a um ambiente do Google Ads que funcione. Para que o código de exemplo possa ser executado com seu próprio ambiente do Google Ads, você precisa ter os seguintes itens:

  • Uma conta de administrador do Google Ads e acesso à API Google Ads. Se você ainda não tem essas instruções, siga as instruções no procedimento de inscrição.
  • Um token de desenvolvedor do Google Ads, um ID e uma chave secreta do cliente OAuth e um token de atualização OAuth para a biblioteca de cliente em Python do Google Ads. Se você ainda não tiver esses itens, siga as instruções em Configurar o acesso à AdWords API para consegui-los. Para a etapa 5 desse procedimento, use googleads-python-lib/examples/adwords/authentication/generate_refresh_token.py para ver como receber um token de atualização.
  • Dados de transação que podem ser usados para calcular o CLV e dados do cliente que incluem o endereço de e-mail do cliente. Use isso no lugar dos dados de amostra fornecidos na seção Importar os dados. Você precisará garantir que os dados usem os mesmos nomes e esquemas de tabela que os dados de amostra. As tabelas a seguir descrevem as tabelas esperadas do BigQuery:

Tabela clv.sales

Coluna Tipo de dado
customer_id INTEGER
order_id STRING
transaction_date DATE
product_sku STRING
qty INTEGER
unit_price FLOAT

Tabela clv.customers

Coluna Tipo de dado
customer_id INTEGER
full_name STRING
age INTEGER
job_title STRING
email STRING

Objetivos

  1. Preparar e explorar dados de treinamento usando o BigQuery
  2. Criar, treinar e implantar um modelo de ML usando o BigQuery ML
  3. Receber previsões de CLV enviadas pelo modelo implantado
  4. Criar uma lista dos clientes que representam os 20% principais do CLV
  5. Criar uma lista de remarketing do Google Ads com base na lista dos principais clientes de CLV, que você consegue usar para gerar um público-alvo semelhante a esses clientes

Custos

Neste tutorial, há componentes faturáveis do Google Cloud, a saber:

  • AI Platform
  • BigQuery
  • BigQuery ML
  • Compute Engine

Use a calculadora de preços para gerar uma estimativa de custos baseada na projeção de uso. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Antes de começar

  1. Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
  2. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  3. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  4. Ative as APIs Compute Engine, BigQuery, and Notebooks.

    Ative as APIs

Criar um notebook

  1. Abrir o console do Notebooks
  2. Clique em Nova instância.
  3. Escolha Python 2 e 3.
  4. Em Nome da instância, digite clv.
  5. Clique em Criar A criação da instância do notebook leva alguns minutos.
  6. Quando a instância estiver disponível, clique em Abrir JupyterLab.
  7. Na seção Notebook do JupyterLab, clique em Python 3.

Instalar bibliotecas

Instale googleads e outras bibliotecas necessárias para este tutorial:

  1. Copie o seguinte código na primeira célula do notebook:

    # Install libraries.
    %pip install -q googleads
    %pip install -q -U kfp matplotlib Faker --user
    
    # Restart kernel after installs
    import IPython
    app = IPython.Application.instance()
    app.kernel.do_shutdown(True)
    
  2. Clique em Executar na barra de menu.

Importar pacotes

Instale os pacotes necessários para este tutorial copiando o seguinte código na próxima célula vazia do notebook e executando-o:

from __future__ import absolute_import
from __future__ import division
from __future__ import print_function

import os, json, random
import hashlib, uuid
import time, calendar, math
import pandas as pd, numpy as np
import matplotlib.pyplot as plt, seaborn as sns
from datetime import datetime
from google.cloud import bigquery
from googleads import adwords

Crie um cliente do BigQuery

Crie um cliente do BigQuery para a biblioteca de cliente Python para BigQuery. Para isso, copie o seguinte código na próxima célula vazia do notebook e execute-o. Substitua myProject pelo ID do projeto que você está usando para concluir este tutorial. É possível encontrar o ID do projeto no card Informações do projeto no painel do projeto do Google Cloud.

bq_client = bigquery.Client(project="myProject")

Importar os dados

Use as instruções nas seções a seguir para importar os dados de amostra para o BigQuery e processá-los para usar o treinamento do modelo de ML.

Se você tem um ambiente ativo do Google Ads, pode usar seus próprios dados em vez de importar a amostra. Preencha a tabela clv.sales com dados de transação que podem ser usados para calcular o CLV e preencha a tabela clv.customers com dados do cliente que inclui o endereço de e-mail do cliente.

crie um conjunto de dados

Antes de criar tabelas do BigQuery para os dados de exemplo, é necessário criar um conjunto de dados para incluí-los.

Crie o conjunto de dados clv copiando o código a seguir para a próxima célula vazia do notebook e executando-o. Substitua myProject pelo ID do projeto que você está usando para concluir este tutorial.

PROJECT_ID = "myProject"
! bq mk $PROJECT_ID:clv

Importar os dados de vendas

Crie e preencha a tabela clv.sales copiando o seguinte código na próxima célula vazia do notebook e executando-o:

! bq load \
--project_id $PROJECT_ID \
--skip_leading_rows 1 \
--max_bad_records 100000 \
--replace \
--field_delimiter "," \
--autodetect \
clv.sales \
gs://solutions-public-assets/analytics-componentized-patterns/ltv/sales_*

Importar os dados dos clientes

Crie e preencha a tabela clv.customers copiando o seguinte código na próxima célula vazia do notebook e executando-o:

! bq load \
--project_id $PROJECT_ID \
--skip_leading_rows 1 \
--max_bad_records 100000 \
--replace \
--field_delimiter "," \
--autodetect \
clv.customers \
gs://solutions-public-assets/analytics-componentized-patterns/ltv/crm.csv

Prepare os dados

Para preparar os dados de transação do cliente a fim de usá-los para treinar o modelo de ML, conclua as seguintes tarefas:

  • Defina os parâmetros que determinam o desvio padrão permitido para o valor monetário do pedido e a quantidade de itens. Eles são usados para identificar e remover registros outliers de cada cliente ao realizar a agregação inicial dos dados da transação do cliente.
  • Agregue os dados de transação do cliente.
  • Verifique a distribuição dos dados agregados entre critérios como transações por cliente e número de itens por pedido para identificar áreas em que convém refinar ainda mais os dados.
  • Defina os atributos a serem calculados a partir dos dados agregados, como os valores de RFM.
  • Defina os parâmetros que configuram o período de tempo a ser usado para o cálculo do recurso. Por exemplo, quantos dias deve haver entre as datas limite.
  • Calcule os atributos necessários para treinar o modelo.

Definir parâmetros de agregação

Use os seguintes parâmetros no procedimento de agregação para definir os valores máximos do desvio padrão:

  • MAX_STDV_MONETARY: o desvio padrão do valor monetário por cliente.
  • MAX_STDV_QTY: o desvio padrão da quantidade de produtos por cliente.

Defina parâmetros para determinar os valores de variação padrão a serem usados. Basta copiar o seguinte código na próxima célula vazia do notebook e executá-lo:

AGG_PARAMS = {
    'MAX_STDV_MONETARY': 500,
    'MAX_STDV_QTY': 100
}

Em um caso de uso de produção, é possível modificar esses parâmetros para determinar quais intervalos de valores são aceitáveis para o valor do pedido e a quantidade de itens.

Agregar dados das transações dos clientes

A consulta a seguir agrega todos os pedidos por dia de cada cliente. Como a tarefa de ML é prever um valor monetário para um período, como semanas ou meses, os dias funcionam bem como uma unidade de tempo para agrupar as transações por cliente.

Esta consulta também remove os pedidos outliers de cada cliente. Serão removidos os pedidos em que o valor ou a quantidade de produtos estiver fora dos valores de desvio padrão aceitáveis que foram especificados por MAX_STDV_MONETARY e MAX_STDV_QTY.

  1. Crie uma tabela com dados de transação agregados do cliente. Basta copiar o seguinte código na próxima célula vazia do notebook e executá-lo:

    %%bigquery --params $AGG_PARAMS --project $PROJECT_ID
    
    DECLARE MAX_STDV_MONETARY INT64 DEFAULT @MAX_STDV_MONETARY;
    DECLARE MAX_STDV_QTY INT64 DEFAULT @MAX_STDV_QTY;
    
    CREATE OR REPLACE TABLE `clv.aggregation` AS
    SELECT
      customer_id,
      order_day,
      ROUND(day_value_after_returns, 2) AS value,
      day_qty_after_returns as qty_articles,
      day_num_returns AS num_returns,
      CEIL(avg_time_to_return) AS time_to_return
    FROM (
      SELECT
        customer_id,
        order_day,
        SUM(order_value_after_returns) AS day_value_after_returns,
        STDDEV(SUM(order_value_after_returns)) OVER(PARTITION BY customer_id ORDER BY SUM(order_value_after_returns)) AS stdv_value,
        SUM(order_qty_after_returns) AS day_qty_after_returns,
        STDDEV(SUM(order_qty_after_returns)) OVER(PARTITION BY customer_id ORDER BY SUM(order_qty_after_returns)) AS stdv_qty,
        CASE
          WHEN MIN(order_min_qty) < 0 THEN count(1)
          ELSE 0
        END AS day_num_returns,
        CASE
          WHEN MIN(order_min_qty) < 0 THEN AVG(time_to_return)
          ELSE NULL
        END AS avg_time_to_return
      FROM (
        SELECT
          customer_id,
          order_id,
          -- Gives the order date vs return(s) dates.
          MIN(transaction_date) AS order_day,
          MAX(transaction_date) AS return_final_day,
          DATE_DIFF(MAX(transaction_date), MIN(transaction_date), DAY) AS time_to_return,
          -- Aggregates all products in the order
          -- and all products returned later.
          SUM(qty * unit_price) AS order_value_after_returns,
          SUM(qty) AS order_qty_after_returns,
          -- If negative, order has qty return(s).
          MIN(qty) order_min_qty
        FROM
          `clv.sales`
        GROUP BY
          customer_id,
          order_id)
      GROUP BY
        customer_id,
        order_day)
    WHERE
      -- [Optional] Remove dates with outliers per a customer.
      (stdv_value < MAX_STDV_MONETARY
        OR stdv_value IS NULL) AND
      (stdv_qty < MAX_STDV_QTY
        OR stdv_qty IS NULL);
    
  2. Veja uma amostra dos dados na tabela clv.aggregation resultante copiando o seguinte código na próxima célula vazia do notebook e executando-o:

    %%bigquery
    
    SELECT * FROM clv.aggregation LIMIT 5;
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Primeiras cinco linhas de dados agregados.

Em um caso de uso de produção, você provavelmente refinaria ainda mais os dados aplicando outros critérios de seleção, como as seguintes opções:

  • Remover registros que não têm quantidades de itens e quantidades de compras positivas
  • Remover os registros que não têm um ID de cliente
  • Manter somente os clientes ativos. Você escolhe que tipo de cliente é definido como ativo. Por exemplo, é uma boa ideia se concentrar nos clientes que compraram algo nos últimos 90 dias

Verificar a distribuição de dados

Neste tutorial, você aprende a realizar uma limpeza mínima de dados, concentrando-se na transformação básica dos dados de transação para que eles funcionem com o modelo. Nesta seção, você verifica a distribuição de dados para determinar onde há outliers e identifica áreas para o refinamento adicional.

Verificar a distribuição por data

  1. Crie e preencha o df_dist_dates dataframe com dados de data das transações agregadas copiando o código a seguir na próxima célula vazia do notebook e executando-o:

    %%bigquery df_dist_dates --project $PROJECT_ID
    
    SELECT count(1) c, SUBSTR(CAST(order_day AS STRING), 0, 7) as yyyy_mm
    FROM `clv.aggregation`
    WHERE qty_articles > 0
    GROUP BY yyyy_mm
    ORDER BY yyyy_mm
    
  2. Use seborn para visualizar os dados de data. Para isso, copie o código a seguir na próxima célula vazia do notebook e execute-o:

    plt.figure(figsize=(12,5))
    sns.barplot( x='yyyy_mm', y='c', data=df_dist_dates)
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Visualização da distribuição dos dados de data.

    Os pedidos são bem distribuídos ao longo do ano, embora seja um pouco menor nos primeiros meses capturados nesse conjunto de dados. Em um caso de uso de produção, use a distribuição de dados por data como um fator a ser considerado ao definir os parâmetros da janela de tempo para o procedimento de computação em atributos.

Verificar a distribuição por transações por cliente

  1. Crie e preencha o quadro de dados df_dist_customers com as contagens de transações de clientes das transações agregadas. Para fazer isso, copie o seguinte código na próxima célula vazia do notebook e execute-o:

    %%bigquery df_dist_customers --project $PROJECT_ID
    
    SELECT customer_id, count(1) c
    FROM `clv.aggregation`
    GROUP BY customer_id
    
  2. Use o Seaborn para visualizar os dados da transação do cliente. Para isso, copie o seguinte código para a próxima célula vazia do notebook e execute-o:

    plt.figure(figsize=(12,4))
    sns.distplot(df_dist_customers['c'], hist_kws=dict(ec="k"), kde=False)
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Visualização da distribuição dos dados de clientes.

    Esses dados têm boa distribuição, com o número de transações por cliente distribuídos em um intervalo restrito e sem valores claros.

Verificar a distribuição por quantidade de itens

  1. Crie e preencha o quadro de dados df_dist_qty com os dados de quantidade de item das transações agregadas. Basta copiar o seguinte código na próxima célula vazia do notebook e executá-lo:

    %%bigquery df_dist_qty --project $PROJECT_ID
    
    SELECT qty_articles, count(1) c
    FROM `clv.aggregation`
    GROUP BY qty_articles
    
  2. Use o Seaborn para visualizar os dados da quantidade de itens. Para isso, copie o código a seguir para a próxima célula vazia do notebook e execute-o:

    plt.figure(figsize=(12,4))
    sns.distplot(df_dist_qty['qty_articles'], hist_kws=dict(ec="k"), kde=False)
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Visualização da distribuição dos dados de quantidade de itens.

    Alguns clientes têm quantidades muito grandes nos pedidos, mas a distribuição geralmente é boa. Em um caso de uso de produção, é possível fazer mais engenharia de dados nessa área. Você quer remover transações outliers para clientes individuais, por exemplo, remover uma transação de 20 itens para um cliente que normalmente compra 1 ou 2 itens. Você quer manter os clientes que são outliers porque eles compram muito mais itens do que outros.

Verificar a distribuição por valor monetário

  1. Crie e preencha o DataFrame df_dist_values com dados de valor monetário das transações agregadas, copiando o seguinte código na próxima célula vazia do notebook e executando-o:

    %%bigquery df_dist_values --project $PROJECT_ID
    
    SELECT value
    FROM `clv.aggregation`
    
  2. Use o marbordo para visualizar os dados do valor monetário copiando o código a seguir na próxima célula vazia do notebook e executando-o:

    axv = sns.violinplot(x=df_dist_values["value"])
    axv.set_xlim(-200, 3500)
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Visualização da distribuição dos dados monetários.

    A distribuição mostra alguns outliers que gastam significativamente mais do que a média. Em um caso de uso de produção, é possível fazer mais engenharia de dados nessa área. Você quer remover transações outliers para clientes individuais, por exemplo, remover uma transação de US $1.000 para um cliente que normalmente gasta cerca de US $50 por transação. Você quer manter os clientes que são outliers porque eles geralmente gastam muito mais do que outros.

Definir atributos

Na tabela a seguir, descrevemos os atributos que são calculados para treinar o modelo:

Nome do recurso Tipo Descrição
monetário FLOAT A soma dos valores monetários de todas as transações de um determinado cliente em um determinado período.
frequência INTEGER O número de transações feitas por um determinado cliente em um determinado período.
tempo para retorno INTEGER O tempo entre a primeira e a última transações que foram executadas por um determinado cliente durante um período específico.
T INTEGER O tempo entre a primeira transação no conjunto de dados e o final do período de transações de entrada.
time_between FLOAT O tempo médio entre as transações de determinado cliente em um determinado período.
avg_basket_value FLOAT O valor monetário médio da cesta de compras do cliente em um determinado período.
avg_basket_size FLOAT O número médio de itens que um determinado cliente tem no seu carrinho durante um determinado período.
has_returns STRING Se um determinado cliente devolveu itens para pelo menos uma transação durante um determinado período.
avg_time_to_return FLOAT O tempo que um cliente leva para retornar o primeiro item da transação.
num_returns INTEGER O número de itens retornados pelo cliente que estão associados a transações em uma determinada janela de tempo.

Definir parâmetros de computação de atributos

Os parâmetros a seguir definem os períodos que serão usados para calcular os atributos:

  • WINDOW_STEP: especifica o número de dias entre os limites. Isso determina a frequência com que você calcula recursos e rótulos.
  • WINDOW_STEP_INITIAL: especifica o número de dias entre a primeira data de pedido nos dados de treinamento e o primeiro limite.
  • WINDOW_LENGTH: especifica o número de dias a serem usados para transações de entrada. O padrão é usar um valor de 0, que toma todas as transações antes do limite fornecido.
  • LENGTH_FUTURE: especifica o número de dias no futuro para prever o valor monetary que serve como rótulo do ML. A cada limite, o BigQuery calcula o valor do rótulo para todos os pedidos que ocorrem LENGTH_FUTURE após a data limite.

Por exemplo, supondo um conjunto de dados com uma data de transação mais antiga de 01/01/2015 e os seguintes valores de parâmetro:

  • WINDOW_STEP: 30
  • WINDOW_STEP_INITIAL: 90
  • WINDOW_LENGTH: 0
  • LENGTH_FUTURE: 30

As janelas de tempo dos primeiros loops do procedimento de criação de recursos funcionariam da seguinte maneira:

Primeira repetição

Parâmetro Como o cálculo é feito Valor
Data limite A data da transação mais antiga + o valor WINDOW_STEP_INITIAL, ou seja, 01/01/2015 + 90 dias. 01/04/2015
Window start WINDOW_LENGTH é zero. Portanto, todas as transações antes do limite são usadas. A transação mais antiga acontecerá no dia 01/01/2015. 01/01/2015
Período da transação de entrada Da data de início do período até a data limite. 01/01/2015 - 01/04/2015
Período da transação de destino Desde a data limite (exclusiva) até a data limite + o número de dias especificados por LENGTH_FUTURE (01/04/2015 + 30 dias). 04/02/2015 - 01/05/2015

Segunda repetição

Parâmetro Como o cálculo é feito Valor
Data limite A data limite do loop anterior + o valor WINDOW_STEP, portanto, 01/04/2015 + 30 dias 01/05/2015
Window start WINDOW_LENGTH é zero. Portanto, todas as transações antes do limite são usadas. A transação mais antiga acontecerá no dia 01/01/2015. 01/01/2015
Período da transação de entrada Da data de início do período até a data limite. 01/01/2015 - 01/05/2015
Período da transação de destino Desde a data limite (exclusiva) até a data limite + o número de dias especificados por LENGTH_FUTURE (01/05/2015 + 30 dias). 02/05/2015 - 31/05/2015

Se você modificar WINDOW_LENGTH para ter um valor de 15, os períodos funcionariam da seguinte maneira:

Primeira repetição

Parâmetro Como o cálculo é feito Valor
Data limite A data da transação mais antiga + o valor WINDOW_STEP_INITIAL, ou seja, 01/01/2015 + 90 dias. 01/04/2015
Window start Data limite: valor de WINDOW_LENGTH, portanto, 01/04/2015 - 15 dias. 17/03/2015
Período da transação de entrada Da data de início do período até a data limite. 17/03/2015 - 01/04/2015
Período da transação de destino Desde a data limite (exclusiva) até a data limite + o número de dias especificados por LENGTH_FUTURE (01/04/2015 + 30 dias). 04/02/2015 - 01/05/2015

Segunda repetição

Parâmetro Como o cálculo é feito Valor
Data limite Limite de data do loop anterior + valor de WINDOW_STEP. Sendo assim, 01/04/2015 + 30 dias. 01/05/2015
Window start Data do limite - valor WINDOW_LENGTH, portanto, 0501/2015 - 15 dias 16/04/2015
Período da transação de entrada Da data de início do período até a data limite. 16/04/2015 - 01/05/2015
Período da transação de destino Desde a data limite (exclusiva) até a data limite + o número de dias especificados por LENGTH_FUTURE (01/05/2015 + 30 dias). 02/05/2015 - 31/05/2015

Defina os parâmetros para determinar as janelas de computação de atributos copiando o seguinte código na próxima célula vazia do notebook e executando-o:

CLV_PARAMS = {
    'WINDOW_LENGTH': 0,
    'WINDOW_STEP': 30,
    'WINDOW_STEP_INITIAL': 90,
    'LENGTH_FUTURE': 30
}

Em um caso de uso de produção, você alteraria esses parâmetros para conseguir resultados mais adequados aos dados com que está trabalhando. Por exemplo, se os clientes compram várias vezes por semana, você pode calcular recursos usando períodos semanais. Ou, se você tiver muitos dados, poderá criar mais períodos reduzindo os tamanhos e possivelmente diminuindo o número de dias entre as datas limite. Testar esses parâmetros, além do ajuste de hiperparâmetro, pode melhorar o desempenho do modelo.

Criar recursos

  1. Crie uma tabela com recursos calculados para treinar o modelo. Para isso, copie o seguinte código na próxima célula vazia do notebook e execute-o:

    %%bigquery --params $CLV_PARAMS --project $PROJECT_ID
    
    -- Length
    -- Date of the first order in the dataset.
    DECLARE MIN_DATE DATE;
    -- Date of the final order in the dataset.
    DECLARE MAX_DATE DATE;
    -- Date that separates inputs orders from target transactions.
    DECLARE THRESHOLD_DATE DATE;
    -- How many days back for inputs transactions. 0 means from the start.
    DECLARE WINDOW_LENGTH INT64 DEFAULT @WINDOW_LENGTH;
    -- Date at which an input transactions window starts.
    DECLARE WINDOW_START DATE;
    -- How many days between thresholds.
    DECLARE WINDOW_STEP INT64 DEFAULT @WINDOW_STEP;
    -- How many days for the first window.
    DECLARE WINDOW_STEP_INITIAL INT64 DEFAULT @WINDOW_STEP_INITIAL;
    -- Index of the window being run.
    DECLARE STEP INT64 DEFAULT 1;
    -- How many days to predict for.
    DECLARE LENGTH_FUTURE INT64 DEFAULT @LENGTH_FUTURE;
    
    SET (MIN_DATE, MAX_DATE) = (
      SELECT AS STRUCT
        MIN(order_day) AS min_days,
        MAX(order_day) AS max_days
      FROM
        `clv.aggregation`
    );
    
    SET THRESHOLD_DATE = MIN_DATE;
    
    -- For more information about the features of this table,
    -- see https://github.com/CamDavidsonPilon/lifetimes/blob/master/lifetimes/utils.py#L246
    -- and https://cloud.google.com/solutions/machine-learning/clv-prediction-with-offline-training-train#aggregating_data
    CREATE OR REPLACE TABLE clv.features
    (
      customer_id STRING,
      monetary FLOAT64,
      frequency INT64,
      recency INT64,
      T INT64,
      time_between FLOAT64,
      avg_basket_value FLOAT64,
      avg_basket_size FLOAT64,
      has_returns STRING,
      avg_time_to_return FLOAT64,
      num_returns INT64,
      -- threshold DATE,
      -- step INT64,
      target_monetary FLOAT64,
    );
    
    -- Using a BigQuery scripting loop
    -- (https://cloud.google.com/bigquery/docs/reference/standard-sql/scripting#loop)
    -- lets you enhance the logic of your query without the need of another
    -- programming language or client code.
    
    LOOP
      -- Can choose a longer original window in case
      -- there were not many orders in the early days.
      IF STEP = 1 THEN
        SET THRESHOLD_DATE = DATE_ADD(THRESHOLD_DATE, INTERVAL WINDOW_STEP_INITIAL DAY);
      ELSE
        SET THRESHOLD_DATE = DATE_ADD(THRESHOLD_DATE, INTERVAL WINDOW_STEP DAY);
      END IF;
      SET STEP = STEP + 1;
    
      IF THRESHOLD_DATE >= DATE_SUB(MAX_DATE, INTERVAL (WINDOW_STEP) DAY) THEN
        LEAVE;
      END IF;
    
      -- Takes all transactions before the threshold date unless you decide
      -- to use a different window length to test model performance.
      IF WINDOW_LENGTH != 0 THEN
        SET WINDOW_START = DATE_SUB(THRESHOLD_DATE, INTERVAL WINDOW_LENGTH DAY);
     ELSE
        SET WINDOW_START = MIN_DATE;
      END IF;
       INSERT clv.features
      SELECT
        CAST(tf.customer_id AS STRING),
        ROUND(tf.monetary_orders, 2) AS monetary,
        tf.cnt_orders AS frequency,
        tf.recency,
        tf.T,
        ROUND(tf.recency/cnt_orders, 2) AS time_between,
        ROUND(tf.avg_basket_value, 2) AS avg_basket_value,
        ROUND(tf.avg_basket_size, 2) AS avg_basket_size,
        has_returns,
        CEIL(avg_time_to_return) AS avg_time_to_return,
        num_returns,
        ROUND(tt.target_monetary, 2) AS target_monetary,
      FROM (
          -- This SELECT uses only data before THRESHOLD_DATE to make features.
          SELECT
            customer_id,
            SUM(value) AS monetary_orders,
            DATE_DIFF(MAX(order_day), MIN(order_day), DAY) AS recency,
            DATE_DIFF(THRESHOLD_DATE, MIN(order_day), DAY) AS T,
            COUNT(DISTINCT order_day) AS cnt_orders,
            AVG(qty_articles) avg_basket_size,
            AVG(value) avg_basket_value,
            CASE
              WHEN SUM(num_returns) > 0 THEN 'y'
              ELSE 'n'
            END AS has_returns,
            AVG(time_to_return) avg_time_to_return,
            THRESHOLD_DATE AS threshold,
            SUM(num_returns) num_returns,
          FROM
            `clv.aggregation`
          WHERE
            order_day <= THRESHOLD_DATE AND
            order_day >= WINDOW_START
          GROUP BY
            customer_id
        ) tf
          INNER JOIN (
        -- This SELECT uses all data after threshold as target.
        SELECT
          customer_id,
          SUM(value) target_monetary
        FROM
          `clv.aggregation`
        WHERE
          order_day <= DATE_ADD(THRESHOLD_DATE, INTERVAL LENGTH_FUTURE DAY)
          -- For the sample data, the overall value is similar to the value
          -- after threshold, and prediction performs better using the overall
          -- value. When using your own data, try uncommenting the following
          -- AND clause and see which version of the procedure gives you better
          -- results.
          -- AND order_day > THRESHOLD_DATE
        GROUP BY
          customer_id) tt
      ON
          tf.customer_id = tt.customer_id;
      END LOOP;
    
  2. Veja uma amostra dos dados de um cliente na tabela clv.features resultante. Para isso, copie o seguinte código para a próxima célula vazia do notebook e execute-o:

    %%bigquery
    
    SELECT * FROM `clv.features` WHERE customer_id = "10"
    UNION ALL
    (SELECT * FROM `clv.features` LIMIT 5)
    ORDER BY customer_id, frequency, T LIMIT 5
    
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Primeiras cinco linhas de dados de atributos.

Treine o modelo

Neste tutorial, usamos o AUTOML_REGRESSOR no BigQuery ML para criar, treinar e implantar um modelo de regressão AutoML.

O tutorial usa as configurações padrão para treinar o modelo. Em um caso de uso de produção, é possível testar outras técnicas de engenharia de atributos e diferentes divisões de dados de treinamento para melhorar o modelo.

Crie e preencha o modelo clv_model copiando o seguint código na próxima célula vazia do notebook e executando-o:

%%bigquery

CREATE OR REPLACE MODEL `clv.clv_model`
       OPTIONS(MODEL_TYPE="AUTOML_REGRESSOR",
               INPUT_LABEL_COLS=["target_monetary"],
               OPTIMIZATION_OBJECTIVE="MINIMIZE_MAE")
AS SELECT
  * EXCEPT(customer_id)
FROM
  `clv.features`

Isso deve dar a você um bom modelo base para começar a trabalhar. Para adaptar o modelo aos seus próprios dados e casos de uso, otimize-o. Para fazer isso, use o ajuste de hiperparâmetros, a engenharia de atributos e outras técnicas.

Prever o CLV

Em seguida, receba previsões do CLV do modelo para cada cliente e grave esses dados em uma tabela. Os registros de previsão contêm os campos descritos na tabela a seguir:

Nome do campo Tipo Descrição
customer_id STRING ID de cliente
monetary_so_far FLOAT Valor total em dinheiro gasto pelo cliente antes da data de previsão.
monetary_predicted FLOAT Valor total estimado de dinheiro gasto pelo cliente, que é a soma dos valores do campo monetary_so_far e monetary_future.
monetary_future FLOAT Valor futuro previsto de dinheiro que o cliente gastará entre a data da previsão e o final do período da previsão.
  1. Crie e preencha a tabela clv.predictions copiando o seguinte código na próxima célula vazia do notebook e executando-o:

    %%bigquery --params $CLV_PARAMS --project $PROJECT_ID
    
    -- How many days back for inputs transactions. 0 means from the start.
    DECLARE WINDOW_LENGTH INT64 DEFAULT @WINDOW_LENGTH;
    -- Date at which an input transactions window starts.
    DECLARE WINDOW_START DATE;
    
    -- Date of the first transaction in the dataset.
    DECLARE MIN_DATE DATE;
    -- Date of the final transaction in the dataset.
    DECLARE MAX_DATE DATE;
    -- Date from which you want to predict.
    DECLARE PREDICT_FROM_DATE DATE;
    
    SET (MIN_DATE, MAX_DATE) = (
      SELECT AS STRUCT
        MIN(order_day) AS min_days,
        MAX(order_day) AS max_days
      FROM
        `clv.aggregation`
    );
    
    -- You can set any date here. In production, it is generally today.
    SET PREDICT_FROM_DATE = MAX_DATE;
    IF WINDOW_LENGTH != 0 THEN
      SET WINDOW_START = DATE_SUB(PREDICT_FROM_DATE, INTERVAL WINDOW_LENGTH DAY);
    ELSE
      SET WINDOW_START = MIN_DATE;
    END IF;
    
    CREATE OR REPLACE TABLE `clv.predictions`
    AS (
    SELECT
      customer_id,
      monetary AS monetary_so_far,
      ROUND(predicted_target_monetary, 2) AS monetary_predicted,
      ROUND(predicted_target_monetary - monetary, 2) AS monetary_future
    FROM
      ML.PREDICT(
        -- To use your own model, set the model name here.
        MODEL clv.clv_model,
        (
          SELECT
            customer_id,
            ROUND(monetary_orders, 2) AS monetary,
            cnt_orders AS frequency,
            recency,
            T,
            ROUND(recency/cnt_orders, 2) AS time_between,
            ROUND(avg_basket_value, 2) AS avg_basket_value,
            ROUND(avg_basket_size, 2) AS avg_basket_size,
            has_returns,
            CEIL(avg_time_to_return) AS avg_time_to_return,
            num_returns
          FROM (
            SELECT
              customer_id,
              SUM(value) AS monetary_orders,
              DATE_DIFF(MAX(order_day), MIN(order_day), DAY) AS recency,
              DATE_DIFF(PREDICT_FROM_DATE, MIN(order_day), DAY) AS T,
              COUNT(DISTINCT order_day) AS cnt_orders,
              AVG(qty_articles) avg_basket_size,
              AVG(value) avg_basket_value,
              CASE
                WHEN SUM(num_returns) > 0 THEN 'y'
                ELSE 'n'
              END AS has_returns,
              AVG(time_to_return) avg_time_to_return,
              SUM(num_returns) num_returns,
            FROM
              `clv.aggregation`
            WHERE
              order_day <= PREDICT_FROM_DATE AND
              order_day >= WINDOW_START
            GROUP BY
              customer_id
          )
        )
      )
    )
    
  2. Veja uma amostra dos dados na tabela clv.features resultante copiando o seguinte código na próxima célula vazia do notebook e executando-o:

    %%bigquery
    
    SELECT * FROM clv.predictions
    ORDER BY customer_id
    LIMIT 5;
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Primeiras cinco linhas de dados de previsão.

Avaliar os dados de previsão

Visualize e gere estatísticas sobre os dados de previsão para entender melhor a distribuição de dados e ver se há tendências claras.

  1. Crie um DataFrame com base na tabela clv.predictions:

    %%bigquery df_predictions --project $PROJECT_ID
    
    clv.predictions
    
  2. Use pandas.DataFrame.describe para gerar estatísticas descritivas nos dados de predição. Basta copiar o código a seguir na próxima célula vazia do notebook e executá-lo:

    df_predictions.describe()
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Estatísticas para dados de previsão.

  3. Use matplotlib.gridspec para ver os dados de predição. Para isso, copie o seguinte código para a próxima célula vazia do notebook e execute-o:

    from matplotlib.gridspec import GridSpec
    
    fig = plt.figure(constrained_layout=True, figsize=(15, 5))
    gs = GridSpec(2, 2, figure=fig)
    
    sns.set(font_scale = 1)
    plt.tick_params(axis='x', labelsize=14)
    
    ax0 = plt.subplot(gs.new_subplotspec((0, 0), colspan=1))
    ax1 = plt.subplot(gs.new_subplotspec((0, 1), colspan=1))
    ax2 = plt.subplot(gs.new_subplotspec((1, 0), colspan=2))
    
    sns.violinplot(df_predictions['monetary_so_far'], ax=ax0, label='monetary_so_far')
    sns.violinplot(df_predictions['monetary_predicted'], ax=ax1, label='monetary_predicted')
    sns.violinplot(df_predictions['monetary_future'], ax=ax2, label='monetary_future')
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Visualização da distribuição dos dados de previsão.

    A análise de distribuição monetária mostra pequenos valores monetários para o próximo mês em comparação com o valor histórico geral. Um motivo é que o modelo é treinado para prever o valor do próximo mês, conforme especificado no parâmetro LENGTH_FUTURE. Teste a alteração desse valor para treinar e prever no próximo trimestre (seria LENGTH_FUTURE = 90) e veja como a distribuição é alterada.

Criar um público-alvo semelhante

Use os procedimentos desta seção para criar e exportar uma lista de clientes com um CLV alto e, em seguida, usar essa lista para criar um público-alvo semelhante no Google Ads.

Os exemplos de código nas seções a seguir Identificar principais clientes do CLV só poderão ser executados se você tiver acesso a um ambiente funcional do Google Ads. Resolva os Requisitos de integração do Google Ads para que esse código de exemplo seja executado no seu ambiente do Google Ads.

Identificar os principais clientes por CLV

Como primeira etapa para criar um público-alvo semelhante, você precisa identificar seus principais clientes com base no CLV previsto e associar endereços de e-mail a eles. Para isso, use o ID do cliente para mesclar a tabela de previsões com uma tabela de dados do cliente que contém essas informações.

Neste tutorial, usamos 20% dos principais clientes com base no CLV. É possível alterar a porcentagem de clientes a serem selecionados, basta modificar o parâmetro TOP_CLV_RATIO. A instrução SQL para selecionar os clientes usa a função PERCENT_RANK para identificar clientes cujo gasto futuro previsto os coloca na/acima da porcentagem identificada pelo valor TOP_CLV_RATIO.

  1. Para definir o parâmetro TOP_CLV_RATIO, copie o seguinte código na próxima célula vazia do notebook e execute-o:

    CLV_PARAMS = {
        'TOP_CLV_RATIO': 0.2
    }
    
  2. Crie e preencha o DataFrame df_top_ltv copiando o seguinte código na próxima célula vazia do notebook e executando-o:

    %%bigquery df_top_ltv --params $CLV_PARAMS --project $PROJECT_ID
    
    DECLARE TOP_CLV_RATIO FLOAT64 DEFAULT @TOP_CLV_RATIO;
    
    SELECT
      p.customer_id,
      monetary_future,
      c.email AS email
    FROM (
      SELECT
        customer_id,
        monetary_future,
        PERCENT_RANK() OVER (ORDER BY monetary_future DESC) AS percent_rank_monetary
      FROM
        `clv.predictions` ) p
    INNER JOIN (
      SELECT
        customer_id,
        email
      FROM
        `clv.customers` ) c
    ON
      p.customer_id = c.customer_id
    WHERE
      -- Decides the size of your list of emails. For similar-audience use cases
      -- where you need to find a minimum of matching emails, 20% should provide
      -- enough potential emails.
      percent_rank_monetary <= TOP_CLV_RATIO
    ORDER BY monetary_future DESC
    
  3. Veja uma amostra dos dados do df_top_ltv. Para isso, copie o código a seguir para a próxima célula vazia do notebook e execute-o:

    df_top_ltv.head(5)
    

    Os resultados serão semelhantes aos exibidos abaixo:

    Primeiras cinco linhas dos principais clientes por dados de CLV.

Criar o arquivo de configuração do Google Ads

Crie o arquivo de configuração YAML para o cliente do Google Ads.

  1. Defina as variáveis de arquivo YAML que controlam o acesso à API Google Ads substituindo as variáveis de marcador abaixo pelos valores apropriados para o ambiente. Consulte Requisitos da integração com o Google Ads para informações sobre como receber os tokens e as credenciais do OAuth necessários, caso ainda não os tenha.

    Copie o seguinte código na próxima célula vazia do notebook e execute-o:

    DEVELOPER_TOKEN = "myDeveloperToken"
    OAUTH_2_CLIENT_ID = "myClientId"
    CLIENT_SECRET = "myClientSecret"
    REFRESH_TOKEN = "myRefreshToken"
    
  2. Para criar o conteúdo do arquivo YAML, copie o código a seguir na próxima célula vazia do notebook e execute-o.

    ADWORDS_FILE = "/tmp/adwords.yaml"
    
    adwords_content = f"""
    # AdWordsClient configurations
    adwords:
      #############################################################################
      # Required Fields                                                           #
      #############################################################################
      developer_token: {DEVELOPER_TOKEN}
      #############################################################################
      # Optional Fields                                                           #
      #############################################################################
      # client_customer_id: INSERT_CLIENT_CUSTOMER_ID_HERE
      # user_agent: INSERT_USER_AGENT_HERE
      # partial_failure: True
      # validate_only: True
      #############################################################################
      # OAuth2 Configuration                                                      #
      # Below you may provide credentials for either the installed application or #
      # service account flows. Remove or comment the lines for the flow you're    #
      # not using.                                                                #
      #############################################################################
      # The following values configure the client for the installed application
      # flow.
      client_id: {OAUTH_2_CLIENT_ID}
      client_secret: {CLIENT_SECRET}
      refresh_token: {REFRESH_TOKEN}
      # The following values configure the client for the service account flow.
      # path_to_private_key_file: INSERT_PATH_TO_JSON_KEY_FILE_HERE
      # delegated_account: INSERT_DOMAIN_WIDE_DELEGATION_ACCOUNT
      #############################################################################
      # ReportDownloader Headers                                                  #
      # Below you may specify boolean values for optional headers that will be    #
      # applied to all requests made by the ReportDownloader utility by default.  #
      #############################################################################
        # report_downloader_headers:
        # skip_report_header: False
        # skip_column_header: False
        # skip_report_summary: False
        # use_raw_enum_values: False
    
    # AdManagerClient configurations
    ad_manager:
      #############################################################################
      # Required Fields                                                           #
      #############################################################################
      application_name: INSERT_APPLICATION_NAME_HERE
      #############################################################################
      # Optional Fields                                                           #
      #############################################################################
      # The network_code is required for all services except NetworkService:
      # network_code: INSERT_NETWORK_CODE_HERE
      # delegated_account: INSERT_DOMAIN_WIDE_DELEGATION_ACCOUNT
      #############################################################################
      # OAuth2 Configuration                                                      #
      # Below you may provide credentials for either the installed application or #
      # service account (recommended) flows. Remove or comment the lines for the  #
      # flow you're not using.                                                    #
      #############################################################################
      # The following values configure the client for the service account flow.
      path_to_private_key_file: INSERT_PATH_TO_JSON_KEY_FILE_HERE
      # delegated_account: INSERT_DOMAIN_WIDE_DELEGATION_ACCOUNT
      # The following values configure the client for the installed application
      # flow.
      # client_id: INSERT_OAUTH_2_CLIENT_ID_HERE
      # client_secret: INSERT_CLIENT_SECRET_HERE
      # refresh_token: INSERT_REFRESH_TOKEN_HERE
    
    # Common configurations:
    ###############################################################################
    # Compression (optional)                                                      #
    # Below you may specify whether to accept and automatically decompress gzip   #
    # encoded SOAP requests. By default, gzip compression is not enabled.         #
    ###############################################################################
    # enable_compression: False
    ###############################################################################
    # Logging configuration (optional)                                            #
    # Below you may specify the logging configuration. This will be provided as   #
    # an input to logging.config.dictConfig.                                      #
    ###############################################################################
    # logging:
      # version: 1
      # disable_existing_loggers: False
      # formatters:
        # default_fmt:
          # format: ext://googleads.util.LOGGER_FORMAT
      # handlers:
        # default_handler:
          # class: logging.StreamHandler
          # formatter: default_fmt
          # level: INFO
      # loggers:
        # Configure root logger
        # "":
          # handlers: [default_handler]
          # level: INFO
    ###############################################################################
    # Proxy configurations (optional)                                             #
    # Below you may specify an HTTP or HTTPS Proxy to be used when making API     #
    # requests. Note: You must specify the scheme used for the proxy endpoint.    #
    #                                                                             #
    # For additional information on configuring these values, see:                #
    # http://docs.python-requests.org/en/master/user/advanced/#proxies            #
    ###############################################################################
    # proxy_config:
      # http: INSERT_HTTP_PROXY_URI_HERE
      # https: INSERT_HTTPS_PROXY_URI_HERE
      # If specified, the given cafile will only be used if certificate validation
      # is not disabled.
      # cafile: INSERT_PATH_HERE
      # disable_certificate_validation: False
    ################################################################################
    # Utilities Included (optional)                                                #
    # Below you may specify whether the library will include utilities used in the #
    # user agent. By default, the library will include utilities used in the user  #
    # agent.                                                                       #
    ################################################################################
    # include_utilities_in_user_agent: True
    ################################################################################
    # Custom HTTP headers (optional)                                               #
    # Specify one or more custom headers to pass along with all requests to        #
    # the API.                                                                     #
    ################################################################################
    # custom_http_headers:
    #   X-My-Header: 'content'
    """
    
  3. Para preencher o arquivo YAML, copie o seguinte código na próxima célula vazia do notebook e execute-o.

    with open(ADWORDS_FILE, "w") as adwords_file:
        print(adwords_content, file=adwords_file)
    

Criar uma lista de remarketing do Google Ads

Use os e-mails dos principais clientes de CLV para criar uma lista de remarketing do Google Ads.

  1. Para criar uma lista com os e-mails dos principais clientes de CLV, copie o seguinte código para a próxima célula vazia do notebook e execute-o:

    ltv_emails = list(set(df_top_ltv['email']))
    
  2. Para criar a lista de remarketing, copie o código a seguir para a próxima célula vazia do notebook e execute-o:

    """Adds a user list and populates it with hashed email addresses.
    
    Note: It may take several hours for the list to be populated with members. Email
    addresses must be associated with a Google account. For privacy purposes, the
    user list size will show as zero until the list has at least 1000 members. After
    that, the size will be rounded to the two most significant digits.
    """
    
    import hashlib
    import uuid
    
    # Import appropriate modules from the client library.
    from googleads import adwords
    
    def main(client):
      # Initialize appropriate services.
      user_list_service = client.GetService('AdwordsUserListService', 'v201809')
    
      user_list = {
          'xsi_type': 'CrmBasedUserList',
          'name': 'Customer relationship management list #%d' % uuid.uuid4(),
          'description': 'A list of customers that originated from email addresses',
          # CRM-based user lists can use a membershipLifeSpan of 10000 to indicate
          # unlimited; otherwise normal values apply.
          'membershipLifeSpan': 30,
          'uploadKeyType': 'CONTACT_INFO'
      }
    
      # Create an operation to add the user list.
      operations = [{
          'operator': 'ADD',
          'operand': user_list
      }]
    
      result = user_list_service.mutate(operations)
      user_list_id = result['value'][0]['id']
    
      emails = ['customer1@example.com', 'customer2@example.com',
                ' Customer3@example.com ']
      members = [{'hashedEmail': NormalizeAndSHA256(email)} for email in emails]
    
      # Add address info.
      members.append({
          'addressInfo': {
              # First and last name must be normalized and hashed.
              'hashedFirstName': NormalizeAndSHA256('John'),
              'hashedLastName': NormalizeAndSHA256('Doe'),
              # Country code and zip code are sent in plaintext.
              'countryCode': 'US',
              'zipCode': '10001'
          }
      })
    
      mutate_members_operation = {
          'operand': {
              'userListId': user_list_id,
              'membersList': members
          },
          'operator': 'ADD'
      }
    
      response = user_list_service.mutateMembers([mutate_members_operation])
    
      if 'userLists' in response:
        for user_list in response['userLists']:
          print('User list with name "%s" and ID "%d" was added.'
                % (user_list['name'], user_list['id']))
    
    def NormalizeAndSHA256(s):
      """Normalizes (lowercase, remove whitespace) and hashes a string with SHA-256.
    
      Args:
        s: The string to perform this operation on.
    
      Returns:
        A normalized and SHA-256 hashed string.
      """
      return hashlib.sha256(s.strip().lower()).hexdigest()
    
    if __name__ == '__main__':
      # Initialize the client object with the config
      # file you created in the previous section.
      adwords_client = adwords.AdWordsClient.LoadFromStorage(ADWORDS_FILE)
      main(adwords_client)
    

Adicionar um público-alvo semelhante

Depois de criar a lista de remarketing, siga as instruções na documentação do Google Ads para Adicionar públicos-alvo semelhantes à sua segmentação.

Próximas etapas opcionais

Use as informações das seções a seguir para melhorar opcionalmente o desempenho do modelo e automatizar o fluxo de trabalho de ML.

Melhorar o modelo

Neste tutorial, mostramos uma abordagem possível para criar um modelo básico para prever o valor monetário futuro dos clientes. Se você decidiu investigar melhor essa abordagem, veja a seguir sugestões de melhorias ou testes:

  • Se você tiver muitos outliers nos dados, faça engenharia de dados adicional ou encontre dados de treinamento adicionais.
  • Tente abordagens diferentes para criar recursos. Para isso, os limites do período de tempo ou altere a proporção de entrada para transações de destino.
  • Ao comparar modelos, use o mesmo conjunto de dados de teste para comparar de maneira justa o desempenho dos modelos. Por exemplo, este tutorial prepara os dados para prever melhor os pedidos dos próximos 30 dias. Se você quiser que um modelo preveja o próximo trimestre, atualize o parâmetro LENGTH_FUTURE e recalcula os atributos.
  • O conjunto de dados de exemplo usa um número limitado de campos. Se você tiver outras dimensões, como categorias de produtos, regiões geográficas ou informações demográficas nos seus próprios dados, tente criar mais atributos para o modelo.

Automatizar o fluxo de trabalho de ML

Nas etapas anteriores, você aprendeu a usar o BigQuery e o BigQuery ML para preparar dados para machine learning, criar e treinar um modelo, receber previsões e preparar dados para a integração do Google Ads.

Em um caso de uso de produção, todas as tarefas seriam recorrentes. É possível executar essas etapas manualmente, mas recomendamos que você automatize o processo. Este tutorial tem um código complementar no GitHub que fornece um conjunto de procedimentos armazenados do BigQuery para automatizar essas etapas, além de um script de shell, run.sh (ambos em inglês), que você pode usar para executá-los.

Use os seguintes parâmetros ao chamar o script run.sh para configurá-lo para funcionar em seu ambiente:

Variável Descrição Padrão
PROJECT_ID ID do projeto Obrigatório
DATASET_ID ID do conjunto de dados Obrigatório
TRAIN_MODEL_ID Nome do modelo treinado Defina como *null* se você não quiser treinar um modelo. String baseada em tempo.
USE_MODEL_ID Nome do modelo a ser usado para predições. Precisa incluir um conjunto de dados: [DATASET].[MODEL] String baseada em tempo.
WINDOW_LENGTH Período em dias para transações de entrada. 0
WINDOW_STEP Tempo em dias entre dois períodos. Equivalente ao tempo entre duas datas limite. 30
WINDOW_STEP_INITIAL Tempo inicial em dias antes de definir a primeira data limite. 90
LENGTH_FUTURE Tempo em dias para fazer uma previsão. 30
MAX_STDV_MONETARY Desvio padrão do valor monetário por cliente acima do qual o script remove transações. 500
MAX_STDV_QTY Desvio padrão do valor de quantidade por cliente acima do qual o script remove transações. 100
TOP_LTV_RATIO Porcentagem dos principais clientes a serem extraídos. 0,2

Siga estas etapas para usar o script run.sh na automação:

  1. Clone o repositório do GitHub:

    git clone https://github.com/GoogleCloudPlatform/analytics-componentized-patterns.git
    
  2. Atualize o script run.sh para definir os valores dos parâmetros de acordo com seu ambiente.

  3. Se você usar seus próprios dados de transação, atualize 10_procedure_match.sql para especificar as colunas apropriadas da tabela de transações.

  4. Ajuste as permissões no script run.sh para que você possa executá-lo:

    chmod +x run.sh
    
  5. Consulte a ajuda da linha de comando para mais informações sobre como definir os parâmetros:

    ./run.sh --help
    
  6. Execute o script:

    ./run.sh --project-id [YOUR_PROJECT_ID] --dataset-id [YOUR_DATASET_ID]
    

Em um caso de uso de produção, verifique com seus engenheiros de dados e sua equipe de DevOps para ver se eles podem integrar os procedimentos armazenados ao utilizar ferramentas para facilitar o uso.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto que contém os recursos ou mantenha o projeto, mas exclua apenas esses recursos.

Seja como for, remova esses recursos para que não sejam faturados no futuro. Nas seções a seguir, você verá como excluir esses recursos.

Excluir o projeto

A maneira mais fácil de eliminar o faturamento é excluir o projeto criado para o tutorial.

  1. No Console do Cloud, acesse a página Gerenciar recursos:

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir os componentes

Se você não quiser excluir o projeto, use as seguintes seções para excluir os componentes faturáveis deste tutorial.

Excluir o conjunto de dados e as tabelas do BigQuery

  1. Abra o console do BigQuery
  2. Na seção Recursos, expanda o projeto em que você fez este tutorial e selecione o conjunto de dados clv.
  3. Clique em Excluir conjunto de dados no cabeçalho do painel do conjunto de dados.
  4. Na janela de sobreposição que aparece, digite clv e clique em Excluir.

Excluir o AI Platform Notebooks

  1. Abrir a página do AI Platform Notebooks
  2. Marque a caixa de seleção da instância do notebook clv.
  3. Clique em Excluir.
  4. Na janela de sobreposição que aparece, clique em Excluir.

A seguir