MongoDB Atlasによるリアルタイムカスタマー保持

ソリューション概要

カスタマー保持とは、顧客が製品を購入し、他のプロバイダーに切り替えないようにする組織の能力のことを指します。保持を改善して、小売で長期的に成功するようにします。保持を 5% 増加させると、利点は 25% から 95% に増加します。カスタマーを保持するコストは、新しいカスタマーを取得するよりもはるかに少なくなります。最新のコマース プラットフォームは、大量の動作データを生成します。カスタマーは、検索、製品ビュー、チャート アクション、参照アクティビティを通じてこのデータを作成します。

ほとんどの小売業者はこのデータを システム レコード に保存し、後でバッチするパイプライン を通じて分析します。このため、セッションが終了した後にのみ応答します。時間後の場合、次のことを行います。

• 廃止されたチャートメールを送信します。

• 選挙のリターゲティングを開始します。

• ダッシュボードの確認。

その時点で、カスタマーはすでに退化し、購入に影響を与える機会を失います。カスタマーがアクティブな状態で応答します。レコードのシステムからアクションのシステムに移行する。セッション中に動作シグナルを検出し、リアルタイムで応答します。

図の 1。バッチ処理とストリーム処理: 後で分析された保存済みデータとリアルタイムで分析されたイベント 。

MongoDB AtlasとAtlas Stream Processingを使用して、リアルタイム動作パイプラインを構築します。これらのパイプラインはクリックストリーム イベントを発生時に処理し、未加工のイベントを実行可能なコンテキストに変換します。これらのツールを使用すると、次のことができます。

• 現在の動作コンテキストを取得するライブ セッション メモリを作成します。

• ほぼリアルタイムの相互作用パターンから動作シグナルを検出します。

• trigger エージェント カスタマーを変換にガイド個別のベスト アクション（オプション）。

• MongoDB Change Streams を通じて行動シグナルに 反応する 。

• セッション メモリ、カスタマーデータ、ビジネス ポリシーを統合したMongoDBインテリジェンス データレイヤーに組み合わせます。

Atlas Stream Processing を使用することで、 MongoDB Query API （MQL）と Aggregation Framework を同じプラットフォームで使用することで、 SQLベースのストリーム処理の堅牢性を回避できます。柔軟なMongoDB document modelを使用することで、セッション コンテキストの変化を表すことができます。1 つのセッションドキュメントで履歴動作と最新のアクティビティ スナップショットが取得されるため、ほぼリアルタイムの動作分析が可能になります。

Simplify your architecture個別のストリーミングインフラストラクチャを管理する代わりにMongoDBでストリームを直接プロセシングすることでアーキテクチャを簡素化し、イベント駆動型アプリケーションの提供を高速化します。

図の 2。Atlas Stream Processing でこれら 3 つの主要原則を実現します

リアルタイムで動作パターンを検出して、カスタマー保持を向上できます。

• 購入意向

• 検索競合

• 放棄のリスク

これらのシグナルが表示されたら、すぐに応答します。次のようなターゲット trigger をアクションします。

• カスタマイズの推奨事項

• コンテキストに応じたソーシャル 証明通知

• 配送関連のオプション

図の 3。変換の可能性を高めるライブユーザーの動作に基づいて、リアルタイムの次のベストアクションをトリガーします。

カスタマーセッションがアクティブなときに動作し、次の操作を行います。

• 変換率を上げます。

• カスタマーライフタイム値を改善します。

• 長期的な信頼関係をビルドする。

MongoDB Atlasを基盤としたリアルタイムのカスタマー保持システムをビルドする。

参照アーキテクチャ

Atlas Stream Processing とMongoDB Atlasによるカスタマー保持アーキテクチャの概要

このソリューションを実装するには、データフロー、イベント プロセシング ステージ、および主要なアーキテクチャコンポーネントを理解する必要があります。

図の 4。MongoDB Atlasを基盤としたカスタマー保持エンジン

1. イベント取り込み層

   ｅコマースアプリケーションでは、カスタマーインタラクションによってリアルタイムイベントストリームが生成されます。このアプリケーションを使用すると、次のことができます。

   • 10 秒ごとにハートビートイベントを発行して、カスタマーセッションがアクティブなままであることをシグナルします。

   • 検索、製品ビュー、カードに追加、カーソルを終了するなどのカスタマーアクションをキャプチャします。

   このデモ ソリューションでは、 イベントをMongoDBコレクションにストリーミングします。Change Streams は各ドキュメントを新しいイベントとして公開し、ストリーム処理レイヤーに入力するリアルタイムイベントソースを作成します。

   また、 MongoDB Atlasにイベントを保存せずに、 Apache Kafka、Google Cloud Pub/Sub、 Azure Event Hubs、 AWS Kinesisなどのプラットフォームから Atlas Stream Processing のソースとしてこれらのストリームを取り込むこともできます。

2. Atlas Stream Processing

   Atlas Stream Processing は、データを受信時に処理するために使用されます。これにより、次のことが可能になります。

   • $source 演算子を使用してデータストリームに接続します。

   • セッション状態の構築や動作シグナル パターンの検出など、さまざまなタスクに複数のストリーム プロセッサを使用します。

   • 高い購入意図、検索の競合、終了リスクなどの動作シグナルを生成します。

3. データシンク

   $merge 演算子は処理されたデータを宛先に送信するために使用されます。このソリューションでは、次のことが行われます。

   • ストリーム プロセッサはセッション状態をMongoDBに書き込み、エージェント決定レイヤーのライブ セッション メモリとして機能します。

   • Atlas Stream Processing は、処理されたイベントから生成された動作シグナルをMongoDBに書込みます。

   • MongoDB Change Streams はこれらのシグナルを公開し、キーカスタマー保持シグナルが表示されたときにエージェント NUレイヤーを trigger します。

   $merge 演算子は、 Apache Kafka、 AWS S3、または外部関数に結果を送信することもできます。

4. エージェント

   AIエージェントを配置して動作シグナルを読み取り、次のようなRBを計算します。

   • カスタマイズの推奨事項

   • コンテキストに応じたソーシャル 証明通知

   • 配送関連のオプション

   エージェントは、 決定レイヤーとして機能します。単純なエージェントまたは高度なエージェントとして実装できます。このソリューションでは、Model Context Protocol (MCP)、ベクトル検索、Voyage AI 埋め込みモデル、大規模言語モデル (LLMs) を組み合わせた決定論的エージェントが使用されます。これらのツールはコンテキストを評価し、アクティブなリスナーを維持するための最適な RB を生成します。

5. MongoDB Atlas

   MongoDB Atlas をコマースおよびカスタマーコンテキストレイヤーとして使用します。エージェントは、コンテキストのために Atlas から運用データとカスタマー履歴を読み取ります。エージェントはこのデータを評価し、RB をMongoDBコレクションに書込みます。

   Atlas は、エージェントのエコシステム全体のデータ統合を安全かつ大増やすに 簡素化 します。これにより、カタログ、カスタマーの嗜好、およびその他のベクトル検索のユースケースの埋め込みと並行して運用データを運用できます。

6. リアルタイム エクスペリエンス

   カスタマー画面に NU をリアルタイムで表示します。ｅコマースアプリケーションはChange Streams を使用して NUコレクションをモニターします。その後、アプリケーションはアクティブなホッパーに対象を絞った通知を表示します。例としては、次のものが含まれます。

   • 戦略的製品のアイコンを起動

   • 通知としてまたはカード リスト内でのソーシャル 証明メッセージ

   • 推奨事項または割引通知をポップアップとして表示します

Atlas Stream Processing による動作シグナルの検出

それぞれの製品ビュー、検索、またはチャートアクションには意向のトレースが含まれていますが、未加工のイベントは多くの場合してノイズを含むものです。Atlas Stream Processing を使用して、これらのイベントを明確なセッション コンテキストに変換します。

このコンテキストをリアルタイムで更新 します。これを使用して、セッション全体の動作を追跡し、重要なパターンを検出します。クエリ、説明、操作が簡単な形式で、決定レイヤーにこのコンテキストへの高速アクセスを提供します。このアーキテクチャでは、Atlas Stream Processing がそのロールを実行します。

図の 5。Atlas Stream Processing による動作シグナルの検出

ASP #1 はクリックストリーム（1）（2）をアクティブなセッションごとに単一の session_stateドキュメントに継続的に変換し、セッション メモリを最新の 10 秒の動作スナップショット（4）と組み合わせます。ASP #2 は、その新しいイベントソース（5）を読み取って、高レベルの動作シグナルを検出し、session_signals（7）にシンクします。どちらも処理データをMongoDBに保存しますが、無効なイベントはデバッグとトラブルシューティングのためにDLQコレクション（3）（6）にルーティングされます。

Atlas Stream Processing No.1: ライブ セッション状態をビルドする

各カスタマーセッション向けにライブ セッション状態を構築します。このセッション状態は、次の 2 つの目的で使用します。

1. セッション メモリをビルドする: 下流のシステムに必要なセッション メモリを作成します。セッションごとに処理されたドキュメントを 1 つ保持し、10 秒ごとに更新します。最初のアクティビティ、最後のアクティビティ、インタラクション数、最近の動作、検索履歴など、重要なセッションコンテキストを保存します。

2. 意向を解釈: ドメインに合わせてカスタマイズされた意向モデルでアクティビティを解釈し、保存型アクティビティを超えGo。

このデモでは、最近のカスタマーイベントを 10 秒ごとにグループ化し、動作の構造化ビューを作成します。このビューを使用して、カスタマーが注意を向ける場所と、その注意が時間の経過とともにどのように変化するかを追跡します。

3 つの概念を含む意向モデルを定義します。

• 次元: 各インタラクションの動作フィルター。製品イベントは、articleType や brand など、特定の製品とより広範なコンテキストの両方を識別します。これにより、各イベントの複数レベルで意向を読み取ることができます。カスタマーは、記事タイプなどの同じタイプの「ディメンション」に焦点を当てながら、複数の製品を調べる可能性があります。

• 重み: 相互作用シグナルの強度。すべてのアクションが同じ重要性を持つわけではありません。

  このデモでは、重みは次のとおりです。

  • view-製品 = 3

  • カードに追加 = 7

  次元内の各アイテムについて、以下のように重みを計算します。

  重み(item) = 10 秒ウィンドウ内のそのアイテムのイベントの重みの合計

  例:

  カスタマーが「X」製品（P1）を 2 回表示し、P1 を 1 回チャートに追加し、かつ trackType がターゲットの場合、次のようになります。

  重み(P1) = 3 + 3 + 7 = 13

  重み(ドキュメント) = 3 + 3 + 7 = 13

  この計算は、特定の製品と特定の製品の両方において が懸念されることを示しています。

• フォーカス: Focus を使用して、1 つの単位内でカスタマーの注意がどの程度集中しているかを測定します。

  次元内の各項目について、以下を計算します。

  Focus(item) = 重み(アイテム) / 同じウィンドウ内のその次元の合計重み

  例:

  P1 がそのウィンドウ内でカスタマーが操作する唯一の製品である場合、次のようになります。

  Focus(P1) = 13 / 13 = 1.0

  つまり、カスタマーは1 つの製品に完全に集中しています。

  カスタマーが同じウィンドウで 2 つの製品を操作し、各製品が異なる MongoDB に属している場合、次のようになります。

  • は、製品 P1 を表示します。ここで、tributionType = シャットー → 重み（Shape）=3

  • は、製品 P2 を表示し、製品 P2 をチャートに追加します。ここでは、付け加えた値を にします。ここでは、速度（Conditioner）= 3+7 = 10

  以下は次の操作を行います。

  合計重み(textType) = 3 + 10 = 13

  So:

  Focus(Shapoo) = 3 / 13 = 0.23

  Focus(Conditioner) = 10 / 13 = 0.77

  つまり、カスタマーの注意は featureType ディメンションの複数の項目に分散されていますが、コンフィギュレーションサーバーにより集中します。

このモデルを使用して、これらの変数を一定の期間追跡します。各 10 秒のスナップショットは、Atlas Stream Processing No.2 の構造化された動作入力になり、高レベルのパターンを時間の経過とともに評価します。これは、カスタマーの属性を持っているかどうかを判断するのに役立ちます。

• 特定のアイテム、カテゴリ、またはブランドに焦点を当て

• 幅広い探索

• 明確なまたは不正確な意向を表示

Atlas Stream Processing のネイティブ機能を使用して、このセッション状態をビルドします。

• $source を使用して、events_ingest からイベントを読み取り、ウィンドウ用にイベント時間を保持します。

• $validate を使用してイベント契約を強制し、無効なイベントを events_ingest_dlq に送信します。

• $tcomingWindow を 10 秒のイベント時間間隔で使用して、セッションごとに 1 つの安定したプロセシング フレームを作成します。

• $group を使用して、複数の未加工イベントを各ウィンドウの 1 つのセッションごとのスナップショットにまとめます。

• $addFields と $switch を使用して、各インタラクションに重みを割り当てます。

• $function を使用して、各次元の重みとフォーカスの意向モデルを計算します。カウンターと算術演算を使用して、 JavaScriptロジックで各タームウィンドウのイベントを処理し、10 秒ごとにセッション動作の構造化スナップショットを生成します。これにより、Atlas Stream Processing No. 2 が次のステージで消費する新しいデータセットが作成されます。

• $merge を使用して結果を session_state にアップサートし、最新のスナップショットと累積セッションメモリの両方を使用して、セッションごとに 1 つのライブドキュメントを保持します。

Atlas Stream Processing No. 2: 動作パターンを一定期間検出

未加工のクリックストリーム イベントではなく、session_state から構造化されたセッション スナップショットを読み取ります。これにより、評価用の処理された時間認識型動作レイヤーが提供されます。

このデモでは、Atlas Stream Processing No.2 は 3 つのストリーム プロセッサを使用しています。各プロセッサは 1 つのシグナル タイプを検出します。

• high-intent

• search-friction

• exit-risk

3 つのプロセッサはすべて同じパターンに従います。

• 読み取りセッション スナップショット session_state

• 30 秒ウィンドウ全体で動作を評価する

• 挿入専用シグナル ドキュメントの書き込み (write) session_signals

この設計により、パイプラインはシンプルかつモジュール的に保たれます。各プロセッサは同じソースとシンク パターンを使用しますが、動作シグナルを検出するために異なるルールを適用します。これらのシグナルは動作チェックポイントとして使用します。それぞれが、次のようなセッション動作における意味のある変化をキャプチャします。

• 積の整合性

• 未解決の検索

• 終了の意向。

シグナルは スパース で、時間制限があり、説明可能な状態に維持します。これにより、決定レイヤーは、未加工のイベントをすべてプロセシングするのではなく、関連する状況が発生した場合にのみReactできます。

Atlas Stream Processing No.2 は、次のアクションを決定しません。これは、決定システムがリアルタイムで理由を説明し、動作するために使用する動作シグナルレイヤーを構築します。

図の 6。AIエージェントのための統合インテリジェンス データレイヤーの構築

次の最高のアクションエージェントは、 MongoDBの統合インテリジェンス データレイヤーの上部で実行されます。It reacts to behavioral signals (1) through Change Streams, takes live context from session_state (2.a), and combines it with business and semantic context stored in MongoDB, such as user profile, catalog, promotions, rules, embeddings, and MongoDB Vector Search (2.b).エージェントは次のベストアクションをリアルタイムで計算して保存します（3）。このアクションは、その後、eコマースアプリケーションがChange Streams を通じて消費し、カスタマー保持目的でライブ セッション中に表示されます（4）。

セッション状態、動作シグナル、および決定出力をMongoDBに保存することで、エージェントに統合インテリジェンス データレイヤー を提供します。エージェントは、そのセッションの新しい動作コンテキストと履歴シグナルを読み取ることができます。次に、このデータをプロファイル、カタログ、プロモーション、ビジネス ルールと組み合わせて、同じ運用プラットフォーム上で RB を書き込み (write) します。これにより、アーキテクチャがシンプルになり、データの移動が減り、エージェントは安全かつスケーラブルな方法でリアルタイムで動作するために必要なコンテキストにすばやくアクセスできます。

データモデルアプローチ

MongoDB は、リアルタイムアーキテクチャに柔軟な document model を提供します。異なるスキーマを持つさまざまなカスタマーイベントを単一のコレクションに保存します。ビジネス ロジックの変化に応じてスキーマを更新する。

ドキュメントモデルは、配列やサブドキュメントなどの複雑な構造を取り扱います。これらの構造を使用して、圧縮されたクエリ可能なセッションメモリを構築します。この設計では、データベース結合のないAIエージェントの即座のコンテキストが提供されます。Time-to-Live（TTL）インデックスを使用して、手動データクリーンアップスクリプトを排除します。

このソリューションは 4 つの主要なコレクションを使用します。

• event_ingest: 未加工の有効期間の短いデータ イベントを保存します。ストリーミングパイプラインのプライマリ ソースとして機能します。

• Session_rate: セッションごとにライブ運用コンテキストを保存し、約 10 秒ごとに更新を取得します。

• Session_signals: 解釈可能な動作シグナルを保存します。Atlas Stream Processing は、検出されたシグナルごとに 1 つのドキュメントを生成します。

• 次の_ベスト_アクション: ｅコマース インターフェースの最終アクション契約を保存します。

1. Raw イベント Ingestion（events_ingest）

   ｅコマースアプリケーションは、未加工のイベントを events_ingestコレクションにストリーミングします。各イベントは、タイムスタンプ、タグ、メタデータを含む共通の構造に従います。イベントフィールドはイベントの種類を識別し、メタデータセクションにはイベント固有の属性が保存されます。この多形設計により、厳格なスキーマを強制せずに、異なるイベントタイプが同じコレクションに共存できます。このエフェメラル データを管理するには、短い TTLインデックスを使用します。

   {
     "timestamp": "2026-01-05T14:55:12.321Z",
     "tags": {
       "sessionId": "1767624420027",
       "userId": "66fe219d625d93a100528224",
       "event": "search"
     },
     "metadata": {
       // Event-specific fields
     }
   }

2. マテリアライズドセッション状態（セッション_状態）

   セッション状態ドキュメントは、セッションごとに単一のライブ真実のソースを表します。Atlas Stream Processing No。1 はこのドキュメントを 10 秒ごとに更新します。これにより、Atlas Stream Processing No. 2 のソースとして機能し、アクティブなセッション内でエージェントが決定を行うためのライブかつ短期間のコンテキストとして機能する圧縮されたコンテキストが作成されます。

   ドキュメントは、累積アクティビティ（sessionTotals）と最近のマイクロウィンドウ アクティビティ（last10s）を分離します。イベント数、最近の検索、チャート更新を追跡します。重み付きインタラクション モデルを使用して、アイテムの優先順位スコアを計算します。このモデルは、書き込みの強度とフォーカスの方向を測定します。

   {
     "_id": {
       "$oid": "69c16dd2f2145b31c07b1beb"
     },
     "firstSeen": {
       "$date": "2026-03-23T16:43:59.013Z"
     },
     "lastEvent": {
       "event": "view-product",
       "ts": {
         "$date": "2026-03-23T16:49:29.849Z"
       }
     },
     "lastSeen": {
       "$date": "2026-03-23T16:49:29.849Z"
     },
     "sessionId": "d73477b8-3879-4749-a402-321a526cdc33",
     "userId": "671ff2451ec726b417352703",
     "last10s": {
       "intent": {
         "products": [
           {
             "productId": "67192b4264d161905fbe8342",
             "searchCount": 0,
             "viewCount": 0,
             "addToCartCount": 1,
             "weight": 7,
             "focus": 0.4375
           },
           {
             "productId": "67192b4264d161905fbe8245",
             "searchCount": 0,
             "viewCount": 1,
             "addToCartCount": 0,
             "weight": 3,
             "focus": 0.1875
           },
           {
             "productId": "67192b4264d161905fbe82a1",
             "searchCount": 0,
             "viewCount": 1,
             "addToCartCount": 0,
             "weight": 3,
             "focus": 0.1875
           },
           {
             "productId": "67192b3f64d161905fbe77af",
             "searchCount": 0,
             "viewCount": 1,
             "addToCartCount": 0,
             "weight": 3,
             "focus": 0.1875
           }
         ],
         "articleTypes": [
           {
             "articleType": "SHOES",
             "searchCount": 0,
             "viewCount": 2,
             "addToCartCount": 1,
             "weight": 13,
             "focus": 0.8125
           },
           {
             "articleType": "CARGO_STRAP",
             "searchCount": 0,
             "viewCount": 1,
             "addToCartCount": 0,
             "weight": 3,
             "focus": 0.1875
           }
         ],
         "subCategories": [
           {
             "subCategory": "Shoes",
             "searchCount": 0,
             "viewCount": 2,
             "addToCartCount": 1,
             "weight": 13,
             "focus": 0.8125
           },
           {
             "subCategory": "Hardware",
             "searchCount": 0,
             "viewCount": 1,
             "addToCartCount": 0,
             "weight": 3,
             "focus": 0.1875
           }
         ],
         "dimensionTotals": {
           "productWeightTotal": 16,
           "articleTypeWeightTotal": 16,
           "subCategoryWeightTotal": 16
         }
       },
       "lastEvent": {
         "event": "view-product",
         "ts": {
           "$date": "2026-03-23T16:49:29.849Z"
         }
       },
       "window": {
         "start": {
           "$date": "2026-03-23T16:49:20.000Z"
         },
         "end": {
           "$date": "2026-03-23T16:49:30.000Z"
         }
       }
     },
     "sessionTotals": {
       "eventCounts": {
         "heartbeat": 30,
         "search": 2,
         "view-product": 21,
         "add-to-cart": 13,
         "exit-risk": 14
       },
       "windowCount": 30
     },
     "searchHistory": [
       "shoes",
       "running shoes"
     ]
   }

3. 実行可能な診断（session_signals）

   Atlas Stream Processing No.2 は、30 秒ごとにセッション状態を評価し、動作パターンを識別してシグナルを生成します。セッションドキュメント内でシグナルの配列ではなく、シグナルごとに 1 つのドキュメントを使用します。この挿入専用アプローチは、書込み保証を回避し、小売トラフィックのピーク時にホットドキュメントを防止します。

   このソリューションは、ほとんどのeコマース ジャーナルで高影響の保持時間を表す 3 つの主要な動作シグナルに焦点を当てています。

   • 高意向:カスタマーは購入を検討しており、強力な意向シグナル（繰り返しの製品フォーカス、チャートプログレス、集中型の特権など）を示しています。これは、再保証、 製品ガイダンス、可用性、および配信の明確さを通じて懸念を減らし、変換を迅速化するのに最適なタイミングです。

   • 終了リスク:カスタマーは変換せずに終了する可能性があり、多くの場合意味のあるンゲージメントやチャート アクティビティの後になります。これは、セッションを保持したり、カードをリカバリしたり、意向を保持したり、即座の支援を提供したりするための最後の機会です。

   • 検索競合:カスタマーは検索と参照を繰り返し処理できない状態で繰り返し検索するため、一致するものを見つけるのが困難か、またはフレーバーが発生する可能性があります。これは、枯渇やフィールドでカスタマーがセッションを放棄する前に、早期に中断するための最も価値の高い機会の 1 つです。

   以下は、検索競合シグナルのドキュメントの例です。

   {
     "_id": "69c172667348bc2e9b60ee7b",
     "evidence": "Explored a considerable number of products in the last 30 seconds, while articleType focus remained predominant on 'PET_SUPPLIES'. The absence of add-to-cart suggests stable topic-level intent combined with choice overload at the product level",
     "severity": "medium",
     "sid": "d73477b8-3879-4749-a402-321a526cdc33",
     "signal": "search-friction",
     "topic": {
       "dimension": "articleType",
       "value": "PET_SUPPLIES"
     },
     "ts": "2026-03-23T17:03:20.000Z",
     "uid": "671ff2451ec726b417352703"
   }

ソリューションのビルド

このデモを自分の環境で再生するには、次の手順に従います。

キーポイント

• カスタマーをリアルタイムで保持 : Atlas Stream Processing を使用すると、クリックストリーム イベントを処理して、アクティブなセッション中に次のアクションをトリガーできます。これにより、小売業者は、リアクティブな障害制御から、先を見越した時点での介入への移行が可能になります。

• データ アーキテクチャを簡素化: MongoDBドキュメントモデルを使用すると、未加工のクリックストリーム イベント、セッション状態、動作シグナルを単一のプラットフォームに保存できます。TTL インデックスと柔軟なコレクションを使用することで、パイプラインの抽出、変換、ロード、および手動クリーンアップを回避します。

• MongoDBのインテリジェンス データレイヤー上にエージェント的ベスト アクションをビルドする: MongoDBのライブ セッション コンテキストと運用データにAIエージェントを直接接続します。ベクトル検索などのAI機能で次のベストアクションを強化し、カスタマイズされたエクスペリエンスを提供します。

作成者

• Angie Guemes, MongoDB

• Florencia Arin, MongoDB

• ロドリールール、 MongoDB

• MongoDB、 MongoDB

詳細

• MongoDBによるカスタマー保持の強化

• 小売業界の革新を支える MongoDB