コンポーザブルカタログデータモデルが存在する理由
現代のコマースチームでは、多くの場合、ブランド、地域、ディーラー、デジタルチャネルにわたって販売されています。 各チャネルが独自のカタログコピーを保持している場合、買い物客の体験を向上させるよりも、SKU、価格、可用性の調整により多くの時間を費やします。 Adobe Commerce Optimizerの背後にある Adobe コンポーザブルカタログデータモデル（CCDM） は、そのパターンを反転するように設計されています。SaaS レイヤーの単一の統合カタログ、各ストアフロントまたは統合で許可される内容を カタログビュー およびポリシー。
この動画は誰のためのものでしょうか？
- Adobe Commerce Optimizerを初めて使用するCommerce ソリューションアーキテクトおよび開発者で、カタログソース、ビュー、ポリシーを設定する前にビジネスコンテキストを必要とする方
ビデオコンテンツ
- 重複したチャネル固有のカタログが、オペレーショナルリスクを引き起こし、イノベーションを遅らせる理由
- CCDMが、マルチブランドおよびマルチリージョンのシナリオをサポートしながら、製品データを統合する方法
- カタログビューが、共有ベースカタログと特定のストアフロントやオーディエンスとの間の「レンズ」としての役割を果たす方法
- ヘッドレスエクスペリエンスが設定されたカタログとの整合性を維持できるように、マーチャンダイジングサービス APIがそれらのビューをどのように使用するか
分断されたカタログが抱える課題
すべてのディーラーサイト、地域のストアフロント、またはブランドプロパティが 独自のカタログデータベース を維持している場合、いくつかの問題が複合的に発生します。
- 複製 – 同じSKU、説明、メディアが何度も入力されます。
- Drift – 価格の更新、新しい属性、または廃止されたアイテムが1つのチャネルに表示されますが、他のチャネルには表示されません。
- 開始が遅い – 新しい各顧客接点では、単一の製品レコードを再利用する代わりに、多くのデータ作業が繰り返されます。
CCDMが存在するため、製品情報は 他のシステムがエンリッチする1つの構成可能なカタログ に存在し、ストアフロントには チャネルに適した の品揃えと価格が引き続き提供されます。
コンポーザブルカタログデータモデルの変更点
Adobe Commerce Optimizerでは、商品データは、1つ以上の カタログソース から 統合ベースカタログ に取り込まれます（例：en-USなどのロケール、PIMやERPなどのアップストリームシステム）。 そのソースは生の属性と値を提供します。
カタログビューでは、ビジネスコンテキストに対して、統合データが 整理され、公開される 方法を定義します。どの製品が ポリシー に合格するか、どの 価格表 が適用されるか、どの カタログソース がビューを支持するかです。 したがって、同じ基になるレコードは、各サイトのカタログ全体を複製することなく、ディーラー、地域、ブランドごとに個別のビューなど、多くの予測をサポートできます。
データの取得元が（カタログソース）であるのに対し プレゼンテーション方法（カタログビュー）であるこの分離は、チャネルごとに並行カタログを維持する代わりにCCDMを採用する主な理由となります。
ストアフロントレンズとしてのカタログビュー
マーチャンダイジングサービスのカタログビューで説明されているように、カタログビューは レンズ のように動作します。買い物客は、ビューが許可する商品、価格、ルールのみを表示しますが、ベースカタログは共有システムのままです。 このモデルは マーチャンダイジングサービス と直接ペアを設定するので、API クライアントは正しいビュー（および関連ヘッダー）を渡し、各エクスペリエンスに対して一貫性のあるポリシー駆動型の応答を受け取ります。
これらの要素がエンドツーエンドのフローにどのように適合するかについての詳細は、開発者チュートリアル ストアフロント用の構成可能なカタログの作成を参照してください。