0から1までのeコマース製品センターの構築

このシリーズの記事では、コアとなる電子商取引システムの製品設計ソリューションを詳しく紹介し、電子商取引製品を体系的に理解できるようにします。

この記事を読むと、以下の問題についてより深く理解できるようになります。

製品センターの定義と責任は何ですか?
製品センターのコアモジュールは何ですか?
製品センターを設計するには？

同時に、製品に関連するほとんどの機能モジュールの設計アイデアを体系的に把握することもできます。

序文

前回の記事「1 つの記事で電子商取引の製品アーキテクチャを理解する」では、電子商取引の基本的な業務、システムプロセス、製品アーキテクチャを全体的に紹介しました。3 つの大きな図を通じて、電子商取引の基本的な外観を事前に確認し、完全な電子商取引システムのコアコンポーネントを理解し、概念レベルで電子商取引の全体的な理解を得ました。

今回からは、各コアシステムの詳細な設計思想やソリューションを一つずつ解説していきます。

各種電子商取引システムの責任の順序から判断すると、製品システムは最も基本的かつ中核的なシステムであることがわかります。製品がなければ、他のシステムは動作できません。そのため、この記事ではまず「製品センター」の詳細な設計思想と計画を紹介します。

（画像が大きすぎて正しく表示されない場合は、コンピューターを使用して拡大してください）

1. 製品センターの概要

1. コモディティシステムとは何ですか?

名前が示すように、コモディティシステムは、コモディティ関連のデータと機能を管理するシステムであり、次の 3 つの文に要約できます。

製品の作成と管理を担当するシステム
カテゴリ、ブランド、属性、その他すべての製品関連データの作成と管理を担当するシステム
フロントデスクでの商品の展示や、関連する上流・下流システムに商品機能を提供するシステム

電子商取引の商品システムでは、商品は他のすべての関連システムの基礎です。技術的に言えば、商品システムは他のシステムの依存関係です。商品の調達から在庫管理、商品自体の作成と棚管理から商品の価格設定とフロントエンドのディスプレイ、プロモーション活動から注文の支払い、注文の生産から履行と配送まで、電子商取引のすべてのプロセスは商品に関連しています。

こうした上流・下流システムの中でも、商品データは統一・普遍化・標準化されている必要があります。例えば、調達システムにおける商品Aと発注システムにおける商品Aは同じAでなければなりません。したがって、商品システムは、集中型サービスの提供能力を大いに備えていなければなりません。したがって、商品システムは、すべてのシステムの中で最も優先度の高い集中型サービスとして設計する必要があるシステムでもあります。

これが、この記事のタイトルが「0 から 1 までの e コマース製品センターの構築」である理由です。

2. 商品センターには何がありますか?製品センターでは何ができるのでしょうか?

写真を通して理解することができます：

上の図の中央部分は製品センターです。製品センターのコアモジュールは、次の 4 つの部分に抽象化できます。

製品分類: カテゴリを作成および管理し、製品やその他のシステムの分類機能を提供するために使用されます。
製品ブランド: ブランドを作成および管理し、製品やその他のシステムにブランド機能を提供するために使用されます。
製品属性: 属性を作成および管理し、製品や他のシステムに属性機能を提供するために使用されます。
コモディティ: コモディティを作成および管理し、他のシステムにコモディティ機能を提供するために使用されます。

カテゴリ管理、ブランド管理、属性管理、製品管理は、システムアーキテクチャ内で独立して存在し、一方向の依存関係があります。これらは独立したシステムモジュールです。各モジュールは独自の機能を担当し、個別にまたはパッケージで外部にサービスを提供できます。モジュールは、特定のオブジェクトを介して相互接続されます。

分類、ブランド、属性は製品の基本的な構成要素であり、これらが組み合わさって製品を構成します。

商品センターの最も基本的な機能は、フロントエンドの各リンクの商品検索と表示機能をサポートすると同時に、価格センター、マーケティングセンター、注文センター、フルフィルメントセンター、調達システム、在庫センター、倉庫、輸送などの下流システムに商品機能とサービスを提供して、電子商取引システム傘下のすべてのシステムの商品データの統一された入出力を確保することです。

次に、製品センターの 4 つのコアモジュールの一般的な設計ソリューションを紹介します。

2. 分類管理

1. なぜ分類管理が必要なのか？

（スクリーンショットはJD APP分類ページです）

電子商取引プラットフォームは、実際には仮想ウェブサイト上の物理的なスーパーマーケットのマッピングと見ることができます。スーパーマーケットのショッピングシーンでは、消費者が購入したい商品を素早く見つけられるように、スーパーマーケットは商品を分類することがよくあります。

異なるカテゴリーが異なるエリアに配置され、各エリアにはショッピングガイドの標識が付けられ、異なる棚には異なる商品が展示されています。これがスーパーマーケットの分類です。分類により、消費者は欲しい商品をより便利かつ迅速に見つけることができます。

電子商取引のSKU量は実店舗のスーパーマーケットの数千倍であり、電子商取引サイトで目的の商品を検索するのはより困難になります。そのため、スーパーマーケットの分類機能は、当然電子商取引プラットフォームに適用されます。

ユーザーにとって：検索とカテゴリナビゲーションは、消費者が商品を見つけるために最もよく使用される2つの方法です（推奨技術の応用が深まるにつれて、検索とカテゴリの比重はある程度低下しました）。カテゴリナビゲーションは、ユーザーが目的の商品をすばやく見つけるのに役立ちます。カテゴリナビゲーション機能の実現は、商品のカテゴリ管理に依存します。

運営側にとって：大量の商品を管理することは、プラットフォームと販売者にとって大きなコストがかかります。キーワード検索に加えて、分類管理も運営者が特定の商品を素早く見つけるための重要な手段です。分類により、商品管理の効率を向上させることができます。

2. 分類管理の基本設計コンセプト（要点）

分類管理の中心的な設計思想は、フロントエンドとバックエンドの分離、および多対多のマッピングです。

（１）フロントエンドとバックエンドの分離

これは、フロントエンド分類とバックエンド分類の2つの分類システムに設計されていることを意味します。バックエンド分類は主にプラットフォーム管理用であり、その主なロジックは構造化された管理ロジックです（iPhone13∈携帯電話分類、スウェットパンツ∈衣類分類）。フロントエンド分類は主にユーザーエンド用であり、操作のための操作スペースとユーザーの買い物の利便性を提供します。その主なロジックは操作とユーザーエクスペリエンスです（たとえば、フロントエンドのスウェットパンツの分類は「冬の新製品」にすることができ、主な考慮事項は操作効果とユーザーが製品をよりよく見つけられるかどうかです）。

（２）多対多マッピング

前景分類は背景分類に基づく必要があります。前景分類を作成するときは、まず背景分類を選択する必要があります。前景分類と背景分類の間には多対多のマッピング関係があり、つまり、1 つの前景分類で複数の背景分類を選択でき、異なる前景カテゴリで同じ背景分類を選択できます。

3. バックエンド分類設計計画

製品マネージャーはよく「分類管理」、「分類設計」、「分類機能」などについて語りますが、これらは一般的には背景分類管理機能を指し、企業の内部管理機能です。背景分類は実際の製品分類です。

一般的に、商品分類モデルはプラットフォーム構築の初期段階で決定され、後期段階でビジネスの発展（カテゴリの拡大）に応じてアップグレードおよび最適化されるだけです。バックエンド分類が作成された後は、簡単に変更または削除することはできません。

インターフェースの観点から見ると、バックグラウンド分類管理には、主に分類作成と分類管理という 2 つの視覚化機能の部分が含まれます。

（１）カテゴリーの作成

新しいカテゴリを作成するには、カテゴリレベルとカテゴリ名の 2 つの主要なフィールドに入力する必要があります。背景分類のカテゴリ名は、保守と管理を容易にするために、通常、物理的な商品 (携帯電話など) の業界カテゴリに入力されます。カテゴリ名は一意である必要があります。

分類レベルは、一般的には 3 レベルのツリー構造として設計され、第 1 レベル、第 2 レベル、第 3 レベルと段階的に分類されます (レベルが多すぎると複雑になり、レベルが少なすぎると分類の目的が達成されません。具体的な設計は、プラットフォームのカテゴリの複雑さなどの要素に基づいて総合的に検討する必要があります)。

二次レベルまたは三次レベルで新しいカテゴリを作成する場合は、親カテゴリを選択する必要があります。

カテゴリコードとカテゴリ ID は、どちらも特定のルールに従って自動生成されるように設計できます (カテゴリコードはカテゴリ名のピンイン + タイムスタンプで構成されるなど)。カテゴリコードとカテゴリ ID は一意である必要があります。カテゴリが他のシステムによって呼び出され、パラメータとして渡される場合、カテゴリコードまたはカテゴリ ID を介して実装できます。

（２）分類管理

カテゴリー管理は、主にカテゴリー自体の照会、並び替え、変更などの機能を提供します。同時に、カテゴリーに対応する属性やブランドをバインド/アンバインドする機能を設計できます（属性やブランドを作成するときにも、カテゴリーをバインドする機能が利用できます）。

カテゴリーの削除や変更については、前述の通り、一般的に変更することは推奨されません（レベルの変更や親カテゴリーの変更も含む）。変更する場合は、カテゴリーの下位に関連データがあるかどうかを確認する必要があります。関連データがない場合、ある程度の変更は可能です。削除機能はより慎重に設計する必要があります。通常、カテゴリーの下位に関連データ（関連商品、関連フロントエンドカテゴリーなど）がある限り、削除することはできません。削除操作は、カテゴリーの下位に関連データが存在しない場合にのみ実行できます（初期段階では削除機能を設計しないか、削除操作を実行するために高度な権限が必要になるように設計することをお勧めします）。

4. フロントエンド分類設計計画

(JD.com PC 上の商品分類のスクリーンショット)

役割分担の観点から、フロントエンド分類は「ウェブサイト/ APP 操作構成」の機能カテゴリに属し、真の意味での分類機能ではありません。フロントエンド分類を維持する場合、 1 つ以上のバックエンドカテゴリに関連付ける必要があります。ユーザーがカテゴリをクリックしてフロントエンドで製品を検索すると、システムは [フロントエンドカテゴリ - バックエンドカテゴリ - 製品] の 3 レベルのマッピング関係を通じて、フロントエンドカテゴリの下にどの製品を表示するかを照会します。

（カテゴリー管理インターフェース例）

フロントエンドとバックエンドのカテゴリ間の多対多マッピングの設計ロジックは、主に運用上のニーズとユーザーの製品に対する認識の違いを考慮しています。カテゴリナビゲーションのトラフィックは非常に大きいため、運用では推奨カテゴリ、よく使用されるカテゴリなど、いくつかの運用カテゴリを構成することがよくあります。推奨/一般的なカテゴリの場合、それらは本質的に製品属性に直接関係していません。運用上の選択のために、フロントエンドカテゴリは複数の異なるバックエンドカテゴリに関連付けることができます（たとえば、多くのeコマースWebサイトでは、バックエンドカテゴリの携帯電話カテゴリと携帯電話アクセサリカテゴリは、どちらもフロントエンドカテゴリの携帯電話に対応しています）。

3. ブランド管理

1. なぜブランド管理が必要なのか?

大規模な電子商取引プラットフォームのシステムアーキテクチャでは、カテゴリ管理と同様に、ブランド管理は独立した完全な機能です。多くの人が初めてプロダクトシステムに触れたとき、製品を作る際にその製品のブランドをシンプルに記入する設計手法を見たことがあるかもしれません。では、なぜ大手プラットフォームではブランド管理が別途行われているのでしょうか。

大規模な電子商取引プラットフォームでは、ブランドはユーザーが商品を検索したりフィルタリングしたりする重要な手段でもあります。カテゴリが標準化されているほど、ブランドフィルタリングを通じて商品を検索する使用シナリオが増えます（たとえば、JD.comで携帯電話や家電製品を購入する場合、消費者はまずブランドを選択することがよくあります）。

ブランドデータが構造化されておらず、商品を作成する際に運営者や販売者が自由に記入できる場合、同じブランドの商品でも、異なる企業や販売者によって異なるブランドが記入される可能性があります。たとえば、販売者AはXiaomiを「xiaomi」という文字で記入し、販売者BはXiaomiを中国語の「小米」で記入し、販売者Cは「showmi」などの誤ったデータを記入します。基礎となるデータを統一できない場合、ブランドデータを使用する必要があるフロントエンドスクリーニングやその他のシステムは、それを正常に使用できなくなります。

2. ブランドマネジメントをどのように設計するか?

ブランド管理には、主にブランド創造とブランド管理という 2 つの機能が含まれます。

（１）ブランドの創造

ブランド創出には主に2つのシナリオがあります。1つはプラットフォーム側での積極的な創出で、一般的には初期段階で各カテゴリに応じてシステムに直接初期化されます。もう1つは、プラットフォームベースの電子商取引でより一般的な申請方法で、プラットフォームに定着したサードパーティのマーチャントがブランドを申請します（たとえば、Alibaba JDプラットフォームでは、新しく定着したマーチャントが自社所有の新しいブランドであるか、プラットフォームに含まれていない場合は、最初にブランド申請プロセスを経る必要があります。たとえば、初期のTaobaoブランドHan Du Yisheなど）。ブランドはプラットフォームの審査後にブランドライブラリに追加されます。

ブランド構築には通常、いくつかの重要な要素があります。

ブランド中国語名
ブランド英語名: 推奨形式では大文字が必要です
ブランド別名: ブランドには正式名称と俗称があります。俗称の方が正式名称よりもよく知られている場合もあります。4. ブランド登録者
ブランド登録番号
ブランドロゴ: システム表示仕様に適合するように画像のサイズと寸法を制限する必要があります
ブランド登録エリア
その他のフィールドは、プラットフォームの特性や業界の資格要件に応じてカスタマイズされます。

サードパーティのアプリケーションを通じて作成された場合、記入する必要がある情報は、プラットフォームが独自に作成したものと同じです。ただし、ブランド申請プロセスが完了したら、ブランドに提出して審査を受けます（レビュープロセスの設計については、この記事では詳しく説明しません）。審査に合格すると、2番目の販売者は同じブランドの商品を運営する際に、ブランドライブラリから直接選択できます。

（２）ブランドマネジメント

ブランド管理とは、ブランド自体の照会、変更、非アクティブ化、つまり基本的な追加、照会、変更の機能を指します。ブランドを変更または非アクティブ化する場合は、ブランドの下に関連データ（製品、カテゴリなど）がないことを確認する必要があり、そうでない場合は変更または非アクティブ化を実行できないことに注意してください（一部の情報の変更は、他のデータの表示に影響を与えない場合は実行できます）。

もう 1 つの機能は、ブランドと製品カテゴリ間のマッピング関係を設計することです。製品を送信するときにカテゴリを選択すると、カテゴリの下に表示されるブランドが自動的に取得されます (設計しないこともできます。設計しないロジックは、カテゴリを選択した後、ブランドを選択するとすべてのブランドが取得されるためです。どちらのソリューションにも長所と短所があります)。

4. 属性管理

1. 属性とは何ですか?なぜ属性管理が必要なのでしょうか?

属性とは何ですか? ——属性とは、色の属性、サイズの属性、仕様の属性など、製品の固有の特性を指します。

属性の機能は何ですか? ——属性も、商品を分類・集約する上で必要かつ重要な手段です。カテゴリーやブランドは、大量の商品をある程度までしか分類できません。例えば、ユーザーがJD.comで「家電」を購入する場合、カテゴリー（テレビ、エアコン、冷蔵庫、洗濯機など）やブランド（Gree、Xiaomiなど）を通じて、欲しい商品（Xiaomi TVなど）を検索することができます。しかし、ユーザーがさらに素早く、最も正確に意図した結果（Xiaomi TV 55インチ4K版など）を見つけたい場合、カテゴリーやブランドだけでは不十分です。そのため、より細かい区分を実現したい場合は、属性を通じてしか実現できません。

製品のすべてのプロパティは、画面サイズ、解像度、エネルギー効率レベルなどの製品の属性です。しかし、異なるカテゴリーの製品は異なる属性を持っています（例えば、衣料品には画面サイズなどの属性がなく、携帯電話にはサイズ属性がありません）。カテゴリーが豊かになるにつれて、属性データも非常に大きくなります。異なるタイプの製品の属性をより適切に管理し、フォアグラウンドで適用するときに明確でシンプルなロジックを持つためには、属性管理の重要性が非常に重要になります。

2. 属性管理の設計アイデア

属性は、構造的な観点から、属性グループ > 属性 > 属性値の3つの部分に分けられます。

属性グループ: 携帯電話の「外観属性」や「性能属性」など、多数の属性を分類して管理しやすくします。
属性: 色、バージョン、実行メモリなどの特定の属性を参照する属性名。
属性値：属性の特定の値を指します。たとえば、色属性の属性値は、赤、黄、緑です。

上記の 3 つのモジュールは、属性管理を構成します。場合によっては、ビジネスレベルでのコミュニケーションを容易にしたり、口径を統一したりするために、またはその他のアプリケーションシナリオでは、属性分類の設計が導入されます。属性は、属性グループ (比較的抽象的な分類) に基づいて分類され、一般的には基本属性、販売属性、倉庫属性、物流属性、拡張属性に分けられます (属性分類には標準的な設計はありません。独自のプラットフォームの特性に応じて分類することも、属性分類を設計することもできます)。

以下では、携帯電話のカテゴリを例に、属性分類を 3 つのコアモジュールと組み合わせ、表を通じて属性のさまざまな概念を説明します。

以下は、JD.com の iPhone 13 の製品詳細ページのスクリーンショットです。JD.com のフロントデスクでは、この情報は構造化されたフィールド (テキストやグラフィックではない) であり、そのデータは製品の作成時に入力された属性から取得されます。

3. 属性管理の設計

属性グループのコア機能: 作成と管理 (属性のクエリ、変更、バインド)
属性のコア機能: 作成と管理 (クエリ、変更、属性グループのバインド、カテゴリのバインド)
属性値: 属性機能によって異なる

（１）属性グループの作成

（２）属性グループ管理（リスト）

（３）属性グループ管理（詳細）

主な機能は、属性のバインドとアンバインド、および属性グループの有効/無効制御をサポートすることです。無効操作では、属性グループの下に関連データ（属性など）がないことを確認する必要があります。

（４）属性と属性値の作成

属性と属性値の作成には、2 つのシナリオがあります。1 つはプラットフォーム側での積極的な作成であり、もう 1 つはプラットフォームベースの電子商取引のより一般的な適用方法です。つまり、サードパーティの販売者が商品を作成するときに、属性ライブラリ内の属性が不十分な場合は、商品作成インターフェイスで直接属性を追加できます。

プラットフォーム側での属性の作成

関連カテゴリに焦点を当てる：属性はカテゴリに関連付ける必要があります。新しい製品を作成する場合、最初のステップはカテゴリを選択することです。後で属性を選択すると、システムは選択したカテゴリに基づいて対応する属性を照会できます（たとえば、携帯電話のカテゴリでは、衣服のサイズなどの属性は表示されません）。製品をサードパーティに送信するときに、属性/属性値を作成します。

Taobaoサードパーティバックエンドに属性/属性値機能を追加

JD.comのサードパーティバックエンドに属性/属性値機能を追加

以上が属性管理関連機能モジュールの設計紹介です。属性管理のインターフェース（バインドカテゴリ、バインド属性グループ）は属性グループのインターフェースと似ています。

属性の削除とバインド解除は属性グループと同じです。関連付けられているデータがあるかどうかも確認する必要があります。

5. 製品管理

製品管理モジュールは、主に製品の作成と管理、および他のシステムへの製品機能の提供を担当します。これは、製品センターのコアモジュールです。製品管理は、分類、ブランド、属性の 3 つのモジュールにも依存します。

商品の作成を例にとると、商品を作成するときに入力する必要があるフィールドの中で、最も重要なのはカテゴリ、ブランド、属性を選択することです。商品は、カテゴリモジュール、ブランドモジュール、属性モジュールの上に構築されたモジュールであると言えます。

1. 2つの概念 - SPUとSKU

商品モジュールを詳しく説明する前に、「SPUとSKU」という2つの用語について説明する必要があります。電子商取引プラットフォームだけでなく、取引を伴うほとんどのシステムにはSPUとSKUが関係している可能性があります。ほとんどの人がこの2つの名前に触れたことがあると思います。以下は、Baidu 百科事典による SPU と SKU の説明です。

SPU （Standard Product Unit）――標準化された製品単位。これは、商品情報集約の最小単位であり、製品の特性を表す、再利用可能で簡単に検索できる標準化された情報の集合です。

簡単に言えば、同じ属性値と特性を持つ製品は SPU SKU (在庫管理単位) と呼ぶことができます。SKU は入庫と出庫の計測単位で、個、箱、パレットなどの単位になります。SKU は販売できる製品です。

簡単に言えば、SPU は製品を配置し、SKU は商品を配置します。たとえば、携帯電話のカテゴリでは、iPhone 13はSPUであり、iPhone 13 256GブラックはSKUです（JDのSKUには、公開バージョンなどの属性も追加されます）。一般的に、画面サイズ、CPUモデル、ピクセルなどの携帯電話の基本属性など、基本属性はSPUの属性と見なすことができます。色、バージョンなどの販売属性などの販売属性と倉庫および物流属性はSKUに保存されます。

2. 製品を作成する

製品作成機能は、インターフェイスから見ると、いくつかのフィールドに入力するだけの比較的シンプルなものに見えます。ただし、プラットフォームの規模、複雑さ、垂直的な専門知識、その他の要素に応じて、次の 2 つの設計ソリューションに抽象化できます。

解決策 1:複数の SKU を同時に作成し、関連する SPU を同時に生成します。全体的な解決策は、SKU を直接作成することです。複数の異なる属性を維持することは、複数の SKU を生成して維持することを意味します。このソリューションは、ほとんどの 2C 総合 e コマースプラットフォームに適しています (Taobao や JD POP など、この方法で製品を作成します)。

解決策2：まずSPUを作成し、次にSPUに基づいてSKUを作成します。全体的な解決策は、プラットフォームのマスターデータチームがSPUの維持管理を担当し、マーチャント（自営およびPOPを含む）がSPUに基づいてSKUを維持するように運営（または購入および販売）することです。SKUを作成するときは、まずSPUを選択し（SPU内の基本属性はデータチームによって維持されています）、SPUに基づいて販売属性、物流属性などを維持し、次にSKUを生成します。このソリューションは、自動車、医薬品などの専門性の高い垂直B2B業界に適しています。

2つの方向性がある理由は、垂直型B2Bプラットフォーム（伝統的な業界や老舗企業）のマーチャントは運用能力が限られており、2Cプラットフォームのマーチャントに比べて商品属性の維持におけるエラー率がはるかに高いためです。プラットフォームは商品の構造管理に対して高い要求を持っています。同じ商品が複数の異なる属性（車のタイヤのトレッド幅やサイズなど）を持つ異なるマーチャントによって維持されることを避けるために、プラットフォームは多くの場合、専用のデータチームに商品の基本属性、つまりSPUを維持させることを選択します。

さらに、B2B 垂直型電子商取引はカテゴリが少なく、SKU の量が比較的少なく、カテゴリの標準化度が高く、プラットフォームによる統一的なメンテナンスが実現可能であるという特徴があります。

しかし、数万のカテゴリーを持つ総合型ECプラットフォームの場合、プラットフォームのデータチームに頼って統一的に管理するのは現実的ではありません。また、衣料品のような非標準カテゴリーの場合、商品の構造化された管理の需要は低いため、総合型プラットフォーム（JD.com、Taobao）と垂直型プラットフォームの設計方向には違いがあります。

実際には、総合プラットフォーム（JD.com など）でも、カテゴリによって設計方法が異なります。一部のカテゴリには垂直の深さがあり、プラットフォームも SPU を維持し、マーチャントが SKU を作成します。

（1）指示1で説明したSKU設計計画を作成する

この方法は非常に一般的です。TaobaoやJD.comなどの主流の電子商取引プラットフォームのバックエンドを見たことがある人なら、ある程度の印象を持っているはずです。そのロジックは、SKUを直接作成し、SKUと同時に対応するSPUを生成することです。次のTaobaoマーチャントバックエンドの図を参照してください。

(Taobao のサードパーティバックエンドで商品を作成するスクリーンショット - 販売情報の入力)

図からわかるように、同じ基本属性を持つ複数の SKU は同じ SPU に対応しています。色属性 + フライトタイプ属性によって SKU が決定されます。価格と在庫は SKU に保存されます (同じ価格と在庫がバッチで入力された場合でも、データの下部にある SKU ディメンションに従って保存され、フロントエンドの SPU ディメンションに表示されます (エクスペリエンスが向上します))。販売属性を切り替えると、同じ SPU ディメンションで異なる SKU を切り替えることになります。

上記はTmall PC上のiPhone13の商品詳細ページです。iPhone13+Black+128GとiPhone13+Pink+128Gは2つの独立したSKU（異なるskuid）であり、2つのskuに対応するSPUは同じ（spuidは同じ）であることがわかります。

上記はソリューション 1 のコア設計ロジックです。つまり、製品を作成するときに、異なる販売属性を維持することは、複数の異なる SKU を維持することを意味しますが、最終的には同じ SPU が同期的に生成されます。

設計ロジックを理解すれば、機能の設計は非常に簡単です。自社製の背景でもサードパーティ製のポップな背景でも、製品を作成するためのインターフェースは似ており、プロセスに応じて7つのステップに分けることができます。

ステップ 1: カテゴリ (製品分類) を選択します。カテゴリを選択する際は、背景分類が呼び出されることに注意してください (ここでは分類管理サービスが使用されます)。

(画像: Taobao マーチャントバックエンド - 新しい商品の作成 - カテゴリの選択)

カテゴリーを選択すると、システムはそのカテゴリー内の対応するブランドデータを自動的に読み込みます（一部のカテゴリーでは、製品情報を入力する際にブランドを選択する必要があります）。

次の手順は比較的簡単です。対応するフィールドに入力するだけです。ここでは詳細には触れません。参考までに、背景のスクリーンショットを以下に示します。

（写真は、Taobao の販売者がバックエンドで商品を投稿しているスクリーンショットです）

以上が商品作成の設計案です。プラン2とプラン1の違いは、SKUを作成する際にSPUに基づいてSKUを作成する必要があることです。つまり、SPUは社内のデータ運用保守チームによって作成および保守されます。運営者およびサードパーティの加盟店がSKUを作成する場合、まずSPUを選択する必要があります（選択しない場合は申請する必要があります）。具体的なインターフェースはプラン1とあまり変わらないため、この記事では詳しく説明しません。