Googleに言われたことをすべて修正したのに、Merchant Centerがまだ停止されています。ほかに何を求めているのですか？

最初とまったく同じ言葉で再びMisrepresentationを指摘する拒否メールは、あなたの努力への判決のように感じられます。何をしても無駄だった、と。その読み方は理解できますが、たいてい間違っています。

Googleの申し立てへの返信はテンプレートです。「Misrepresentation」はひとつの具体的な問題ではありません。事業者アイデンティティの欠如、フィードとウェブサイトの不一致、ポリシーページの矛盾、薄い・重複したコンテンツ、疑わしいアカウント履歴、支払いプロファイルの不整合など、数十の異なるシグナルを覆う包括カテゴリです。それらのシグナルのどれかひとつでもまだ作動していれば、システムは最初と同じカテゴリ名を返します。メールは「最初の15の問題がすべて残っている」と「14は修正され1つだけ残っている」を区別しません。どちらも同一のメッセージを生成します。

つまり、同じ拒否文面は、まったく異なる3つの現実のいずれとも両立します。

• 大部分は修正済みで、残った1つか2つの問題が同じカテゴリを作動させ続けている。 「すべて修正した」と言うオーナーのストアを監査したとき、私たちが最もよく見るケースです。
• ウェブサイトは修正したが、引き金はそもそもウェブサイト上になかった。 後述するアカウントレベルおよびアイデンティティレベルの要因は、ウェブサイトの修正にはまったく反応しません。
• 申し立てが実質的に再審査されなかった。 数分から数時間で返ってくる申し立ては、自動処理されたのであって読まれたのではありません。心当たりがあるなら、申し立てが数時間で却下される理由をご覧ください。

販売者は、人間の顧客が気づくものを修正します。目に見えるポリシーページ、お問い合わせページ、商品説明、価格。Googleのシステムがチェックするのは別のもの、つまりストアの機械可読でクロスリファレンスされたバージョンであり、そこで「人間にとってのコンプライアンス」と「分類器にとってのコンプライアンス」が静かに乖離します。

「完全に修正済み」のストアでよく見つかるギャップ

これらはどれも、自分のウェブサイトを自分で読み返しても見つかりません。あなたのウェブサイトは人間の目には本当に問題ないからです。見つかるのは、機械と同じやり方でストアを監査したときだけです。ページごとに、フィードのフィールドごとに、アカウント設定ごとに。その監査の体系的なバージョンについては、Merchant Centerの不実表示による停止を修正する方法で説明しています。

ウェブサイトの監査が本当にクリーンな結果を返すこともあります。それでも停止は続きます。それは、Misrepresentationによる停止のかなりの割合がウェブサイトの問題ではまったくないからです。問題はアカウントにあり、どれだけウェブサイトに手を入れてもそれが解消されることはありません。

アカウント履歴とリンクされたアカウント

Googleは単一のアカウントではなく、アカウントのグラフのレベルで信頼性を評価します。あなたのMerchant Centerが、停止済みの古いサブアカウントも含むマルチクライアントアカウント（MCA）の下にある場合、あるいは過去に停止されたアカウントと支払いプロファイル、管理者ユーザー、電話番号、住所、ドメイン履歴を共有している場合、その関連付けはあなたの停止を無期限に存続させることがあります。存在を忘れていた死んだ兄弟アカウント - 放置されたテストアカウント、以前の代理店が作った設定、2年前に閉じたストア - は、リンクされているすべてに静かにその停止を引き継がせます。拒否テンプレートがこれに言及することは決してありません。クリーンなウェブサイトが拒否され続けるとき、リンクされたアカウント構造の確認は最初にやる価値のあることのひとつです。

法人とアイデンティティの不一致

アカウントの背後にある法人は、Googleが参照できるすべての場所で一致していなければなりません。Merchant Centerの事業者名、ウェブサイトに記載された会社名、支払いプロファイル、ドメイン登録、VATや法人登記の記録。「SunGrid」というブランドのストアが「Codershyve SRL」によって運営され、支払いプロファイルは第三の名前になっている場合、個々の要素がすべて正当であっても、アイデンティティの不整合として読まれます。これらの詳細を公的登記簿と照合する検証は日常的に行われ、そこでの不一致は自分のウェブサイトの中からは見えません。何千もの他社と共有されるバーチャルオフィスの住所も同様です。合法ではありますが、弱いアイデンティティシグナルです。

知らないうちに引き継いでいた履歴

• 過去に停止されたドメイン。 あなたのドメインが前の所有者のもとで停止されたストアをホストしていた場合、その履歴を引き継ぐことがあります。
• 「再出発」のアカウント。 このアカウントが以前のアカウントの停止後に開設されたものである場合、新しいストアがどれだけ準拠していても、Googleはそれをシステムの回避とみなす可能性があります。これは、停止が設計どおりに機能している唯一のケースです。
• 代理店のアカウント構造。 マーケティング代理店のMCA内で作成されたアカウントは、そのMCAとその中のすべてのアカウントの信頼プロファイルを引き継ぎます。

拒否された後の自然な衝動は、すぐにもう一度申し立てることです。何か小さな点を調整し、再送信し、期待する。それは我慢してください。この特定の状況では、矢継ぎ早の繰り返し申し立てには実際のコストが伴います。

ほかの魅力的に見える逃げ道も、この状況では同じく非生産的です。止まったままの審査が自然に解決するのを待つことには独自の落とし穴があり、申し立てが「審査中」のまま返事がないときにすべきことで扱っています。そして、人間がついに具体的な説明をしてくれることを期待してサポートにエスカレーションしても、一般的には別のチャネルを通じて同じテンプレートが返ってくるだけです。Merchant Centerのサポートがコピペ回答を送り続ける理由をご覧ください。

ここまでのすべてを踏まえても、核心の不公正は手つかずのままです。あなたは見ることを許されないチェックリストで裁かれ続けています。Googleの内部プロセスの中では、それは変わりません。どの申し立ても、どのサポートチケットも、どのフォームも、あなたのストアが具体的に何にまだ違反しているのかをGoogleに述べさせることはありません。内部プロセスは、Googleが決定の根拠を示す必要がなく、ただ繰り返せばよいように作られています。ポリシーカテゴリ名とヘルプページへのリンクが、システムが与えるように設計された説明のすべてです。その仕組みについては、不実表示による停止が実際に何を意味するのかで解説しています。

欧州連合に拠点を置く販売者には、その非対称性が逆転するルートがひとつあります。停止をEUデジタルサービス法（DSA）に基づく認証された裁判外紛争解決機関にエスカレーションすることです。これはGoogleのシステムの外にある独立した正式な手続きであり、コンプライアンスを完了した販売者が必要とするまさにその形で、やり取りのルールを変えます。

• Googleは独立した審査者に自らの立場を提示しなければなりません。 内部プロセスの中では、テンプレートが回答のすべてです。紛争手続きでは、根拠のないカテゴリ名は回答ではなく弱点になります。私たちが勝訴したケースのひとつでは、Googleがまだ間違っている具体的な点を何ひとつ指摘できなかったことこそが決定的な論拠でした。
• あなたが文書化した修正が、ついに読まれます。 あなたが構築したビフォーアフターの記録 - すべての修正、日付付き、証拠付き - は、証拠に基づく手続きが評価するものそのものであり、自動化された申し立てパイプラインが無視するものそのものです。
• コンプライアンスを完了した販売者は、最も強い申立人です。 このルートは、現に違反があるストアのための抜け穴ではありません。本当にクリーンで、それを証明する文書化された記録を持つストアこそ、このルートの教科書的なケースです。

だからこそ、前のセクションで説明した作業は、それが支えた申し立てが却下されたとしても無駄にはなりません。残存するウェブサイトの問題を排除する監査、リンクされたアカウントと法人整合性の確認、すべての修正の日付付き記録 - そのすべてが紛争のための証拠ファイルになります。このルートがどう機能するのか、誰が利用でき、手続きがどのようなものかの全体像は、Merchant Center停止に対するDSA申し立てルートの概要をご覧ください。

正直な注意点が2つあります。第一に、このルートはEUに拠点を置く事業者だけが利用できます。第二に、これは本当に独立した審査です。実際の違反や資格を失わせるアカウント履歴の問題が残っていれば、審査者はそれを見つけます。だからこそ監査が先なのです。エスカレーションは、監査があなたのケースは強いと言ったときに取るステップであり、監査の代わりではありません。

結論

Googleが求めたことを本当にすべて修正したのにテンプレートが返ってき続けるなら、推測をやめてください。何か具体的で発見可能なものがまだ作動しているか - 確認しなかったページ、触らなかったアカウント設定、知らなかったアカウント履歴の中で - あるいは、あなたのストアはクリーンで、内部プロセスがそれを認めることは決してないかのどちらかです。前者は機械レベルの監査で解決できます。後者は、EUの販売者にとっては、Googleがついにテンプレートではなく具体的な内容で答えなければならない場で解決できます。