Bán chéo trong các vấn đề thương mại điện tử: Hướng dẫn kỹ thuật để bán thêm trực tuyến

Trong bài viết này, tôi sẽ mô tả một phương pháp tương đối đơn giản để triển khai tính năng bán chéo (các sản phẩm được cung cấp cho khách hàng ngoài những sản phẩm trong giỏ hàng) trong thương mại điện tử, chẳng hạn như cửa hàng tạp hóa hoặc dịch vụ giao đồ ăn, mà chúng tôi đã triển khai thành công trong ứng dụng di động "Mnogo Lososya". Đây là hệ thống đề xuất lọc cộng tác cơ bản kết hợp các phương pháp tiếp cận dựa trên người dùng và mặt hàng và có thể được sử dụng trong nhiều dự án thương mại điện tử, đặc biệt là những dự án có số lượng lớn SKU, để cung cấp nhiều đề xuất.

Mnogo Lososya, được thành lập vào năm 2018, là một chuỗi gồm hơn 50 nhà bếp ma và hơn 250 nhà bếp mang đi cũng như một thương hiệu ô cho nhiều khái niệm món ăn. Điểm bán hàng độc đáo của chúng tôi là giao các bữa ăn mới nấu trong vòng 30 phút. Chúng tôi đã nhanh chóng mở rộng và gần đây đã vượt qua 100 nghìn MAU ứng dụng với tổng doanh thu hàng tháng hơn 100 triệu RUB.

Phần lớn các đơn đặt hàng của chúng tôi được thực hiện trực tuyến, với một phần ba đến từ ứng dụng di động của chính chúng tôi và hai phần ba còn lại đến từ các dịch vụ giao hàng. Ứng dụng là một thành phần quan trọng trong sản phẩm của chúng tôi vì đây là một trong những điểm tiếp xúc đầu tiên, cùng với dịch vụ của chúng tôi và bản thân thực phẩm, góp phần mang lại trải nghiệm tốt hơn cho khách hàng.

Ngành kiến trúc

Giải pháp này được xây dựng hoàn toàn trên các dịch vụ Đám mây Yandex, nhưng nó cũng có thể được xây dựng trên AWS vì nó cũng có tất cả các dịch vụ cần thiết. Tôi đang chỉ định các dịch vụ theo ký hiệu AWS để thuận tiện cho người dùng AWS, điều này cũng rõ ràng đối với nhiều người dùng YC.

• MongoDB được quản lý
• hàm lambda
• Cổng API
• DNS đám mây
• Phụ trợ di động (đám mây điện toán)

Kiến trúc đơn giản hóa trông như thế này:

1. Người dùng đặt hàng thông qua ứng dụng di động. Trong hệ thống ERP, các đơn đặt hàng được tạo và xử lý.

2. Các đơn đặt hàng sau đó được sao chép vào kho dữ liệu trong quy trình ETL một lần mỗi ngày vào ban đêm. Mỗi đơn hàng bao gồm thông tin về sản phẩm đã đặt cũng như mã định danh khách hàng.

3. Các thủ tục SQL tính toán sở thích của người dùng và tính tương tự của sản phẩm. Một mô tả chi tiết hơn về tính toán được cung cấp dưới đây. Tính toán mang lại hai bộ sưu tập trong MongoDB với cấu trúc sau:

   
   

   bộ sưu tập userPref

   Điện thoại: Chúng tôi sử dụng “điện thoại” làm định danh người dùng.

   
   

   • món ăn liên quan

     • id: ID của một món ăn liên quan
     • thứ hạng

   • ngày cập nhật cuối cùng. Ngày và thời gian tính toán lại lần cuối

     
     

     Ví dụ về một tài liệu:

Bộ sưu tập sản phẩm tương tự

• ID món ăn

• món ăn liên quan

  • id: ID của một món ăn liên quan
  • thứ hạng

• lastUpdateDate: Ngày và thời gian tính toán lại lần cuối

  
  

Ví dụ về một tài liệu

4. Khi người dùng cập nhật giỏ hàng, ứng dụng sẽ gửi yêu cầu đến hàm Lambda. Yêu cầu bao gồm số nhận dạng người dùng (điện thoại) và danh sách số nhận dạng sản phẩm hiện có trong giỏ hàng.
5. Lambda trích xuất các món ăn liên quan từ bộ sưu tập productSimilarity cho mỗi bữa ăn trong giỏ hàng và các món ăn liên quan theo điện thoại nhất định từ bộ sưu tập userPref.
6. Sau đó, thuật toán lambda kết hợp các danh sách món ăn có liên quan này thành một danh sách và gửi trở lại ứng dụng dành cho thiết bị di động dưới dạng danh sách đề xuất. Trong giỏ hàng, ứng dụng hiển thị thẻ sản phẩm.

thuật toán

Sở thích của người sử dụng

Chúng tôi đã triển khai tùy chọn người dùng dựa trên lịch sử bán hàng có trọng số, trong đó ưu tiên bán hàng gần đây. Xem xét lịch sử bán hàng của người dùng tùy ý sau:

Người dùng đã mua cả sản phẩm B và sản phẩm C bốn lần. Tuy nhiên, do phần lớn doanh số bán hàng của sản phẩm B diễn ra cách đây 4 tháng nên chúng tôi ưu tiên doanh số bán sản phẩm C gần đây hơn. Các sản phẩm được sắp xếp theo tổng doanh số có trọng số, là tổng doanh số có trọng số cho từng sản phẩm.

Ví dụ trên ngụ ý rằng người dùng thích sản phẩm A hơn sản phẩm C và sản phẩm C hơn sản phẩm B.

sản phẩm tương tự

Số lượng đơn đặt hàng có các cặp sản phẩm được sử dụng để tính độ tương tự của sản phẩm. Kết quả được tính riêng cho từng tháng, với những tháng gần đây nhất được ưu tiên. Do đó, chúng tôi xếp hạng các sản phẩm tương tự cho từng sản phẩm và lưu trữ chúng trong MongoDB, trong đó ID sản phẩm là chỉ mục cho bộ sưu tập.

Sự giới thiệu

Danh sách đề xuất hàng hóa kết quả kết hợp sở thích của người dùng và các sản phẩm tương tự và sắp xếp chúng theo một số chiến lược, đó là sắp xếp tăng dần theo thứ hạng. Do đó, chúng tôi chỉ cần kết hợp tất cả các danh sách sản phẩm có liên quan và sắp xếp chúng. Chúng tôi tính thứ hạng trung bình cho các sản phẩm lặp lại. Đây là một ví dụ:

1. Giả sử người dùng hiện có một giỏ hàng với 2 sản phẩm – A và B;
2. Lambda chọn một tài liệu từ bộ sưu tập productSimilarity cho sản phẩm A. Các món ăn liên quan là C (hạng 1), D (hạng 2) và E (hạng 3);
3. Lambda chọn một tài liệu từ bộ sưu tập productSimilarity cho sản phẩm B. Các món ăn liên quan là F (hạng 1), G (hạng 2) và H (hạng 3);
4. Lambda chọn một tài liệu từ bộ sưu tập userPref cho điện thoại nhất định. Các món liên quan là D (hạng 1) và H (hạng 2);
5. Tất cả các món ăn liên quan được kết hợp và đối với các món ăn trùng lặp, thứ hạng trung bình được tính. Danh sách kết quả là C (hạng 1), D (hạng 1,5), E (hạng 3), F (hạng 1), G (hạng 2) và H (hạng 2,5).
6. Sau khi sắp xếp danh sách là C, F, D, G, H và E, và quay trở lại ứng dụng.

kết quả

Số liệu hoặc Cách đo lường kết quả

Chúng tôi đã chọn các chỉ số sau để đo lường hiệu quả bán chéo:

1. Giá trị đơn hàng trung bình (AOV) của các đơn hàng bao gồm bán kèm món ăn cao hơn AOV của các đơn hàng không bán kèm. Tổng của tất cả các sản phẩm trong đơn hàng là giá trị đơn hàng, là số tiền khách hàng thanh toán cho đơn hàng. Do đó, số liệu này cho biết liệu khách hàng có trả thêm tiền cho các đơn hàng bao gồm các món ăn được bán kèm hay không. Đây là số liệu quan trọng vì mức tăng AOV chính xác là những gì chúng tôi mong đợi từ việc bán chéo.

   
   

2. Tỷ lệ hàng hóa được thêm từ phần bán chéo trong tổng số hàng hóa đã bán . Đây là một số liệu phụ chịu ảnh hưởng lớn bởi bản chất của hàng hóa được bán cũng như chiến lược bán chéo. Hãy xem xét một cửa hàng thương mại điện tử bán chéo các mặt hàng bổ sung giá rẻ như vali và cáp sạc cho các mặt hàng đắt tiền hơn trong giỏ hàng như điện thoại thông minh và máy tính xách tay. Nhiều chất bổ sung có thể được bán chéo cho một mặt hàng chính trong trường hợp này và số liệu có thể vượt quá 50%. Mặc dù ví dụ của chúng tôi không bao gồm nhiều loại thực phẩm bổ sung, số liệu này cho thấy việc bán chéo ảnh hưởng như thế nào đến cấu trúc giỏ hàng cuối cùng.

   
   

3. Tỷ lệ phần trăm đơn đặt hàng có bán kèm món ăn . Đây là một chỉ số phụ khác hiển thị "mức độ phổ biến" của bán kèm hoặc tần suất khách hàng mua các sản phẩm được đề xuất trong bán kèm.

Kết quả thực tế

Tập dữ liệu bên dưới chứa dữ liệu đặt hàng không mang tính cá nhân được thu thập từ tháng 12 năm 2022 đến tháng 1 năm 2023 tại một trong các thành phố hoạt động của MnogoLososya.

https://github.com/alexchrn/cross-sell/blob/main/orders.csv

Tập dữ liệu được tổng hợp từ nhiều nguồn khác nhau, bao gồm AppMetrica (sự kiện thêm vào giỏ hàng) và hệ thống ERP (trạng thái đặt hàng và thanh toán, chiết khấu và tổng thanh toán).

Cấu trúc bộ dữ liệu:

• order_id. Một định danh duy nhất của một đơn đặt hàng
• number_of_cross_sell_dish. Số lượng món ăn đã được thêm vào từ phần bán kèm.
• trạng thái. Trạng thái đơn hàng được biết đến gần đây nhất.
• tình trạng thanh toán. Trạng thái thanh toán đã biết gần đây nhất
• điểm_số. Số điểm thưởng đã được rút trong một đơn hàng. 1 điểm bằng 1 rúp.
• chiết khấu_sum. Giảm giá bằng rúp, không bao gồm điểm thưởng.
• thanh toán_summ. Khách hàng đã trả bao nhiêu cho một đơn đặt hàng
• đã tạo_at. Ngày giờ tạo đơn hàng
• appmetrica_device_id. Mã định danh thiết bị duy nhất
• app_version_name. Phiên bản ứng dụng
• tổng_số_của_dishes. Tổng số món ăn trong một đơn hàng
• has_cross_sell_dish. Liệu một đơn đặt hàng có chứa các món ăn được thêm vào từ bán chéo hay không. Trường này được tính toán từ number_of_cross_sell_dishes.

Vì vậy, đây là các giá trị số liệu (được lấy từ tập dữ liệu trên bằng python).

Tỷ lệ món ăn được thêm từ phần bán kèm trong tổng số món ăn đã mua – 3,97%

Tỷ lệ đơn hàng có bán kèm món ăn – 10,46%

AOV của các đơn hàng bao gồm bán kèm món ăn so với AOV của các đơn hàng không:

Có thể thấy, các đơn hàng có bán kèm món ăn có AOV cao hơn với mức chênh lệch là 565 RUB. Số lượng món ăn trung bình trong các đơn đặt hàng như vậy cũng cao hơn, điều này là hợp lý khi xét đến mục tiêu duy nhất của bán kèm là khuyến khích khách hàng thêm nhiều món ăn vào giỏ hàng của họ.

Sự khác biệt của 565 có đáng kể không? Chúng ta có thể sử dụng kiểm định t để xem liệu sự khác biệt này có phải do ngẫu nhiên hay không. Thư viện scripy Python có một phương pháp cho việc này. Đây là phép thử cho giả thuyết khống rằng 2 mẫu độc lập có giá trị trung bình (dự kiến) giống hệt nhau (1).

Do đó, giá trị p, hoặc xác suất của giả thuyết không là đúng, là cực kỳ thấp và chúng tôi bác bỏ giả thuyết không ngay cả ở mức ý nghĩa 99%. Nói cách khác, gần như chắc chắn rằng sự khác biệt đáng chú ý về giá trị trung bình của đơn đặt hàng không phải là ngẫu nhiên và các đơn đặt hàng có bán kèm bữa ăn tạo ra nhiều doanh thu hơn.

Phần kết luận

Bán chéo có thể là một công cụ hiệu quả để tăng giá trị đơn hàng trung bình ngay cả với các kỹ thuật lọc cộng tác đơn giản. Nó cũng có thể được triển khai tương đối dễ dàng từ quan điểm kỹ thuật, nhờ AWS và các dịch vụ serverless của các nhà cung cấp dịch vụ đám mây khác, như được trình bày trong bài viết này.

Tài liệu liên quan:

1. https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html