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. Arquitetura 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. MongoDB gerenciado função lambda Gateway de API Nuvem DNS Back-end móvel (nuvem de computação) 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 Usamos “telefone” como um identificador de usuário. Telefone: pratos relacionados id: ID de um prato relacionado classificação últimaAtualização. Data e hora do último recálculo Exemplo de documento: coleção productSimilarity pratoId pratos relacionados id: ID de um prato relacionado classificação lastUpdateDate: Data e hora do último recálculo Exemplo de um documento Quando um usuário atualiza o carrinho, o aplicativo envia uma solicitação para a função Lambda. A solicitação inclui o identificador do usuário (telefone) e uma lista de identificadores de produtos que estão atualmente no carrinho. O Lambda extrai pratos relacionados da coleção productSimilarity para cada refeição no carrinho e pratos relacionados pelo telefone fornecido da coleção userPref. O algoritmo lambda combina essas listas de pratos relacionados em uma e a envia de volta ao aplicativo móvel como uma lista de recomendações. No carrinho, o aplicativo renderiza os cartões de produto. Algoritmo Preferências de usuário 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. Similaridade do produto 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. Recomendaçã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: Suponha que um usuário agora tenha um carrinho com 2 produtos – A e B; Lambda seleciona um documento da coleção productSimilarity para o produto A. Pratos relacionados são C (classificação 1), D (classificação 2) e E (classificação 3); Lambda seleciona um documento da coleção productSimilarity para o produto B. Pratos relacionados são F (classificação 1), G (classificação 2) e H (classificação 3); O Lambda seleciona um documento da coleção userPref para o telefone fornecido. Os pratos relacionados são D (classificação 1) e H (classificação 2); Todos os pratos relacionados são combinados e, para pratos duplicados, a classificação média é calculada. A lista resultante é C (classificação 1), D (classificação 1,5), E (classificação 3), F (classificação 1), G (classificação 2) e H (classificação 2,5). Depois de classificar a lista é C, F, D, G, H e E, e voltou para o aplicativo. Resultado Métricas ou como medir o resultado Escolhemos as seguintes métricas para medir a eficiência da venda cruzada: 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. O valor médio do pedido (AOV) . 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 mercadorias adicionadas da seção de venda cruzada no total de mercadorias vendidas . 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. Porcentagem de pedidos contendo pratos de venda cruzada Resultados reais 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: pedido_id. Um identificador único de um pedido number_of_cross_sell_dishes. O número de pratos que foram adicionados na seção de venda cruzada. status. O último status de pedido conhecido. status do pagamento. O último status de pagamento conhecido pontos_número. O número de pontos de bônus que foram retirados em um pedido. 1 ponto é igual a 1 rublo. desconto_soma. O desconto em rublos, sem incluir pontos de bônus. pagamento_soma. Quanto um cliente pagou por um pedido criado em. Data e hora de criação de um pedido appmetrica_device_id. Identificador exclusivo do dispositivo app_version_name. Versão do aplicativo total_number_of_dishes. O número total de pratos em um pedido has_cross_sell_dish. Se um pedido contém pratos adicionados de vendas cruzadas. Este campo é calculado a partir de number_of_cross_sell_dishes. 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. Conclusão 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: https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Developers: Build Less. Deliver More. [Learn how]	

Venda cruzada em questões de comércio eletrônico: um guia técnico para upselling online

Muito longo; Para ler

Alexander Chernov

STORY’S CREDIBILITY

Code License

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

Venda cruzada em questões de comércio eletrônico: um guia técnico para upselling online

Muito longo; Para ler

Alexander Chernov

STORY’S CREDIBILITY

Code License

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

HISTÓRIAS RELACIONADAS