この記事では、食料品や食品配達サービスなどの e コマースでクロスセル (カート内の商品に加えて顧客に提供される商品) 機能を開始するための比較的簡単な方法について説明します。 「Mnogo Lososya」モバイルアプリ。これは、ユーザーベースとアイテムベースのアプローチを組み合わせた基本的な協調フィルタリング レコメンダー システムであり、さまざまな e コマース プロジェクト、特に多数の SKU を持つプロジェクトで使用して、幅広いレコメンデーションを提供できます。  2018 年に設立された Mnogo Lososya は、50 以上のゴースト キッチンと 250 以上のテイクアウト キッチンのチェーンであり、複数の料理のコンセプトを包括するブランドでもあります。焼きたてを30分でお届けできるのも当店の特徴です。私たちは急速に拡大しており、最近ではアプリの MAU が 10 万人を超え、月間総収益が 1 億 RUB を超えています。 注文の大部分はオンラインで行われ、3 分の 1 は自社のモバイル アプリから、残りの 3 分の 2 は配送サービスからのものです。アプリは私たちの製品の重要な構成要素です。なぜなら、それは私たちのサービスや食品自体とともに、より良い顧客体験に貢献する最初の連絡先の 1 つであるからです。 建築 このソリューションはすべて Yandex Cloud サービス上に構築されましたが、必要なサービスもすべて備えているため、AWS 上に構築することもできます。 AWS ユーザーの便宜のために AWS 表記法でサービスを指定していますが、これは多くの YC ユーザーにも明らかなはずです。 マネージド MongoDB ラムダ関数 API ゲートウェイ クラウド DNS モバイル バックエンド (コンピューティング クラウド) 単純化されたアーキテクチャは次のようになります。  ユーザーはモバイルアプリから注文します。 ERP システムでは、注文が作成され、処理されます。 注文は、ETL プロセス中に 1 日に 1 回夜にデータ ウェアハウスにコピーされます。各注文には、注文した製品に関する情報と顧客 ID が含まれています。  SQL プロシージャーは、ユーザーの好みと製品の類似性を計算します。計算のより詳細な説明は、以下に提供されます。この計算により、MongoDB に次の構造を持つ 2 つのコレクションが生成されます。   userPref コレクション ユーザー識別子として「電話」を使用します。 電話: 関連料理 id: 関連料理のID ランク 最終更新日。最後の再計算の日時   ドキュメントの例: 製品類似コレクション 料理ID 関連料理 id: 関連料理のID ランク lastUpdateDate: 最後の再計算の日時 ドキュメントの例 ユーザーがカートを更新すると、アプリは Lambda 関数にリクエストを送信します。リクエストには、ユーザー ID (電話) と、現在カートに入っている製品 ID のリストが含まれます。  Lambda は、カート内の各食事の productSimilarity コレクションから関連する料理を抽出し、userPref コレクションから指定された電話で関連する料理を抽出します。 ラムダ アルゴリズムは、関連する料理のこれらのリストを 1 つに結合し、おすすめのリストとしてモバイル アプリに送り返します。カートでは、アプリが商品カードをレンダリングします。 アルゴリズム ユーザー設定 最近の売上を優先して、重み付けされた販売履歴に基づいてユーザー設定を実装しました。次の任意のユーザーの販売履歴を考えてみましょう。 製品 販売 いつ 時間係数 (1/月) 加重販売 あ 1 今月 1   1   B   1 今月 1   1 ハ 4   1ヶ月前 0,5   2 あ 4   1ヶ月前 0,5   2   B   3   4ヶ月前 0,25   0,75 ユーザーは製品 B と製品 C の両方を 4 回購入しました。ただし、製品 B の販売の大部分は 4 か月前に行われたため、最近の製品 C の販売を優先します。製品は、各製品の加重売上の合計である加重売上合計でソートされます。 製品 加重総売上高 ランク あ 3   1   B   1,75   3 ハ 2   2 上記の例は、ユーザーが製品 C よりも製品 A を好み、製品 B よりも製品 C を好むことを意味します。 製品の類似性 製品のペアが存在する注文の数は、製品の類似度を計算するために使用されます。結果は月ごとに個別に計算され、最近の月が優先されます。その結果、各製品の類似製品をランク付けし、製品 ID がコレクションのインデックスである MongoDB に保存します。 おすすめ 結果として得られる商品レコメンデーション リストは、ユーザーの好みと類似商品を組み合わせ、何らかの戦略 (ランクの昇順ソート) に従って並べ替えます。その結果、関連するすべての製品リストを組み合わせて並べ替えるだけです。繰り返し製品の平均ランクを計算します。次に例を示します。 ユーザーが 2 つの製品 (A と B) を含むカートを持っているとします。  Lambda は、製品 A の productSimilarity コレクションからドキュメントを選択します。関連する料理は、C (ランク 1)、D (ランク 2)、および E (ランク 3) です。  Lambda は、製品 B の productSimilarity コレクションからドキュメントを選択します。関連する料理は、F (ランク 1)、G (ランク 2)、および H (ランク 3) です。  Lambda は、指定された電話の userPref コレクションからドキュメントを選択します。関連料理はD（ランク1）とH（ランク2）。 関連するすべての料理が結合され、重複する料理については平均ランクが計算されます。結果のリストは、C (ランク 1)、D (ランク 1.5)、E (ランク 3)、F (ランク 1)、G (ランク 2)、および H (ランク 2.5) です。 リストは C、F、D、G、H、E にソートされ、アプリに返されます。 結果 指標または結果の測定方法 クロスセル効率を測定するために、次の指標を選択しました。 クロスセル料理を含む注文の そうでない注文の AOV よりも高かった。注文に含まれるすべての商品の合計が注文額であり、顧客が注文に対して支払う金額です。したがって、このメトリクスは、顧客が組み合わせ販売された料理を含む注文に対してより多く支払うかどうかを示します。 AOV の増加はまさにクロスセルから期待されるものであるため、これは重要な指標です。 平均注文額 (AOV) は、 。これは、販売される商品の性質とクロスセル戦略に大きく影響される二次的な指標です。スーツケースや充電ケーブルなどの低価格のサプリメントを、スマートフォンやラップトップなどのカート内のより高価なアイテムと組み合わせて販売する電子商取引ストアを考えてみましょう。この場合、多くのサプリメントを 1 つのメイン アイテムに合わせて販売することができ、指標は 50% を超える可能性があります。この例には多種多様なサプリメントは含まれていませんが、この指標は、クロスセリングが最終的なカート構造にどのように影響するかを示しています. クロスセル セクションから追加された商品の合計販売商品の割合 。これは、クロスセルの「人気」、または顧客がクロスセルの推奨製品を購入する頻度を表示するもう 1 つの二次的な指標です。 クロスセル料理を含む注文の割合 実績 以下のデータセットには、2022 年 12 月から 2023 年 1 月までに MnogoLososya の運営都市の 1 つで収集された非個人的な注文データが含まれています。   https://github.com/alexchrn/cross-sell/blob/main/orders.csv データセットは、AppMetrica (カートに追加イベント) や ERP システム (注文と支払いのステータス、割引と支払いの合計) など、さまざまなソースからコンパイルされます。 データセットの構造:  order_id。注文の一意の識別子 number_of_cross_sell_dishes。クロスセル部門から追加された料理の数。 スターテス。最後の既知の注文ステータス。 支払い状況。最後の既知の支払いステータス ポイント数。注文で引き出されたボーナス ポイントの数。 1 ポイントは 1 ルーブルに相当します。 割引合計。ボーナスポイントを含まないルーブルでの割引。  payment_summ.クライアントが注文に対して支払った金額 created_at.注文作成日時 appmetrica_device_id。一意のデバイス識別子 app_version_name.アプリ版 total_number_of_dishes。注文した料理の総数 has_cross_sell_dish.クロスセリングで追加された料理が注文に含まれているかどうか。このフィールドは、number_of_cross_sell_dishes から計算されます。 したがって、ここにメトリック値があります (python を使用して上記のデータセットから派生)。 クロスセル セクションから追加された料理の合計購入料理の割合 –    3.97% クロスセル料理を含む注文の割合 –    10.46% 組み合わせ販売料理を含む注文の AOV と、そうでない注文の AOV の比較:  ご覧のとおり、クロスセル料理の注文は AOV が高く、565 RUB の差があります。このような注文での料理の平均数も高くなります。これは、クロスセリングの唯一の目的が顧客に料理をカートに追加するよう促すことであることを考えると妥当です。  565 の違いは重要ですか? t 検定を使用して、この違いが偶然によるものかどうかを確認できます。 Python scripy ライブラリには、このためのメソッドがあります。これは、2 つの独立したサンプルの平均 (期待) 値が同一であるという帰無仮説の検定です (1)。  したがって、p 値、または帰無仮説が真である確率は非常に低く、99% の有意水準でも帰無仮説を棄却します。言い換えれば、平均注文額の顕著な差が偶然ではないことはほぼ確実であり、組み合わせ販売による食事の注文はより多くの収益を生み出します。 結論 クロスセリングは、単純な共同フィルタリング技術を使用しても、平均注文額を増やす効果的なツールになる可能性があります。この記事で説明したように、AWS や他のクラウド プロバイダーのサーバーレス サービスのおかげで、技術的な観点からも比較的簡単に実装できます。 関連資料:   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

このオーディオは、ストーリーの元の言語で制作されています。

eコマースでのクロスセリング: オンラインでアップセルするための技術ガイド

About Author

コメント

ラベル

この記事は

Related Stories

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps