إدارة جوجل ميرشنت لعملاء شركات التسويق بنظام وايت ليبل: ملكية الحساب وجودة بيانات المنتجات

عندما تبيع شركة تسويق خدمة إدارة ظهور منتجات متجر عميلها على Google، لا تكون المهمة مجرد ربط إعلان بصورة منتج. هناك حساب Merchant Center، ومصدر بيانات يرسل الأسعار والمخزون والروابط، وموقع يشتري منه الناس، وحساب إعلاني قد يستخدم هذه البيانات. في نموذج الوايت ليبل ينفذ شريك متخصص العمل خلف هوية الشركة، لكن ملكية المتجر وقرارات السعر والمخزون وسياسة الإرجاع لا تنتقل إليه تلقائيًا. إذا اختلطت هذه الطبقات، قد يبدو التقرير جيدًا بينما يظل المنتج مرفوضًا أو يتحول حساب العميل إلى أصل يصعب استعادته

هذا الدليل لشركات ووكالات التسويق التي تدير Google Merchant Center لعملائها أو تعيد بيع تنفيذ متخصص تحت اسمها. يشرح ما الذي تبيعه الوكالة حقًا، وكيف تفصل وصولها عن ملكية العميل، ومتى يُراجع مصدر المنتجات، وكيف تصعّد الأخطاء إلى صاحب القرار. لا يعد بزيادة مبيعات أو قبول كل منتج؛ فقبول المنتجات وتوافر الميزات والسياسات يتغير بحسب السوق والحساب ونوع المنتج وحالة الموقع

ما الذي تملكه شركة التسويق في خدمة جوجل ميرشنت وايت ليبل؟

يمكن أن يكون عرض الشركة «إعداد الحساب» فقط، أو «إدارة بيانات المنتجات ومشكلاتها»، أو «ربط Merchant Center بإعلانات Google ومتابعة الحملات»، أو مزيجًا من ذلك. لا تكتب في عرض السعر «إدارة جوجل ميرشنت» من دون تعريف الحد الفاصل. هل سيعدل المنفذ عناوين المنتجات داخل المتجر أم داخل مصدر بيانات تكميلي؟ من يصحح السعر إذا اختلف الموقع عن الخلاصة؟ من يوافق على تغيير الشحن أو الإرجاع؟ من يرد عند تعليق حساب أو رفض منتج؟ هذه الأسئلة تحدد جهد الخدمة أكثر من عدد المنتجات وحده

في وايت ليبل، تكون الوكالة مسؤولة أمام العميل عن الوعد الذي باعته، حتى إن نفذته جهة أخرى. لكن المسؤولية التجارية لا تعني أن تملك الوكالة حساب المتجر أو أن تغير بيانات الأسعار نيابة عن التاجر بلا تفويض. يجب التمييز بين أربعة أدوار: صاحب المتجر الذي يحدد الحقيقة التجارية، شركة التسويق التي تدير العلاقة والاعتماد، شريك التنفيذ الذي يعمل ضمن الصلاحيات المتفق عليها، ومزود المتجر أو التطوير الذي يتحكم في كتالوج الموقع وتغذيته التقنية. قد تجتمع بعض الأدوار لدى فريق واحد، لكن لا بد من تسميتها

إذا كان هدفك تعاقدًا أشمل مع شريك ينفذ باسم شركتك، فراجع صفحة وايت ليبل لشركات التسويق. أما هذا المقال فليس صفحة بيع للخدمة العامة؛ موضوعه قرار محدد داخل حسابات Merchant Center وبيانات المنتجات، وما ينبغي تسليمه واختباره عند تشغيلها لعميل

قبل الوصول إلى لوحة Merchant Center: سجل ملكية الأصول

لا تطلب كلمة مرور العميل كخطوة أولى. ابدأ بجرد حساب Merchant Center ورقمه، الموقع المطالب بملكيته، متجر التجارة الإلكترونية، مصدر بيانات المنتجات، حساب Google Ads المرتبط إن وجد، وأي أداة وسيطة أو تطبيق يرسل المنتجات. دوّن اسم الجهة التي تملك كل أصل في العقد وفي المنصة، ومن يستطيع دعوة المستخدمين أو إزالة وصولهم. قد يرى الشريك المنتجات داخل اللوحة ولا يملك حق إصلاح مصدرها؛ وقد يملك المطور القدرة على تعديل المصدر لكنه لا يرى سبب الرفض في Merchant Center

اكتب في سجل العميل: الرابط والمعرف، مالك الحساب، نوع الوصول الممنوح للوكالة، نوع وصول المنفذ، تاريخ مراجعة الصلاحيات، مسار استرداد الحساب، جهة اعتماد أي تعديل يمس الأسعار أو سياسة المتجر، وحالة الربط بحساب الإعلانات. لا تخزن كلمات المرور في هذا السجل. استعمل الدعوات والروابط الإدارية التي تدعمها المنصة، ومنح أقل صلاحية تحقق المهمة، مع حساب إداري دائم لصاحب المتجر أو الجهة المخولة

إذا كان متجر العميل يعمل عبر سلة أو منصة مشابهة، تحقق من التطبيق أو الربط الفعلي الذي يرسل بيانات المنتجات قبل اقتراح إعادة إنشاء الخلاصة. نقل البيانات إلى ملف يدوي بلا سبب قد يجعل السعر والمخزون يتأخران عن الموقع. كذلك لا تفترض أن كل المنتجات تنتمي إلى بلد عرض واحد أو أن إعدادات الشحن متطابقة بين المناطق. ابدأ بما يبيعه المتجر وكيف يظهر سعره وتوافره لزائر البلد المستهدف بالفعل

هل يستخدم العميل Merchant Center for Agencies؟

أعلنت Google نموذجًا لإدارة وصول الوكالات إلى حسابات عملائها عبر Merchant Center for Agencies. توضح وثائقها أدوارًا على مستوى حساب الوكالة وأدوارًا على مستوى حساب العميل، وإمكانية ربط حسابات العملاء وتوزيعها داخليًا بعلامات وصلاحيات. لكن الوثيقة نفسها تذكر أن هذه الميزة متاحة على نطاق محدود، ولذلك لا تجعلها شرطًا في عرضك أو تفترض وجودها لدى كل شركة أو عميل

إذا كانت الميزة متاحة، قد يرسل مسؤول الوكالة طلب ربط لحساب العميل ويحدد مستوى الوصول المطلوب، ثم يوافق مسؤول حساب التاجر على الطلب. بعد الموافقة، لا تُصبح صلاحية موظف الوكالة أعلى من صلاحية الوكالة نفسها داخل حساب العميل. وهذا تفصيل مهم: لا تكفي كتابة «Admin» على دور داخلي إذا كان ربط الوكالة بحساب التاجر من مستوى أقل. اختبر المهمة الفعلية التي يحتاج الموظف تنفيذها، مثل قراءة المشكلات أو تعديل مصدر البيانات، بدل الاكتفاء برؤية اسم الحساب في القائمة

إذا لم تكن الميزة متاحة، لا يعني ذلك أن العمل يتوقف أو أن الحل هو مشاركة كلمة المرور. استعمل نموذج الوصول الذي توفره واجهة Merchant Center الحالية للحساب المعني، مع دعوات مستخدمين محددين وملكية تبقى لدى العميل، وسجل من لديه حق التعديل. لا تعمم تعليمات الواجهة بين الحسابات إذا كانت مختلفة. اتبع الوثائق الرسمية المحدثة في وقت التنفيذ، وبيّن للعميل أي طلب صلاحية إضافية ولماذا يحتاجه فريقك

احفظ الفصل بين حساب الوكالة وحساب العميل

قد تعمل الوكالة مع متاجر كثيرة. سهولة رؤية الحسابات من لوحة واحدة لا تبرر منح كل موظف وصولًا إلى جميع العملاء. إن كانت أداة إدارة الوكالات متاحة، تصف Google أدوار المسؤول والموظف القياسي وإمكانية استخدام التصنيفات لتحديد الحسابات التي تظهر لفريق معين. اجعل توزيع الوصول مرتبطًا بمهمة الموظف والعميل الذي يخدمه، لا بمن يعمل في الشركة عمومًا. وعند مغادرة موظف أو تغيير شريك تنفيذ، راجع وصوله إلى الحسابات المرتبطة بدل افتراض أن إلغاء بريد واحد حلّ كل المسارات

في نموذج وايت ليبل قد تكون شركة التسويق هي الطرف الذي يتواصل مع التاجر، بينما المنفذ يدير جودّة الخلاصة. ينبغي ألا يخفي هذا الترتيب عن العميل أي علاقة وصول يطلبها النظام أو يوجبها العقد. وثق من طلب ربط الحساب ومن وافق عليه، وما الصلاحية التي مُنحت. إذا كانت واجهة الوكالات غير متاحة واستُخدمت دعوة مستخدم مباشرة، سجّلها بوضوح أيضًا. الشفافية في مستوى الوصول لا تعني كشف تفاصيل تجارية داخلية لا تخص العميل؛ تعني عدم الادعاء بأن الحساب محمي بينما لا يعرف مالكه من يستطيع تغييره

لا تخلط بين إلغاء وصول شريك تنفيذ سابق وحذف حساب العميل أو مصدر بياناته. إزالة مستخدم أو رابط يجب أن تتم بعد وجود بديل مختبر، مع مراعاة حالات الأمن التي تستوجب سحبًا فوريًا. دليل تغيير شريك الوايت ليبل يعالج مسار الانتقال بين منفذين على مستوى الحسابات والخدمات، بينما نركز هنا على خصوصية Merchant Center وبيانات المنتج

مصدر المنتجات هو قلب العمل، وليس ملفًا يُرفع مرة واحدة

تصف وثائق Google إنشاء مصدر بيانات المنتجات بوصفه الطريق لتقديم بيانات السلع إلى Merchant Center. قد يأتي المصدر من منصة المتجر أو ملف أو تكامل آخر بحسب إعداد العميل. مهمة الوكالة ليست اختيار القناة الأسهل للفريق فحسب، بل معرفة أين تعيش الحقيقة التجارية: السعر الحالي، التوافر، عنوان المنتج، الصورة، الرابط والسمات المطلوبة للسوق. إذا تغير السعر في الموقع وبقي المصدر قديمًا، فإن إصلاح نص الإعلان لا يعالج أصل المشكلة

ابدأ بعينة صغيرة من منتجات حقيقية: منتج متاح بسعر عادي، منتج عليه تخفيض معلن، منتج نفدت كميته، منتج له خيارات مثل اللون أو المقاس، ومنتج له شحن مختلف إن وجد. قارن صفحة المنتج بالبيانات المرسلة، ثم حدد من يملك تعديل كل حقل. لا تفترض أن خطأً ظاهرًا في Merchant Center سببه الموظف الذي رفع الخلاصة؛ قد يكون ناتجًا عن تطبيق المتجر أو قالب الصفحة أو توقيت تحديث المخزون

في التسليم وايت ليبل، ينبغي أن تعرف الوكالة ما إذا كان الشريك ينشئ مصدرًا جديدًا أم يحسن مصدرًا قائمًا، وكيف تُستعاد التعديلات إذا خرج من المشروع. احتفظ بخريطة مختصرة لطريقة التحديث والتكرار والاعتماديات والتصديرات المتاحة، من دون نسخ بيانات العميل إلى مكان غير مصرح. إذا كانت هناك قواعد أو ملفات تكميلية أو استبعادات، سجّل سببها وصاحب قرارها. لا تجعل نجاح المنتجات في يوم واحد دليلًا على سلامة المصدر بعد تغير كتالوج المتجر

ملكية الموقع والتحقق: لا تنقل الدومين كي تمنح المنفذ عملًا

قد يحتاج Merchant Center إلى التحقق من موقع المتجر وربطه بالحساب المناسب. في بعض الحالات تتم عملية التحقق تلقائيًا إذا توافرت لدى Google إشارات معتمدة، كما تشرح وثيقة التحقق التلقائي للموقع؛ وفي حالات أخرى يطلب النظام إجراءً يدويًا. لا تضع قاعدة واحدة لكل حساب. افحص حالة الموقع داخل حساب العميل، ومع من توجد صلاحية تعديل DNS أو الموقع إذا احتاج التحقق، وما إذا كانت هذه الصلاحية يجب أن تبقى لدى التاجر أو فريقه التقني

المنفذ قد يحتاج إرشاد العميل إلى خطوة تحقق، لكنه لا يحتاج غالبًا امتلاك الدومين باسمه. لا تضف رمز تحقق دائمًا إلى ملفات الموقع قبل فهم من يملكه وما أثر إزالته لاحقًا. ولا تستبدل موقع العميل أو مسار المنتجات في Merchant Center لمجرد تسهيل تجربة تنفيذية. مثل هذه الخطوات قد تغير ما يمكن عرضه أو كيف تُراجع المنتجات، وقد تمس أصلًا يخص العميل ويستخدمه في خدمات أخرى

دوّن بعد التحقق: عنوان الموقع المعتمد، نوع التحقق كما يظهر في الحساب، المسؤول عن إبقاء الوسيلة، وتاريخ إعادة الفحص عند تغيير الاستضافة أو القالب أو الربط. هذه معلومات تشغيلية تحمي الوكالة من مشكلة مفاجئة عند تحديث الموقع، وتساعد شريكًا جديدًا على فهم الحساب دون إعادة بناء كل شيء من الصفر

الموافقة على المنتج ليست موافقة دائمة على كل تغييره

تشرح صفحة Google الخاصة بالمشكلات في Merchant Center الفرق بين التحذيرات ورفض المنتجات، وتذكر أن اختلاف السعر أو التوافر بين بيانات المنتج وصفحة الهبوط قد يؤدي إلى رفض احترازي. كما قد تنشأ مشكلات من رابط معطل، وصف ناقص، عدم اتساق معلومات الموقع أو منع الزحف. لذلك لا يكفي أن تقول شركة التسويق للعميل «منتجاتك مرفوضة، سنعيد رفعها» قبل معرفة السبب ومصدره

اصنع سجل مشكلات بسيطًا يضم معرف المنتج، البلد والبرنامج المتأثرين إذا ظهرا، نوع الرسالة، وقت ظهورها، الصفحة المقصودة، الحقل المختلف، المسؤول عن الإصلاح، موعد إعادة الفحص، والنتيجة بعد التعديل. استعمل نص المشكلة في حساب العميل لا تخمينًا من مقال عام. إن كان السعر مختلفًا، تحقق من العملة والتخفيض وخيارات المنتج وتوقيت التحديث وصفحة الدفع عند الحاجة. وإن كان الرابط يعيد توجيه الزائر إلى صفحة عامة، أصلح مسار المنتج بدل إخفاء الرفض بحذف المنتج من المصدر فقط

ليس كل تحذير سببًا لتعليق كل الحملات، وليس كل رفض يعني أن الحساب كله محظور. مستوى الأثر يختلف بحسب المنتج والبلد والسياسة. هنا يظهر دور الوكالة: ترتيب الأولويات مع التاجر بحسب المنتجات المهمة والقدرة الفعلية على الإصلاح، دون وعد بقبول تضمنه جهة خارجية. يجب ألا يرسل شريك التنفيذ طلب مراجعة أو تغييرًا جوهريًا في سياسة الموقع قبل معرفة من يملك القرار وما الذي تغير بالفعل

السعر والمخزون والشحن: من يملك «الحقيقة»؟

التاجر يحدد السعر والمخزون وشروط الشحن والمرتجعات؛ مصدر المنتجات يعرض هذه الحقيقة للمنصة. إذا اختلفت البيانات، لا ينبغي للمنفذ اختراع سعر يرضي النظام أو وضع منتج غير متاح على أنه متوفر. ارجع إلى نظام المتجر ومسار تحديثه. بالنسبة للمنتجات ذات الخيارات، تأكد أن الزائر يصل إلى الخيار والسعر الصحيحين، وأن الصفحة تعرض ما يحتاجه لاتخاذ قرار الشراء. قد يتطلب الأمر تدخل مطور المتجر أو إدارة المخزون، وليس فقط متخصص الإعلانات

توثق Google أن اختلاف السعر بين بيانات المنتج وصفحة الهبوط قد يسبب مشكلات في حالة المنتجات، وأن الشحن غير المطبق على بعض الطلبات يحتاج مراجعة الإعدادات والبيانات. لا تحوّل ذلك إلى وصفة عامة «ضع شحنًا مجانيًا» أو «ارفع السعر في الخلاصة». كل متجر له سياسة فعلية ينبغي أن تظهر بدقة. إذا كان للتاجر توصيل لمناطق محددة فقط، فحدد الأسواق والإعدادات بحسب ما يدعمه حسابه بدلاً من فتح مناطق لا يستطيع خدمتها

قد يحدث التعارض في لحظة إطلاق عرض مؤقت. اتفق مسبقًا على تسلسل: من يحدث السعر على الموقع، كيف ينتقل إلى المصدر، متى يفحص Merchant Center، ومن يوقف ترويج منتج إذا لم تتطابق البيانات بعد التحديث. هذا مسار تشغيل، لا مجرد مشكلة تقنية تعرضها لوحة. بالنسبة لشركة تسويق تعمل باسمها، وضوح هذا التسلسل أهم من إظهار أنها «تتحكم بكل شيء» بينما قرار المخزون خارج يدها

الربط مع Google Ads: حسابان مترابطان لا حساب واحد

تشير وثائق Google Ads لربط Merchant Center إلى ضرورة الربط قبل إنشاء حملات Shopping التي تستخدم معلومات المنتجات. لكن صلاحيات Merchant Center لا تساوي تلقائيًا صلاحيات Google Ads، وملكية وسيلة الدفع ليست جزءًا من بيانات الخلاصة. افصل في عرض الخدمة بين إعداد المنتجات وإدارة الحملات والقياس، حتى يعرف العميل ما الذي تديره الوكالة وما الذي يراجعه داخل حساب آخر

قبل الربط أو فك الربط، سجّل معرفي الحسابين، الجهة التي طلبت الربط ووافقت عليه، حالة سياسات الحساب، والحملات التي تعتمد على المنتجات. لا تفك ربطًا قائمًا لأنك تريد تجربة مسار آخر قبل فهم أثره على الحملات النشطة. ولا تنشئ حساب Ads جديدًا تحت ملكية الشريك المنفذ إذا كان لدى العميل حساب قائم يمكن العمل فيه بصلاحية مناسبة. دليل إعلانات جوجل وايت ليبل يشرح ملكية الحساب والفوترة وقياس الحملات بعمق؛ يكمله هذا المقال من جهة مصدر بيانات المنتجات

عندما يُقبل منتج في Merchant Center، لا يعني ذلك أنه حقق ظهورًا أو نقرة أو طلب شراء. لاحقًا افصل تقارير المنتجات المؤهلة عن تقديم الإعلانات، وعن النقرات، وعن زيارات الموقع، وعن الطلبات المدققة. هذا الفصل مهم للوكالة كي لا تعرض عدد المنتجات المقبولة باعتباره مبيعات، وكي لا تنسب تغيّر الأداء إلى إصلاح الخلاصة دون مراجعة الميزانية والموسمية وتجربة الشراء

ما الذي تراجعه الوكالة أسبوعيًا؟

ليس الهدف إنشاء تقرير ضخم لا يقرأه أحد. افتح حالة الحساب والمنتجات ومصدر البيانات في فترة محددة، ثم اسأل: هل ظهرت مشكلة جديدة؟ ما المنتجات المتأثرة؟ هل تصل التحديثات في وقت مناسب؟ هل توجد فروقات سعر أو مخزون؟ هل رابط المنتج يعمل؟ ما حالة الحسابات المرتبطة؟ ثم رتب المهام إلى ما تستطيع الوكالة إصلاحه وما يحتاج قرار التاجر أو تدخل المطور أو سؤال شريك التنفيذ. يتغير تكرار الفحص بحسب حجم الكتالوج وسرعة تبدل الأسعار والإنفاق، ولا يوجد عدد مراجعات واحد يناسب الجميع

إذا استخدمت Merchant Center for Agencies وكانت الميزة متاحة، قد تساعدك لوحة الحسابات المرتبطة والصلاحيات في رؤية عملاء متعددين. لكن لا تحول اللوحة إلى بديل عن مراجعة حساب العميل الحقيقي. في كل تقرير، اذكر تاريخ القراءة ومصدر الرقم وتعريفه وما إذا كان يتعلق بمنتجات نشطة أو معطلة أو بحاجة إلى انتباه. لا تكرر بيانات غير مستقرة في رسالة مبيعات من دون سياق أو إذن العميل

العميل يحتاج قرارًا، لا صور واجهة فقط. مثال: «هناك مجموعة منتجات لا تظهر بسبب اختلاف السعر بين المصدر والصفحة، وفريق المتجر يراجع تحديث الأسعار قبل أن نطلب إعادة الفحص». هذه جملة أفضل من «تم اكتشاف 42 خطأ» من غير تعريف أو مالك إصلاح. العدد السابق هنا مثال صياغي افتراضي، لا حالة عميل ولا قياس فعلي. إذا لا تملك دليلًا على المشكلة، قل إن الفحص لم يكتمل بدل نسبة سبب غير مؤكد للمنصة

متى تُصعّد المشكلة ومن تختار للتصعيد؟

للمشكلة التقنية مسار مختلف عن قرار السعر أو الترخيص أو السياسة. إذا كان المنتج يرسل رابطًا مكسورًا، قد يكون المطور أو مدير المتجر هو مالك الحل. إذا كان الوصف يخالف سياسة عرض أو ينقصه حقل، يحتاج متخصص البيانات والتاجر إلى مراجعة المحتوى. وإذا ظهرت رسالة تعليق حساب، فلا تتعامل معها كخطأ عابر في حقل واحد؛ راجع النص الرسمي المعروض والإجراء المطلوب مع صاحب الحساب، ولا تطلب مراجعة قبل معالجة السبب المفهوم

ضع عتبة تصعيد مرتبطة بالأثر: حساب كامل غير قادر على عرض المنتجات، منتجات رئيسية مرفوضة، مشكلة تظهر فقط في بلد محدد، أو تأخر عادي في تحديث منتج غير حرج. لا تساوِ بينها في الأولوية أو في لغة التقرير. سجل وقت اكتشاف المشكلة ووقت إبلاغ الطرف المخول وقرار الإجراء، دون وعود زمنية لا تدعمها المنصة. الوكالة مسؤولة عن إدارة المسار أمام العميل، لا عن التحكم في مراجعة Google أو قرارها النهائي

إذا اعتمدت على منفذ وايت ليبل، يجب أن يوضح اتفاق العمل ما الذي يفحصه يوميًا أو أسبوعيًا، وما الذي يقدمه دليلًا، وما الذي يحتاج موافقة الوكالة قبل تعديله. لا تنسب تأخر إصلاح صفحة منتج إلى المنفذ إذا كان ينتظر تغييرًا من نظام المتجر، لكن لا تترك هذا الانتظار غير مرئي للعميل. سجل التبعية ومالكها وموعد المتابعة

بريف مناسب لشريك التنفيذ بدل «اضبط لنا ميرشنت»

ارسل للشريك بريفًا لا يحتوي كلمات مرور، ويضم السوق المستهدف، نوع المنتجات، منصة المتجر، مصدر البيانات الحالي، عددًا تقريبيًا من المنتجات إذا كان مأخوذًا من حساب العميل بتاريخ واضح، المشكلات المعروفة، الروابط المهمة، حالة الربط بالإعلانات، من يملك تعديل صفحة المنتج، ومن يعتمد الأسعار والشحن. أضف نطاقًا محددًا: إعداد جديد أو مراجعة حساب قائم أو إصلاح مشكلات أو تشغيل دوري. عدم وجود هذه المعلومات ليس سببًا لاختراعها من تقرير قديم

اسأل المنفذ كيف سيشخص منتجًا مرفوضًا، وكيف يثبت أن إصلاحه وصل من المتجر إلى المصدر ثم إلى حالة المنتج، وكيف يفرق بين مشكلة في الخلاصة وسياسة الحساب. اطلب مثالًا افتراضيًا يوضح منهجه لا كشف بيانات عميل آخر. ابدأ باختبار وصول محدود أو فحص عينة إذا كانت الصلاحيات تسمح، ثم وسع النطاق بعد مراجعة النتيجة. من لا يستطيع تحديد مالك السعر ومالك المصدر قد يَعِد بخدمة لا يمكنه تنفيذها وحده

اتفِق أيضًا على شكل التسليم: سجل الإعدادات، قائمة المشكلات وتصنيفاتها، القرارات التي أخذها التاجر، المنتجات التي لم تُراجع، طريقة تحديث المصدر، حسابات Ads المرتبطة، وأسماء الصلاحيات الفعلية دون كلمات مرور. ضع خانة «لم يفحص» صريحة. وايت ليبل لا يعني استبدال الأدلة بعرض شرائح جميل يحمل شعار الوكالة؛ المخرجات يجب أن تكون قابلة للتشغيل من فريق آخر إن تغير الشريك

مثال افتراضي لمتجر سعودي يغيّر أسعار عروضه

افترض متجرًا سعوديًا يبيع أحذية وأجهزة منزلية، وتدير شركة تسويق له Merchant Center عبر شريك وايت ليبل. يطلق التاجر عرضًا في نهاية الأسبوع، فيتغير السعر على الموقع قبل أن ينعكس في المصدر. تظهر بعض المنتجات بحالة تحتاج انتباهًا. لا يبدأ الشريك بحذفها جميعًا أو إنشاء حساب جديد. يطابق أولًا معرفات المنتجات المتأثرة بروابطها وأسعارها الفعلية، ويتحقق من توقيت تحديث الربط، ثم يسأل مدير المتجر عن السعر المعتمد ومدة العرض

في المثال نفسه، تعدل جهة المتجر مصدر الحقيقة إذا كان به خلل، ويتحقق الشريك من وصول البيانات الجديدة، وتراقب الوكالة حالة المنتجات وتبلغ العميل بالنتيجة الدقيقة. إذا بقي الرفض، يقرأ الفريق سبب المشكلة الحالي داخل الحساب ويراجع الصفحة والبيانات بدل تكرار طلبات المراجعة عشوائيًا. المثال لا يصف حالة حقيقية لإنجاز ولا يثبت مدة زمنية أو نسبة قبول؛ فائدته توضيح أن تصحيح المنتج عمل مشترك بين صاحب الحقيقة التجارية والمنفذ التقني والوكالة المسؤولة عن التواصل

وقد تكون بعض المنتجات ذات خيارات متعددة بأسعار مختلفة. عندها يلزم فحص صفحة الخيار المقصود لا الصفحة العامة فحسب. إذا كان السعر في إعلان التسوق مختلفًا عن السعر الذي يراه العميل بعد اختيار المقاس، فالمشكلة لا تعالج بتغيير عنوان المنتج. ينبغي مراجعة الربط بين معرفات المتغيرات وصفحاتها والتحديثات المرسلة حسب إعدادات المتجر. لا تقدم نتيجة مؤكدة من هذا المثال قبل اختبار حساب حقيقي

حدود السيو: Merchant Center ليس بديلًا عن صفحات منتجات صالحة

قد يظهر المنتج في مواضع مجانية أو مدفوعة بحسب الأهلية والإعدادات، لكن Merchant Center لا يصلح تلقائيًا صفحة المنتج الضعيفة أو بنيتها الداخلية. تحتاج صفحات المتجر إلى وصف دقيق، وروابط تعمل، وتجربة شراء واضحة، وسياسات معروضة بصدق. كما أن إتاحة بيانات المنتج في Merchant Center لا تعني فهرسة كل صفحة عضويًا أو ضمان ظهورها في أي نتيجة. افصل بين حالة المنتج في Merchant Center وتقارير Search Console وترتيب البحث العضوي

إذا كانت الوكالة تبيع أيضًا سيو المتاجر، فحدّد كيف تتلاقى المهمتان دون تكرار وعد واحد في عقدين. محتوى الفئات والمنتجات والزحف والروابط الداخلية مسؤوليات سيو الموقع، بينما صحة الخلاصة وأهلية المنتج والربط بالحسابات جزء من تشغيل Merchant Center. بعض الأخطاء مشتركة، مثل صفحة منتج غير متاحة أو سعر غير متسق. دليل سيو المتاجر وايت ليبل يفصل خدمة السيو للوكالات؛ هذا المقال يركز على إدارة مركز التجار لدى العميل

لا تضع Schema Product مكررًا يدويًا في الموقع لمجرد ظهور تحذير داخل Merchant Center. تحقق أولًا من البيانات المنظمة القائمة ومالكها، ومطابقتها للسعر والتوافر في الصفحة، ومن مصدر المشكلة الذي تسجله Google. الإصلاح غير المنضبط قد يخلق تمثيلات متناقضة للمعلومة نفسها بدل تحسينها. ولا تجعل شارة «متوافق مع السيو» في التقرير تغطي عيبًا في بيانات المنتج الأساسية

كيف تسعّر نطاق الخدمة دون رقم مصطنع؟

السعر لا تحدده كلمة «ميرشنت» وحدها. ابدأ بمصدر البيانات الحالي، حجم الكتالوج وتغيره، عدد البلدان والأسواق التي يعرض فيها المتجر منتجاته، حالة المشكلات السابقة، عدد الحسابات والروابط، وجود مطور متاح، وتكرار المتابعة المطلوب. إعداد حساب نظيف لكتالوج ثابت يختلف عن إصلاح حساب به آلاف منتجات ومتغيرات وأسعار تتغير يوميًا. لا تنشر سعرًا سوقيًا أو هامشًا مزعومًا بلا بيانات عقدية حقيقية

افصل بند التهيئة الأولية عن التشغيل الدوري وعن المشاريع الاستثنائية مثل إعادة هيكلة مصدر البيانات أو معالجة مشكلة سياسة حساب. حدد عدد جولات المراجعة وما يتطلب قرار التاجر أو تعديلًا في المتجر لا يشمله عرض الوكالة. إذا كان الشريك المنفذ سيعالج جزءًا فقط، لا تعرض كامل النطاق للعميل كأنه داخل السعر من غير اتفاق معه. لكل تعديل جوهري سجل موافقة يمنع تحوّل «إصلاح منتج» إلى إعادة بناء متجر بلا تفويض

في نموذج وايت ليبل، ليس هامش إعادة البيع مقياسًا للجودة وحده. قد يكون عرض منخفض ظاهريًا مكلفًا إذا أغفل مراقبة الرفض أو حفظ المعرفة أو توثيق الصلاحيات. قارن قيمة الخدمة بما يستطيع العميل استلامه والتحقق منه: خريطة حسابات، مصدر واضح، سجل مشكلات، قرارات موثقة، وتقارير تميز ما أصلحته الوكالة مما يعتمد على التاجر أو Google

تسليم الخدمة من دون احتجاز الحساب لدى المنفذ

عندما ينتهي نطاق العمل أو يتغير شريك التنفيذ، لا ينبغي أن يبدأ الفريق التالي من كلمة «نسينا من أنشأ الحساب». سلّم رقم Merchant Center، حالة ملكية الموقع، المستخدمين والشركاء المصرح لهم، مصادر البيانات وطريقة تحديثها، قائمة الربط بالإعلانات، المشكلات المفتوحة، آخر قرارات الأسعار والشحن التي أقرها التاجر، ومكان النسخ المسموح بها. لا تنقل أسرارًا أو بيانات عميل إلى مجلد شخصي لمجرد تسهيل التسليم

اختبر الاستلام بعمل فعلي: هل يستطيع الشخص الجديد رؤية حساب العميل الصحيح؟ هل يعرف أين يجد منتجًا مرفوضًا وما مصدر بياناته؟ هل يستطيع التفريق بين مشكلة في الموقع ومشكلة في بيانات المنتج؟ هل يوجد مالك دائم خارج حساب المنفذ؟ لا تحذف وصول المنفذ القديم قبل قدرة المستلم على أداء المهمة الحرجة، إلا في حالة أمنية تستوجب إيقافًا فوريًا مع بديل مؤقت. وحين يُسحب الوصول سجّل ما فُعل لا مجرد عبارة «تم نقل الملف»

لا تفترض أن حذف الوصول يلغي كل ربط أو أن ربط وكالة بعميل يبقى مناسبًا إلى الأبد. راجع قائمة الشركاء والمستخدمين دوريًا، خصوصًا بعد انتقال عميل أو انتهاء عقد. وبما أن Merchant Center for Agencies ليست متاحة لكل الحسابات وفق وثائق Google، اكتب مسار التسليم بناء على الأداة الموجودة فعلًا عند العميل، لا على صورة واجهة من عرض تسويقي جديد

أسئلة شائعة لشركات التسويق

هل من الأفضل إنشاء Merchant Center باسم الوكالة أم العميل؟

ينبغي أن تعكس الملكية الاتفاق الحقيقي وصاحب المتجر وموقعه، مع بقاء وصول إداري موثوق لدى الجهة المخولة. في أغلب سيناريوهات إدارة متجر عميل، لا تحتاج شركة التسويق إلى احتجاز حساب التاجر باسمها كي تدير العمل. راجع الحساب القائم أولًا، ثم امنح الوكالة والمنفذ الصلاحيات المناسبة بدل بناء حساب بديل بلا سبب

هل Merchant Center for Agencies متاح لكل وكالة؟

لا تفترض ذلك. تذكر وثائق Google أن نموذج الوكالات متاح على نطاق محدود حاليًا. إذا ظهر في حسابك، اتبع تدفق الربط والموافقة والأدوار المتاح فيه. وإذا لم يظهر، استخدم صلاحيات الحساب الحالية بحسب واجهة العميل ووثائقها دون مشاركة كلمات مرور أو الادعاء بأن الميزة مفعلة

من يصلح رفض منتج بسبب اختلاف السعر؟

ابدأ بتحديد السعر الصحيح لدى التاجر ثم افحص الموقع ومصدر البيانات وتوقيت تحديثهما. قد يحتاج الحل مدير المتجر أو المطور أو منفذ البيانات، بينما تنسق الوكالة المسار وتبلغ العميل. لا يملك الشريك المنفذ حق اختراع سعر أو تغيير سياسة العرض التجارية لإرضاء اللوحة من دون موافقة صاحب القرار

هل يكفي ربط Google Ads ليظهر المنتج؟

لا. ربط الحساب شرط لاستخدام بيانات المنتجات في بعض الحملات، لكنه لا يثبت أهلية كل منتج أو صحة بياناته أو حالة الموقع. افحص حساب Merchant Center ومصدر المنتج والمشكلات المعروضة، ثم راجع إعدادات الحملة والميزانية والقياس كلًّا على حدة. وجود منتج مقبول لا يساوي ظهورًا مضمونًا أو طلب شراء

هل تنقل الوكالة بيانات منتجات العميل إلى حساباتها الخاصة؟

يتوقف ذلك على بنية الحساب والصلاحيات والعقد، لكن لا ينبغي نقل نسخة كاملة بلا حاجة أو موافقة واضحة. الأفضل إدارة وصول قابل للمراجعة إلى أصل يملكه التاجر، مع مصدر بيانات معلوم وتصديرات محدودة لأغراض مشروعة. يجب أن يعرف العميل من يستطيع قراءة البيانات أو تغييرها، وأن يتمكن من استعادة التشغيل عند تغيير الوكالة

ماذا أضع في التقرير المرسل باسم شركتي؟

اذكر حالة الحساب والمنتجات ذات الأثر، المشكلات الجديدة، ما عولج مع مصدر التحقق، ما ينتظر قرار التاجر أو المطور، والخطوة التالية وتاريخ القراءة. لا تنسب عدد منتجات مقبولة إلى المبيعات، ولا تقدم تخمينًا عن سبب انخفاض الطلبات. اعرض ما تعرفه وما لم تفحصه بوضوح؛ اسم الوكالة على التقرير لا يعفيها من دقة مصدر الأرقام

الخطوة الأولى قبل عرض الخدمة

إذا جاءك عميل يطلب «إدارة جوجل ميرشنت»، لا تبدأ بسعر أو وعد فوري. اطلب قراءة منظمة للحساب والمتجر ومصدر المنتجات والصلاحيات، وحدد ما الذي يملك العميل تغييره وما الذي تحتاجه الوكالة أو شريكها للتنفيذ. بعد ذلك اكتب نطاقًا يقبل الاختبار: حساب العميل محفوظ، الخلاصة معروفة المصدر، أهم مشكلات المنتجات مصنفة، والربط الإعلاني واضح. هذا أساس خدمة وايت ليبل يمكن أن تستمر أو تُسلَّم، لا حيلة لإخفاء من يملك الأصول

لشركة تسويق تبحث عن شريك تنفيذ يناقش معها نطاق العمل تحت هويتها، يمكن التواصل مع إنجاز مع وصف نوع المتجر والحسابات والتحديات القائمة، دون إرسال كلمات مرور أو بيانات عملاء حساسة في الرسالة الأولى. قبل أي تنفيذ، يجب مراجعة صلاحيات العميل وموافقة الأطراف المعنية والمخرجات المتفق عليها