mcpField
A
amz-category-renoding-fix

amz-category-renoding-fix

github.com/jaygptproマーケティング・グロース11112 回インストール3 日前に更新
リポジトリ

amz-category-renoding-fix について

amz-category-renoding-fixは、Amazon出品者向けにブラウズノードの誤配置を調べ、商品情報の修正依頼を準備するワークフロー型スキルです。販売データと照合し、自主修正からエスカレーションまで案内します。

主な機能

  1. 01現在と適切なノードの確認
  2. 02ノード変更と販売推移の照合
  3. 03適切なブラウズノードの特定
  4. 04カタログ修正ケースの作成
  5. 05自主修正とエスカレーションの案内
  6. 06修正と回復状況の追跡

活用シーン

  1. 01商品ページの急な流入減少の調査
  2. 02カテゴリーフィルターに出ない商品の修正
  3. 03再分類後の商品配置の確認
  4. 04四半期ごとのブラウズツリー監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jaygptpro/amazon-pro-skills --skill amz-category-renoding-fix

インストール後、Claude Code で/amz-category-renoding-fixを入力して読み込まれたか確認します。

詳細

カテゴリーノードの再割り当て修正

Amazonは定期的にブラウズツリーを再編成し、商品を新しいノードへ通知なく移動します。出品商品が誤ったノードへ移動されると、Amazonが誤った検索クエリ群を基準に評価するため、一晩でオーガニック検索での表示機会が30〜70％失われます。このスキルでは、誤った配置を特定し、修正申請を作成します。

いつ使うか

  • 原因がわからないまま、出品商品の売上が急激に落ちたとき。
  • あるカテゴリーで上位表示されるはずの出品商品が、そのカテゴリーの絞り込みに表示されないとき。
  • 商品が再カテゴリー化されたという通知を最近受け取ったとき。
  • 四半期ごとの定期的なブラウズツリー監査。

フレームワーク：ノード監査

ノードの再割り当ての問題を確認するための4つの質問です。

  1. 現在、その出品商品は実際にどのノードにありますか？ 出品商品の詳細ページにあるパンくずリストと、在庫管理に表示されるカテゴリーを確認します。

  2. 本来、どのノードにあるべきですか？ 顧客がその商品を見つけるためにたどる、最も論理的なブラウズパスと、類似する競合商品が配置されている場所を確認します。

  3. この違いは重要ですか？ 再割り当ての中には見た目だけのものもあります。一方、商品の売上を左右するクエリから商品が外れてしまう場合もあります。

  4. データには何が示されていますか？ 再割り当てが疑われる日付の前後で、セッション数とコンバージョンを確認します。

ノードが誤っており、データが低下を示している場合は、修正を申請します。

手順

  1. 情報を集めます。 ASIN、現在のパンくずリスト／ブラウズノードID、想定されるノード、直近のセッション数と売上推移、変更が疑われる日付を集めます。

  2. 変更を確認します。 現在のノードと想定されるノードを比較します。セッション数またはコンバージョンの低下が特定の日付に関連していることを確認します。

  3. 正しいブラウズノードを見つけます。 Amazonのブラウズツリー（BTG）を使うか、類似商品が配置されている場所を確認します。

  4. カタログ修正申請を作成します。 件名：「[ASIN] のブラウズノード修正が必要です」。本文には、現在のノード、変更希望のノード、ビジネス上の理由、変更前後のデータを記載します。

  5. 適切な窓口から申請します。 まずはセルフサービスでの修正を試します。ブラウズツリーガイドを使って正しいノードを選び、出品商品ページまたはカテゴリー出品レポートから、出品商品の推奨ブラウズノード／商品タイプを編集します。セルフサービスでの編集が反映されない場合は、ケースを作成します。ブランド登録済みの出品者は、Brand Registry > Manage Your Case から申請します。それ以外の出品者は、Seller Central > Help > Get Support > Catalog category を使用します。誤った配置を示すスクリーンショットを添付し、正しいブラウズノードIDを記載します。

  6. 解決状況を追跡します。 ノードの再割り当て修正には、通常5〜15営業日かかります。出品商品のパンくずリストとセッション数の回復を確認します。

  7. 品質チェックを実施してから、納品します。

出力形式

## Category Re-Noding Fix. [ASIN]

Current node: [breadcrumb / node ID]
Should be: [breadcrumb / node ID]
Suspected change date: [date]

### Impact
Sessions before: [n/day]   After: [n/day]   Drop: [%]

### Case to file
Subject: Browse Tree Guide correction for [ASIN]
Body:
- Current placement: ...
- Requested placement: ...
- Business reason: ...
- Data attached: sessions and conversion before/after the change

### Submission path
1. Self-serve: edit recommended browse node / item type via the listing or
   Category Listings Report, using the Browse Tree Guide
2. If that fails: Brand Registry case (if enrolled) or Seller Central > Catalog
   support case

実例

キッチン用品のASINで、1日あたり80セッションあったのが突然22セッションに減少しましたが、広告費は横ばいでした。調査の結果、1週間前に商品が「Kitchen and Dining > Cookware and Bakeware > Specific subcategory」から汎用的な親ノード「Home and Kitchen」に移動されたことが、パンくずリストから判明しました。類似する競合商品は、元のサブカテゴリーに配置されていました。セッションデータを添付してケースを申請しました。8日以内に修正され、セッション数は元の水準まで回復しました。

品質チェック

  • 現在のノードと想定されるノードが、曖昧な説明ではなく具体的に記録されている。
  • 低下が推測ではなく、データによって特定の日付に関連付けられている。
  • 類似する競合商品の配置を根拠として、想定されるノードが正当化されている。
  • まずセルフサービスでの修正（出品商品／ブラウズツリーガイドを使ったカテゴリー出品レポートからの修正）を試し、必要に応じて適切なケース窓口（Brand Registry またはカタログサポート）にエスカレーションしている。
  • 回復を確認できるまで、解決状況を追跡している。

よくある間違い

  • 出品情報のせいにする。 問題がブラウズノードの移動であるにもかかわらず、箇条書きを何日もかけて書き直します。
  • 修正前後のデータがない。 セッションデータのない修正依頼は却下されます。
  • 誤った申請経路を使う。 ブランドレジストリの申請経路や Seller Central のカタログカテゴリではなく、一般サポートから申請します。
  • 一度きりの問題と考える。 Amazon は複数の SKU のノードをまとめて変更します。1つ見つかったら、カタログ全体を確認してください。

Jay GPT Pro 制作

Amazon Pro Skills の一部です。本格的な Amazon 販売者向けの本番品質のスキルです。無料でオープンです。Jay Margaliot が制作しました。

Amazon 販売者向けの新しい AI 活用法を毎週、WhatsApp グループで無料公開しています。 こちらから参加できます：https://chat.whatsapp.com/ILX65p1yWcaIG3c9WGHpTY

コメント

Markdown 対応