悪いデータを公開せずにサプライヤーのカタログのオンボーディングを自動化する方法

カタログのオンボーディングが再発ボトルネックになる理由

新しいサプライヤーは、eコマースシステムが期待する形状にデータを送信することはめったにありません。 1つのスプレッドシートには、1列ごとに製品が含まれている場合があります。別のバージョンでは、親製品を繰り返すこともできます。3分の1は、価格、画像、株式を別々のファイルに分割できます。 列名変更、カテゴリラベルが異なる、重要な値は、フリーテキストの記述内で到着します.

チームは、最初のファイルを手動で解決し、次のバージョンが到着したときに同じ修正を繰り返します。 これは、値のコピー、カテゴリを再構築、重複チェック、失敗した行の配置、空白のフィールドが古い値を削除したり、単独でそれを残すことを意味するかどうかを決定します。 カタログは成長しますが、オンボーディングプロセスはより安全かより速くなります.

便利なオートメーションは、これらの繰り返しの決定を準拠したワークフローに変換します。 供給されたすべての値が信頼できると仮定せず、出版物を第一歩にしません.

ファイルを受け入れる前に公開契約を定義する

公開可能な製品が含まれているものの文書化から始めましょう。 コントラクトは、製品フィールド、バリアントフィールド、商業フィールド、チャネル固有のフィールドを区別する必要があります。 どの識別子が要求されるか、システムが各値、どのフォーマットが受け入れられ、ソースが空白、重複または無効な値を送るときに何が起こるかを記述する必要があります.

Shopifyの宛先では、コントラクトは安定したソース識別子、タイトル、製品ステータス、オプションの定義、少なくとも1つの有効なバリアントを必要とします。 価格と在庫は、サプライヤーファイルではなくERPから来ることができます。 有効化前に画像は、ドラフトが必須である場合があります。 Google Merchant Centerは、製品の種類、市場、目的地に応じて、さらなる属性が必要な場合があります.

この契約は、自動化に明確な境界を与えます。 行は、既知のルールを満たし、承認されたマッピングやニーズレビューによって変換することができます。 その境界がなければ、速い輸入は単にライブカタログに不確実性を動かします.

• 必要なアイデンティティフィールドと各識別子を発行するシステム
• 承認されたプロダクト、変形、価格、在庫および媒体の所有者
• データ型、単位、制御値および特性の限界を受け入れて下さい
• ブランク、除去、交換、変更されていない値のルール
• ドラフト、レビュー、積極的な出版物の要件
• Shopifyおよび製品フィードのチャネル固有の要件

ステージングエリアの各ソースを埋め込む

元のアップロードは変更されず、それをバッチのアイデンティティに割り当てて下さい。 サプライヤー、ファイル名、受信時刻、スキーマバージョン、行数、ファイルチェックサムを記録します。 これは、サプライヤーが後で値が変更されたり、同じ名前で修正されたファイルを送信する理由を尋ねると、信頼できる出発点を作成します.

ライブストアに書き込むことなく、ファイルをステージングレコードにパースします。 変換された値の横にある未加工行を保存します。 関連するファイルが別々に到着したら、行の位置ではなく、明示的なソースキーでリンクします。 製品のファイル、ストックファイル、画像ファイルは、それらが1つの完璧なエクスポートであったりすることなく、独立して処理することができます.

スキーマの漂流は見えるはずです。 新規、名前変更または行方不明の列は、データを誤ったフィールドに静かにシフトする代わりに、影響を受けるマッピングを一時停止する必要があります。 このシステムは、決定が必要な変更を提示しながら、予期しないレコードを処理することができます.

承認されたマッピングを再利用可能なルールに変える

マッチングカラム名に比べ、マッピングは一致しています。 項目と呼ばれる製造者のコラムは製造者の識別子であるかもしれませんが、別の製造者は顧客の直面のタイトルのための項目を使用します。 各マッピングは、ソースフィールド、宛先フィールド、変換、検証、所有権規則を必要とします.

ホワイトスペースのトリミング、承認されたカテゴリーラベルの標準化、既知のユニットの変換、オプション値の分離など、安全かつ反復可能な変換を自動化します。 元の値と適用規則を保ち、結果が説明できるままにします。 自信を持って解釈できない価値は、推測ではなく、レビューにとどまるべきです.

マッピングのバージョン。 カテゴリルールまたは宛先フィールドが変更されると、以前のジョブが生成したルールセットを保持しながら、新しいバッチは新しいバージョンを使うことができます。 ソースファイルが変更された後、カタログ更新を調べることは必須です.

1. ソース列とサンプル値のプロファイル.
2. 各列をプロダクト、変形、関係または商業分野にマップします.
3. 承認された変換と検証ルールを満たします.
4. 代表的なマッピングと意図的に困難な行に対するマッピングをテストします.
5. バージョンとリピート実行を有効にする前に設定されたルールを承認します.

作成前の完成したカタログを検証

検証はフィールド、レコード、関係、バッチレベルで実行する必要があります。 フィールドチェックは、無効な日付、価格、単位、および制御値のキャッチ。 レコードチェックは、必要な属性と有効なバリアントの組み合わせを確認します。 関係は、未知の製品に割り当てられた欠落した両親、重複識別子、画像を特定します。 バッチは、カタログの半分をアーカイブするファイルなど、珍しい合計を調べます.

Google Merchant Centerは、正確で正しくフォーマットされた製品データが不可欠であり、文書に必要なフォーマットと属性の最小限の要件を述べています。 着陸ページと提出されたデータも同意する必要があります。 フィードエラーは、したがって、有用なカタログ品質の信号ですが、データがフィードに達する前に同じチェックが起こるはずです.

明確な結果を生成します。: 準備ができ、警告やブロックで準備できます。 ブロックされたレコードは、ソース行、失敗したルール、および是正措置を示す必要があります。 レコードレベルのディテールのないパーセンテージスコアは、ファイルを修正しなければならない人を助けません.

目隠しを交換する代わりに変更セットを計算する

ステージされたレコードを現在の目的地と比較し、各操作をビルド、更新、変更されていないまま、アーカイブまたはレビューとして分類します。 異なる正確なフィールドを表示します。 これにより、完全なファイルが完全な書き換えになり、出版物の前に理解できる影響を防止します.

安定したソースと宛先識別子を使用してマッチングします。 タイトル、ハンドル、説明は変更が許され、どの商品が更新を受け取るか決定しないでください。 バリアント操作は、バリアント ID や、親製品 ID を必要とするため、価格、SKU またはバーコードは、間違ったオプションの組み合わせに移動できません.

リスト交換について明示してください。 Shopify は、productSet がスカラーフィールドとは異なるリストフィールドを扱います。リストに含まれる値は、目的の完全な状態を記述し、省略されたスカラーフィールドは変更されません。 不完全なバリアントやコレクションリストが供給されていないエントリを削除できるため、ワークフローは区別を理解する必要があります.

変更の危険に対する承認の努力を一致させる

すべての修正が同じレビューを必要としません。 承認された空白のクリーンアップおよび確立されたカテゴリーの同義語は低い危険である場合もあります。 新製品、アイデンティティ変更、削除されたバリアント、大きな価格の動き、互換性のクレーム、および大量ステータスの変更は、より強力な制御に値します.

提案された変更セットの周りの承認ルールを構築します。 レビュアーは、現在の値と提案された値、ソースの証拠、影響を受けたチャンネル、および規則が発射された理由を確認する必要があります。 承認は、そのサプライヤーからのすべての将来のファイルではなく、定義されたバッチとマッピングバージョンをカバーする必要があります.

大量の作業では、ブロックされたレコードが補正キューに残りながら、有効なレコードが進行できるようにします。 出版物の標準を下げることなく、オンボーディング時間を短縮します.

• 既にテストされ、承認された自動承認の変形
• アイデンティティ、削除、互換性、珍しい商業変更のレビューが必要です
• 合計が予想範囲外に落ちるバッチをブロックする
• 理由とソースの証拠で拒否されたレコードを保ちましょう
• バッチを承認したレコード、承認されたもの、いつ

保存可能な結果で制御されたバッチで公開

大規模なカタログは、決定的なバッチに分割する必要があります。 それぞれの操作に不利なキーを与えるため、再試行は2番目の製品を作成せず、同じ変更を2回適用します。 プラットフォームの制限を尊重し、進捗状況を追跡し、すべてのレコードの宛先応答を保存します.

Shopifyは、大きなインポートのためのバルクミューテーション操作を提供し、ステータスと結果がチェックできる操作を返します。 そのproductSetミューテーションは非同期的に実行し、構造化されたユーザエラーを返します。 実用的なレッスンは、ジョブを提出することは、完了と同じではありません。自動化は、操作を監視し、エラーを収集し、最終目的地の状態を調整する必要があります.

Retries は、無効なデータではなく、一時的な障害をターゲットにする必要があります。 タイムアウトまたは一時料金の制限は、バックオフで取得できます。 拒否されたフィールド、未知の識別子または無効なバリアントは修正を必要とします。 両方のカテゴリを混合すると、無限のキューを作成し、壊れたよりも、失敗したバッチが忙しく見えるようになります.

具体的な例: オンボーディング 8,000 の製造者の部品

製品の詳細、バリアントパックサイズ、価格、在庫、画像で8,000部品を受け取る販売代理店を検討してください。 NetSuiteはアイテムの参照と価格を所有しており、Sage 200は別の部門の株式を所有しており、Shopifyは販売チャネルです。 サプライヤーファイルは、説明、カテゴリの提案、技術的な属性に貢献しますが、運用上の値を上書きしないでください.

ステージングのバッチランスは、書き込み前にプロファイルされます。 承認された識別子によってレコードの一致を主張する。 新規レコードは、提案されたShopify製品と多様な構造を受け取ります。 カテゴリー マッピングとユニット変換が自動的に実行されます。, 重複識別子, 欠落した両親と予期しないオプションの組み合わせは、レビューを入力します。.

プレビューレポート 6,920 変更されていないレコード, 640 安全な記述更新, 280 新しいドラフト, 110 警告と 50 ブロックされたレコード. 50行を待つことなく、記述の更新と草案を承認することができます。 価格と在庫は、認可されたシステムに接続されています.

出版物は制御されたバッチで動きます。 各Shopify結果は、ソースレコードと宛先IDに対して記録されます。 失敗したプラットフォームの操作は再調整され、成功したアイテムは目的地でチェックされ、最終レポートは変更されたものを示しています。 次のサプライヤーファイルは、手動演習を再起動するのではなく、承認されたマッピングを再利用します.

ERP、サプライヤー、および店頭の責任を別々に保って下さい

各フィールドに明示的な所有者がある場合、カタログの自動化が最適です。 サプライヤーは、技術的な仕様を所有することができ、ERPはコストと可用性を所有することができます、製品チームは、顧客に直面したコピーを所有することができ、Shopifyは出版物の宛先を維持することができます。 ワークフローは、最新のファイルがすべての競合を獲得できるようにすることなく、それらの責任を組み合わせます.

この分離はまた方向を制御します。 Shopify編集は、承認されたプレゼンテーションフィールドを更新することができますが、準拠したERPアイテム番号を上回る必要はありません。 ERP株式の更新は、製品コピーを交換しないでください。 所有権規則は、同期をコントロールされていない上書きに変えることなく、接続されたシステムに役立ちます.

M.I.A.I カタログオートメーションは、ワークフローベースのエンリッチメント、属性マッピング、品質チェック、人的承認制御のために設計されています。 サプライヤーのオンボーディング、チャネルのリスト作成およびカテゴリの標準化を含む、カタログの分類、濃縮および出版の準備に従ったワークフローを適用します.

速度および正確さを両方測定して下さい

有用な測定は、システムが触れる列の数ではありません。 領収書から出版可能なカタログ、介入なしで処理されたレコードのパーセンテージ、最初のパス検証レート、理由でブロックされたレコード、目的地のエラー率、例外を解決するための時間まで追跡します.

また、繰り返し作業が消えているかどうかを測定します。 良いマッピングは、次のサプライヤーファイルに関するマニュアルの修正を減らす必要があります。 同じ例外が毎週戻ったら、ルール、ソース契約またはサプライヤーのフィードバックを繰り返しクリアするのではなく改善します.

ダウンストリーム結果のレビュー: 必要な属性を持つアクティブなリスト, フィードによって拒否された製品, 欠落画像, 無効な変種, 予期しないアーカイブとソース・オブ・システムと宛先の違いの違い. より高速なオンボーディングは、結果のカタログが信頼されるときだけ価値があります.

カタログのオートメーションの信頼性のチェックリスト

• 書面による出版契約は、必要なフィールドと所有権を定義します.
• すべてのアップロードは、不変なソースのバッチとして保存され、識別されます.
• マッピングは、明示的な変換にテストされ、バージョン管理され、結び付けられます.
• バリデーションは、フィールド、レコード、関係、およびバッチ全体の影響をカバーします.
• 安定した識別子は、製品とバリアントを宛先レコードにマッチさせます.
• プレビューは、作成、更新、変更されていないレコード、アーカイブ、ブロックを区別します.
• 承認はリスクに比例して、定義されたバッチに適用します.
• 完了時に一括ジョブが監視され、エラーが再確認されます.
• 残留物は、本物に再試行不能な故障に限られます.
• 最終監査は、各ソース行を目的地の結果をつなげます.