Estratégia de desconto comercial: onde o valor é criado e onde é silenciosamente destruído

Uma estratégia de desconto comercial apoiada por aprendizagem automática pode transformar decisões de preços causais.

A maioria dos descontos comerciais destrói valor. Os relatórios simplesmente falham em demonstrá-lo. Quando as vendas aumentam após uma campanha, a conclusão parece óbvia: o desconto funcionou. A receita subiu, a conversão melhorou. O painel de controlo confirma a intuição. É aqui que uma estratégia de desconto comercial falha frequentemente — otimiza para a receita visível em vez da margem incremental. Mas este raciocínio assenta na frágil premissa de que os clientes que receberam o desconto compraram mais do que aqueles que não o receberam.

Essa não é a questão… A questão é encontrar quais são os clientes com maior probabilidade de comprar se lhes for dado um desconto. E aqueles que comprariam de qualquer forma, mesmo sem ele. Com esse conhecimento, é finalmente possível direcionar os esforços da campanha para onde esta é mais eficaz.

E o que torna isto particularmente desconfortável é que o mesmo erro se repete muito para além da definição de preços.

Nos recursos humanos, um programa de formação é declarado um sucesso porque o desempenho melhorou posteriormente. Mas talvez tenham sido selecionados para participar os colaboradores mais motivados. A melhoria reflete o potencial prévio, e não a formação em si.

Nas finanças, uma iniciativa de redução de custos é elogiada porque as margens aumentaram. Mas quais teriam sido as margens sem ela? Terão sido as condições de mercado externas as responsáveis? Ou a procura já estava em recuperação?

Compreendeu a ideia: se o resultado observado nas métricas de "business-as-usual" melhora, assume-se que a decisão foi boa. Não, nem sempre é assim!

O que falta em todos estes casos é uma questão causal. Separar a causa e o efeito da correlação. Separar os resultados das decisões da qualidade das mesmas.

A análise causal começa com uma ideia simples, mas exigente: cada decisão cria duas realidades possíveis. Uma em que a ação é tomada, e outra em que não é. Apenas observamos uma delas. A outra permanece oculta.

Na fixação de preços, este mundo oculto é decisivo. Para qualquer cliente, existem dois resultados potenciais:

• A probabilidade de compra se oferecermos um desconto.
• A probabilidade de compra se não o fizermos.

Apenas chegamos a ver um destes resultados. Se oferecermos o desconto, observamos se o cliente compra. Não podemos observar simultaneamente o que esse mesmo cliente teria feito ao preço total.

A análise causal tenta estimar esse cenário em falta. Reformula a questão da fixação de preços de:

As vendas aumentaram após o desconto?

para:

Quanto é que o desconto alterou a probabilidade de compra para este cliente específico?

A parte interessante é que resolver isto não requer dados exóticos, uma nova plataforma de IA ou um programa de transformação massivo. A maioria das organizações já tem o que é necessário.

Os dados já estão lá.

Para demonstrar esta abordagem, estou a recolher dados de um sistema CRM standard para o Dataverse. Vamos analisar as tabelas de dados mais interessantes.

Perfil de Compra do Cliente

Esta é a tabela mestre de clientes. Contém uma linha por cliente (cliente_id) com atributos estruturais e comportamentais extraídos do CRM e do histórico de transações.

• Segmento e canal: segmento, canal_preferencial descrevem o perfil comercial (ex: PME, Online).
• Recência e frequência: recencia, frequencia captam a recência e a intensidade de compra.
• Valor monetário: valor_medio reflete o valor médio do pedido.
• Sensibilidade ao preço: price_elasticity estima quão responsivo o cliente é a descontos.
• Comportamento do cesto: basket_size_score aproxima a profundidade de cross-sell.
• Sinais comportamentais: purchase_intent, brand_loyalty, promo_fatigue quantificam a propensão de compra, a fidelidade à marca e a saturação de promoções.
• Metadados técnicos: dataset_version, generated_at permitem a reprodutibilidade e a rastreabilidade do modelo.

Esta é a matéria-prima para o raciocínio causal. A maioria destes indicadores não é importada de sistemas externos. Eles são processados diretamente a partir do histórico transacional. A recência é simplesmente o número de dias desde a última compra. A frequência conta as transações num período definido. O valor médio do pedido é calculado a partir das faturas já armazenadas no CRM.

Até a elasticidade do preço não é observada diretamente. É inferida a partir do comportamento. Se um cliente compra consistentemente quando existem descontos e raramente ao preço total, os dados revelam um padrão de dependência do preço. Se o comportamento de compra permanece estável independentemente da promoção, o sinal aponta para uma inelasticidade relativa. Estes não são constructos teóricos. São padrões empíricos incorporados nas transações históricas.

O mesmo se aplica aos indicadores comportamentais, tais como a fidelidade à marca ou a saturação de promoções. A fidelidade pode ser aproximada através da concentração de compras repetidas em categorias de produtos ou marcas. A saturação de promoções surge quando as taxas de resposta diminuem após a exposição repetida a incentivos.

Registo de Impacto da Campanha

Esta tabela regista a exposição do cliente a ações comerciais. Contém uma linha por cliente, por evento de campanha, e define o que, em termos causais, chamamos de tratamento.

• Referência do cliente: cliente_id liga cada registo ao mestre de clientes.
• Indicador de tratamento: impactado indica se o cliente foi exposto à campanha (1) ou não (0).
• Tipo de campanha: tipo_campanha diferencia ações como desconto ou pacote (bundle).
• Data da campanha: data_campanha fixa a intervenção no tempo.
• Intensidade do desconto: discount_depth capta a percentagem de desconto aplicada (ex: 0,15 = 15%).
• Metadados técnicos: dataset_version, generated_at garantem a rastreabilidade e a reprodutibilidade.

Esta tabela é mais importante do que parece à primeira vista.

A maioria dos sistemas de relatórios trata as campanhas como contexto. Na modelação causal, elas tornam-se estrutura. O indicador de tratamento (treatment flag) não é apenas uma informação descritiva, mas sim o pivot em torno do qual toda a análise gira.

O registo da campanha torna a intervenção explícita. Diz-nos quem foi exposto, quando ocorreu a exposição e com que intensidade. Essa fixação temporal é crucial. Permite-nos alinhar o comportamento antes e depois da intervenção e separar padrões pré-existentes de potenciais mudanças comportamentais.

Em termos práticos, esta tabela transforma uma ação de marketing num tratamento mensurável. Sem ela, apenas observa resultados (outcomes). Com ela, pode começar a estimar o impacto incremental.

Registo de Compras do Cliente

Esta tabela regista o resultado comercial após a exposição à campanha. Contém uma linha por cliente, por observação de compra, e define a variável de resposta para a modelação de uplift.

• Referência do cliente: cliente_id liga cada transação ao mestre de clientes (customer master).
• Indicador de compra: comprou é uma flag binária (1/0) que indica se ocorreu uma transação.
• Receita: valor_compra capta o valor da transação.
• Margem: margem reflete a contribuição bruta gerada pela compra.
• Data da compra: data_compra ancora o resultado no tempo, permitindo o alinhamento com a exposição à campanha.
• Metadados técnicos: dataset_version garante a consistência e a reprodutibilidade do conjunto de dados.

Sozinha, esta tabela é o que a maioria das organizações utiliza para avaliar o desempenho das campanhas. Diz-nos quem comprou, quanto gastou e quanta margem foi gerada. A partir daqui, os dashboards computam taxas de conversão, aumento de faturação e contribuição por campanha.

Mas em termos causais, esta tabela ganha significado apenas quando combinada com o registo de tratamento. O indicador de compra diz-nos o que aconteceu, enquanto a tabela de campanha nos diz quem foi exposto.

Tabela Análise de Compras do Cliente

This is the decision table generated by the model. It contains one row per customer per model run and stores the analytical output required for operational targeting.

• Referência do cliente: Cliente_ID (lookup) liga a análise à tabela de perfil do cliente. Esta é a chave de ligação (binding key) para a execução.
• dentificador primário: cliente_id armazena o código de cliente legível.
• Sinalizadores de tratamento e resultado: impactado e comprou permitem a validação face à exposição observada à campanha e à compra realizada.
• Contexto comportamental: campos como frequencia e canal_preferencial conferem interpretabilidade para segmentação e filtragem.
• Versão do modelo: ModelVersion garante a reprodutibilidade e a iteração controlada entre as execuções de pontuação (scoring runs).
• Metadados do sistema: os campos de criação e modificação garantem a auditabilidade por conceção (auditability by design).

Até este ponto, descrevemos clientes, intervenções e resultados. Aqui, introduzimos os contrafactuais estimados. Para cada cliente, o modelo armazena a probabilidade prevista de compra com e sem desconto, e a diferença entre ambas. Essa diferença é o efeito incremental estimado.

Ao contrário das tabelas transacionais, esta tabela não regista o que aconteceu. Ela regista o que se espera que aconteça caso intervenhamos.

Conceptualmente, isto converte a previsão em governação. Define:

• quem tem probabilidade de gerar margem incremental,
• quem é indiferente ao desconto,
• quem compraria de qualquer forma,
• e quem pode até reagir negativamente.

Como isto é armazenado diretamente no Dataverse, ligado à entidade de cliente e versionado por execução de modelo, pode ser utilizado imediatamente na lógica de campanha. As listas de público-alvo já não são construídas apenas com base em taxas de conversão passadas, mas sim na mudança comportamental estimada.

O Dataverse SDK para Python

Antes de treinar o modelo, a camada de dados deve estar operacional. Todo o pipeline lê e escreve de volta no Dataverse utilizando o Dataverse SDK para Python.

O primeiro passo é a configuração. Define o URL do ambiente Dataverse, autentica-se via Azure AD (através de um service principal ou login delegado) e armazena as credenciais de forma segura em variáveis de ambiente ou num ficheiro. Uma vez configurado, o SDK permite que o script de treino consulte as tabelas de entrada diretamente: clientes, exposição a campanhas e resultados. Posteriormente, permite escrever os resultados da pontuação (scoring) de volta no Tabela Análise de Compras do Cliente .

Esta integração não é cosmética. Ela garante que:

• Os dados de treino são extraídos do mesmo sistema operacional utilizado pelo negócio.
• Não são necessárias exportações manuais de CSV.
• Os resultados do modelo são escritos de volta em tabelas governadas, com versionamento e registos temporais.

Em termos práticos, o SDK atua como a ponte entre a camada analítica e a camada operacional do CRM. Ele permite que o modelo se comporte como um componente nativo do sistema empresarial, em vez de uma experiência isolada.

Note que, para efeitos desta demonstração, o treino está a ser feito diretamente a partir do Dataverse; em escala, eu provavelmente prepararia o conjunto de treino num lakehouse.

Em termos arquiteturais: o Dataverse é perfeito para a demonstração operacional e para as fases iniciais de produção. Quando o volume aumenta, preparam-se os dados de treino num lakehouse para obter um armazenamento mais económico, um histórico mais alargado e pipelines de atributos (features) mais pesados, mantendo o Dataverse como o repositório operacional governado para entidades e decisões.

Em produção, a arquitetura é intencionalmente simples. O Dataverse continua a ser o sistema de registo para perfis de clientes, exposição a campanhas e resultados de compras. Um trabalho de computação agendado (uma Azure Function com temporizador) lê essas tabelas, constrói o conjunto de treino para uma janela temporal definida, treina e pontua um modelo de uplift, e escreve os resultados de volta numa tabela de análise dedicada, versionada por SnapshotDate e ModelVersion. O Power BI é então utilizado para monitorizar duas coisas que os dashboards de faturação não conseguem: se a campanha alterou o comportamento dos clientes visados e se esse comportamento incremental gerou margem. A demonstração treina diretamente a partir do Dataverse; em escala, o mesmo conjunto de treino pode ser preparado num lakehouse sem alterar o contrato operacional.

O processo de treino de machine learning

Uma vez configurado o acesso aos dados, o processo de treino segue uma sequência estruturada.

Primeiro, o pipeline obtém três conjuntos de dados observáveis do Dataverse: atributos do cliente, exposição à campanha (indicador de tratamento) e o resultado de compra realizado. Estes são fundidos num único conjunto de dados de modelação utilizando o identificador do cliente como chave.

Crucialmente, apenas a informação disponível antes da decisão da campanha é utilizada como entrada do modelo. Variáveis pós-tratamento, tais como a receita realizada ou a margem, são excluídas. Isto evita a fuga de dados (data leakage) e preserva a validade causal.

O conjunto de dados é então dividido em partições de treino e de teste. A divisão é estratificada pelo estado de tratamento para preservar o equilíbrio entre clientes tratados e não tratados.

Em seguida, são treinados dois modelos distintos:

• um utilizando apenas clientes que não foram visados pela campanha,
• e outro utilizando apenas aqueles que foram expostos.

Cada modelo aprende a probabilidade de compra condicional aos atributos observados dentro do seu respetivo grupo.

Após o treino, ambos os modelos são aplicados ao conjunto de exclusão (hold-out). Para cada cliente, estimamos:

• Probabilidade de compra sem tratamento
• Probabilidade de compra com tratamento

A diferença entre estas duas probabilidades representa o uplift estimado.

Finalmente, os resultados da pontuação

Incluindo a estimativa de uplift, as probabilidades e os metadados do modelo são escritos de volta no Dataverse. Cada registo é etiquetado com a versão do modelo e a data do snapshot para garantir a rastreabilidade e a reprodutibilidade.

Nesta fase, o sistema produz não apenas previsões, mas resultados estruturados e prontos para a tomada de decisão, incorporados diretamente no modelo de dados operacional.

A arquitetura de aprendizagem por trás do modelo (leia-se: o algoritmo)

A ideia central é simples mas poderosa: não estamos a tentar prever quem irá comprar.
Estamos a tentar estimar o que muda por causa da intervenção.

Para o fazer, o processo de treino segue uma estrutura clássica de T-Learner.

Em vez de ajustarmos um único modelo preditivo, treinamos dois modelos independentes:

• Um modelo estima a probabilidade de compra para os clientes que não foram expostos à campanha.
• Um segundo modelo estima a probabilidade de compra para os clientes que foram expostos.

Cada modelo aprende a sua própria função de resposta condicional. Em termos estatísticos, estamos a aproximar:

• P(Y = 1 | X, T = 0)
• P(Y = 1 | X, T = 1)

Onde:

• X representa as características do cliente disponíveis antes da decisão.
• T é o indicador de tratamento.
• Y é o resultado da compra.

O uplift é então calculado como a diferença entre estas duas estimativas para cada cliente:

Uplift(X) = P̂(Y = 1 | X, T = 1) −P̂(Y = 1 | X, T = 0)

Esta estrutura permite-nos simular dois mundos paralelos para cada indivíduo:

• A world where the customer receives the discount.
• A world where the customer does not.

The difference between these two simulated probabilities is what drives the decision.

Por que dois modelos?

Porque o tratamento altera fundamentalmente o processo de geração de dados. Os clientes que foram expostos a um desconto não são estatisticamente idênticos àqueles que não foram. O viés de segmentação, as diferenças comportamentais e a lógica comercial influenciam quem recebe o tratamento. Treinar modelos separados permite que cada superfície de resposta seja aprendida de forma independente, em vez de forçar um único modelo a inferir implicitamente a interação.

Isto torna a abordagem:

• Mais flexível
• Mais transparente
• Mais fácil de diagnosticar.
• Mais robusta em produção.

Escolha do modelo.

A implementação utiliza um classificador de gradient boosting concebido para dados tabulares estruturados. Este tipo de modelo é adequado para sinais comportamentais heterogéneos: frequência, recência, proxies de elasticidade de preço, indicadores de fidelização e pertença a segmentos, sem exigir uma engenharia de atributos (feature engineering) manual extensiva.

Os modelos de boosting lidam com:

• Interações não-linearidades.
• Efeitos de limiar
• Entradas mistas numéricas e categóricas.
• Desequilíbrio de classes moderado.

É importante notar que o resultado é probabilístico. O modelo produz probabilidades de compra calibradas em vez de rótulos binários (0 ou 1). Isto é essencial para a estimativa de uplift.

Da previsão à decisão.

O processo de treino não termina com o ajuste do modelo

Após a pontuação do conjunto de retenção , calculamos:

• Probabilidade estimada sem tratamento
• Probabilidade estimada com tratamento
• Uplift Estimado

Estes resultados são gravados novamente no Dataverse como campos estruturados, juntamente com a versão do modelo e a data do snapshot.

At this point, the system is no longer a machine learning experiment. It becomes a decision layer embedded in the operational CRM.

As equipas comerciais podem agora:

• Direcionar apenas para clientes com uplift positivo
• Excluir os "Garantidos", que comprariam de qualquer forma.
• Evitar os "Cães Adormecidos", cuja probabilidade de compra diminui com o desconto ou o contacto.
• Classificar os clientes pelo valor incremental esperado.

Este é o momento em que a modelação deixa de ser descritiva e passa a ser prescritiva.

O reporte – o funcionamento habitual

Esta é a forma como poderíamos começar por desenhar o nosso relatório no Power BI.

Os painéis acima descrevem a base de clientes com precisão. Sabemos quantos clientes temos, como estão distribuídos pelos segmentos, quais os canais dominantes, com que frequência compram e qual o valor médio de cada encomenda.

Podemos observar que 60% dos clientes receberam pelo menos um desconto durante o ano. Verificamos volumes de compra mensais estáveis e conseguimos comparar segmentos e as respetivas contribuições para a receita.

Nada aqui está errado e estes painéis são, de facto, úteis. Eles fornecem a clareza estrutural necessária e ajudam as operações; é apenas isso.

Desta perspectiva, uma campanha que aumenta a receita parece bem-sucedida. Um segmento com um valor médio de encomenda mais elevado parece mais atrativo. Uma curva mensal estável transmite segurança.

No entanto, em lado nenhum nesta página conseguimos ver se o desconto alterou, de facto, o comportamento do cliente. Em lado nenhum conseguimos medir se foi criada margem ou se esta foi silenciosamente sacrificada.

O modelo em acção

A diferença entre correlação e causalidade é financeira. Quando os descontos são avaliados através das vendas agregadas, o "sucesso" é quase garantido. As vendas aumentam. Os clientes compram. A campanha parece eficaz. Mas assim que estimamos o contrafactual (o que teria acontecido sem o desconto), o cenário muda. Alguns clientes teriam comprado de qualquer forma. Outros não comprariam a preço nenhum. Apenas um subconjunto altera verdadeiramente o seu comportamento devido ao incentivo.

Esse subconjunto define o valor incremental. A segmentação por uplift torna isto visível. Persuadíveis: Geram procura incremental real. Garantidos (Sure Things): Inflacionam o desempenho reportado. Cães Adormecidos (Sleeping Dogs): Destroem silenciosamente a margem. Causas Perdidas: Consomem orçamento sem qualquer retorno.

A curva acumulada torna o custo-benefício (trade-off) explícito. O público-alvo expande-se. A receita sobe. Mas a margem incremental atinge o pico e, depois, declina. Para além desse ponto, já não estás a comprar crescimento. Estás a subsidiar um comportamento que teria ocorrido de qualquer forma.

Esta é a conclusão desconfortável:

A maioria dos descontos comerciais não falha por serem mal concebidos. Falham porque são avaliados incorretamente.

A análise causal não otimiza campanhas. Ela restaura a disciplina na tomada de decisão. E assim que passas a ver o valor em termos incrementais, torna-se muito difícil voltar a painéis (dashboards) que medem a atividade em vez do impacto.

Em última análise, uma estratégia de descontos comerciais só cria valor quando está fundamentada em evidência causal.

Construir uma estratégia robusta de descontos comerciais exige mais do que painéis de controlo — exige equipas que compreendam o raciocínio causal e a modelação de dados.

É por isso que desenhamos soluções personalizadas. programas de formação em Business Intelligence e IA aplicada. para ajudar as empresas a tomar melhores decisões de preços e de margem.