Neste artigo, descreverei um método relativamente simples para lançar um recurso de cross-sell (produtos oferecidos a um cliente além dos que estão no carrinho) no comércio eletrônico, como mantimentos ou serviços de entrega de comida, que implementamos com sucesso em o aplicativo móvel "Mnogo Lososya". Este é um sistema básico de recomendação de filtragem colaborativa que combina abordagens baseadas em usuário e itens e pode ser usado em uma variedade de projetos de comércio eletrônico, particularmente aqueles com um grande número de SKUs, para fornecer uma ampla gama de recomendações.
A Mnogo Lososya, fundada em 2018, é uma rede de mais de 50 cozinhas fantasmas e mais de 250 cozinhas para viagem, além de uma marca abrangente para vários conceitos de pratos. Nosso ponto de venda exclusivo é a entrega em 30 minutos de refeições preparadas na hora. Temos expandido rapidamente e recentemente ultrapassamos 100.000 aplicativos MAU com mais de 100 milhões de RUB em receita mensal bruta.
A maioria de nossos pedidos é feita online, com um terço vindo de nosso próprio aplicativo móvel e os outros dois terços vindo de serviços de entrega. A app é uma componente importante do nosso produto porque é um dos primeiros pontos de contacto, o que, juntamente com o nosso serviço e a própria comida, contribui para uma melhor experiência do cliente.
Esta solução foi construída inteiramente nos serviços Yandex Cloud, mas também pode ser construída na AWS porque também possui todos os serviços necessários. Estou designando serviços em termos de notação da AWS para a conveniência dos usuários da AWS, o que também deve ser claro para muitos usuários do YC.
A arquitetura simplificada fica assim:
Os usuários fazem pedidos por meio do aplicativo móvel. No sistema ERP, os pedidos são criados e processados.
Os pedidos são então copiados para o data warehouse durante um processo ETL uma vez por dia à noite. Cada pedido inclui informações sobre os produtos solicitados, bem como o identificador do cliente.
Os procedimentos SQL calculam as preferências do usuário e a similaridade do produto. Uma descrição mais detalhada do cálculo é fornecida abaixo. A computação produz duas coleções no MongoDB com a seguinte estrutura:
coleção userPref
Telefone: Usamos “telefone” como um identificador de usuário.
pratos relacionados
últimaAtualização. Data e hora do último recálculo
Exemplo de documento:
coleção productSimilarity
pratoId
pratos relacionados
lastUpdateDate: Data e hora do último recálculo
Exemplo de um documento
Implementamos as preferências do usuário com base no histórico de vendas ponderado, com as vendas recentes tendo prioridade. Considere o seguinte histórico de vendas arbitrário do usuário:
produtos | Vendas | Quando | Coef de tempo (1/meses) | Vendas ponderadas |
---|---|---|---|---|
A | 1 | este mês | 1 | 1 |
B | 1 | este mês | 1 | 1 |
C | 4 | 1 mês atrás | 0,5 | 2 |
A | 4 | 1 mês atrás | 0,5 | 2 |
B | 3 | há 4 meses | 0,25 | 0,75 |
O usuário comprou o produto B e o produto C quatro vezes. No entanto, como a maioria das vendas do produto B ocorreu há quatro meses, priorizamos as vendas mais recentes do produto C. Os produtos são classificados pelo total de vendas ponderadas, que são a soma das vendas ponderadas de cada produto.
produtos | Total de vendas ponderadas | Classificação |
---|---|---|
A | 3 | 1 |
B | 1,75 | 3 |
C | 2 | 2 |
O exemplo acima implica que o usuário prefere o produto A ao produto C e o produto C ao produto B.
O número de pedidos em que pares de produtos estavam presentes é usado para calcular a similaridade do produto. O resultado é calculado separadamente para cada mês, com prioridade para os meses mais recentes. Como resultado, classificamos produtos semelhantes para cada produto e os armazenamos no MongoDB, onde o ID do produto é um índice para a coleção.
A lista de recomendação de produtos resultante combina as preferências do usuário e produtos similares e os classifica de acordo com alguma estratégia, que é a classificação ascendente por classificação. Como resultado, simplesmente combinamos todas as listas de produtos relacionados e as classificamos. Calculamos a classificação média para produtos repetidos. Aqui está um exemplo:
Escolhemos as seguintes métricas para medir a eficiência da venda cruzada:
O valor médio do pedido (AOV) dos pedidos que incluíram pratos de venda cruzada foi maior do que o AOV dos pedidos que não incluíram. A soma total de todos os produtos do pedido é o valor do pedido, que é quanto o cliente paga pelo pedido. Portanto, essa métrica indica se os clientes pagam mais por pedidos que incluem pratos de venda cruzada. Essa é a métrica principal porque o aumento no AOV é exatamente o que esperamos da venda cruzada.
Porcentagem de mercadorias adicionadas da seção de venda cruzada no total de mercadorias vendidas . Essa é uma métrica secundária fortemente influenciada pela natureza dos produtos vendidos, bem como pela estratégia de venda cruzada. Considere uma loja de comércio eletrônico de eletrônicos que vende suplementos de baixo custo, como malas e cabos de carregamento, para itens mais caros no carrinho, como smartphones e laptops. Muitos suplementos podem ser vendidos para um item principal neste caso, e a métrica pode exceder 50%. Embora nosso exemplo não inclua uma grande variedade de suplementos, essa métrica demonstra como a venda cruzada afeta a estrutura final do carrinho.
Porcentagem de pedidos contendo pratos de venda cruzada . Essa é outra métrica secundária que exibe a "popularidade" da venda cruzada ou com que frequência os clientes compram produtos recomendados para venda cruzada.
O conjunto de dados abaixo contém dados de pedidos impessoais coletados de dezembro de 2022 a janeiro de 2023 em uma das cidades de operações da MnogoLososya.
https://github.com/alexchrn/cross-sell/blob/main/orders.csv
O conjunto de dados é compilado a partir de uma variedade de fontes, incluindo AppMetrica (eventos de adição ao carrinho) e o sistema ERP (status de pedidos e pagamentos, descontos e valores de pagamento).
Estrutura do conjunto de dados:
Aqui estão os valores das métricas (derivados do conjunto de dados acima usando python).
A porcentagem de pratos adicionados da seção de venda cruzada no total de pratos comprados – 3,97%
A porcentagem de pedidos contendo pratos de venda cruzada – 10,46%
AOV de pedidos que incluíram pratos de venda cruzada em comparação com AOV de pedidos que não:
Como pode ser visto, os pedidos com pratos de venda cruzada têm um AOV maior com uma diferença de 565 RUB. A quantidade média de pratos nesses pedidos também é maior, o que é razoável considerando que o único objetivo do cross-selling é incentivar o cliente a adicionar mais pratos ao carrinho.
A diferença de 565 é significativa? Podemos usar um teste t para ver se essa diferença se deve ao acaso. A biblioteca scripty do Python tem um método para isso. Este é um teste para a hipótese nula de que 2 amostras independentes têm valores médios (esperados) idênticos (1).
Assim, o valor-p, ou probabilidade da hipótese nula ser verdadeira, é extremamente baixo e rejeitamos a hipótese nula mesmo no nível de significância de 99%. Em outras palavras, é quase certo que a diferença notável no valor médio do pedido não é coincidência, e os pedidos com refeições de venda cruzada geram mais receita.
A venda cruzada pode ser uma ferramenta eficaz para aumentar o valor médio do pedido, mesmo com técnicas simples de filtragem colaborativa. Ele também pode ser implementado com relativa facilidade do ponto de vista técnico, graças aos serviços sem servidor da AWS e de outros provedores de nuvem, conforme mostrado neste artigo.
Materiais relacionados: