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.

Read My Stories

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

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

State of the Noonion: A New Era For Brands and Writers

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

State of the Noonion: A New Era For Brands and Writers

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps