أرسل إلى Microsoft المنتجات التي تستحق الظهور.

«Bing Ads» هو الاسم القديم لما أعادت Microsoft تسميته في عام 2019 إلى Microsoft Advertising. أما أداة كتالوج المنتجات التي لا يزال كثير من المعلنين يسمّونها «Bing Merchant Center» فهي رسميًا اليوم Microsoft Merchant Center (MMC). وإذا كان فريقكم أو وكالتكم أو جدول بيانات قديم لا يزال يشير إلى «Bing Ads»، فهي المنصة نفسها، لكن باسمها الحالي.

تعمل حملات Microsoft Shopping مثل حملات Google Shopping: فأنتم لا تكتبون إعلانًا يدويًا لكل منتج. بل ترفعون خلاصة منتجات منظّمة، وهي كتالوج يضم العناوين والأسعار والصور والمعرّفات، إلى متجر في Microsoft Merchant Center، ثم يقوم محرك العرض لدى Microsoft بتجميع إعلانات المنتجات من هذا الكتالوج وعرضها تلقائيًا كلما تطابق بحث على Microsoft Search Network مع سمات أحد المنتجات. ووفقًا لوثائق Content API الخاصة بـ Microsoft، يمكن إدارة الخلاصات عبر تطبيق الويب الخاص بـ Microsoft Advertising، أو إرسالها عبر FTP/SFTP، أو دفعها برمجيًا عبر Content API القائم على REST على العنوان https://content.api.bingads.microsoft.com/shopping/v9.1/bmc/.

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

يؤدي ربط الكتالوج بـ Microsoft Merchant Center إلى عرض منتجاتكم أمام المتسوقين على Microsoft Search Network، وهي شريحة من الطلب على البحث لا تتداخل بالكامل مع جمهور Google. ويعني ذلك لمعظم المعلنين وصولًا إضافيًا، وغالبًا بتكلفة أقل لكل نقرة مقارنةً بـ Google Shopping، ودون الحاجة إلى بناء كتالوج ثانٍ من الصفر.

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

ولأن مخطط Product لدى Microsoft بُني عمدًا ليكون متوافقًا مع مخطط Google، فإن معظم بيانات المنتج نفسها، مثل العنوان والسعر والصور وGTIN وbrand وMPN، المطلوبة لخلاصة Google Merchant Center تغذّي أيضًا قوائمكم في Microsoft Merchant Center، مما يُبقي جهد الإعداد الإضافي منخفضًا نسبيًا.

تتسم وثائق Content API من Microsoft بصراحة غير معتادة بشأن المواضع التي يستعير فيها مخططها من Google، والمواضع التي يختلف عنه فيها بهدوء. فعدد من الحقول في كائن Product موجود فقط «من أجل التوافق مع Google»: إذ تقبل واجهة Microsoft البرمجية الحقول additionalImageLinks وadwordsGrouping وadwordsLabels وdestinations وtaxes، لكن وثائقها تنص بوضوح على أن Microsoft Merchant Center لا يستخدم هذه الحقول إطلاقًا. وإذا كنتم تعيدون استخدام خلاصة بصيغة Google، فإن هذه الحقول تمر ببساطة دون أي أثر على جانب Microsoft.

كما توثّق Microsoft ميزة لا توجد في Google Shopping بالشكل نفسه: Shopping Campaigns for Brands. في هذا النموذج التعاوني، يرفع المصنّع قائمة منتجات تحتوي فقط على Brand وGTIN وMPN، ويربطها بمتجر شريك التجزئة في Microsoft Merchant Center، ثم يمكن للطرفين المزايدة على القائمة المشتركة من المنتجات المطابقة، مع تقاسم تكلفة النقرات. وتشير وثائق Microsoft إلى أن هذه الميزة تقتصر حاليًا على الولايات المتحدة والمملكة المتحدة، وهي في مرحلة تجريبية مفتوحة للعملاء التجريبيين.

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

يقبل Microsoft Merchant Center الكتالوج الخاص بكم بطريقتين رئيسيتين، وفق وثائقه الرسمية:

1. ملف خلاصة مسطّح يُرفع إلى متجركم أو كتالوجكم، ويُرسل وفق جدول زمني متكرر عبر FTP/SFTP.
2. Content API، وهي واجهة RESTful قائمة على JSON وموثّقة على العنوان content.api.bingads.microsoft.com/shopping/v9.1/bmc/، لإدراج المنتجات الفردية أو تحديثها أو استرجاعها أو حذفها، أو لمعالجتها بشكل مجمّع عبر نقطة النهاية /products/batch.

تحدد نقطة نهاية الدُفعات في Content API حدودًا ملموسة ينبغي التخطيط لها: يمكن أن يتضمن طلب الدفعة الواحد ما يصل إلى 12,000 عنصر، لكن إجمالي حجم الطلب لا يمكن أن يتجاوز 4 MB، ولذلك فإن إرشادات Microsoft تفيد بأنه يمكنكم عادةً إدراج ما بين 2,000 و6,000 عرض غير مضغوط في الدفعة الواحدة (وحتى 12,000 كاملة إذا ضغطتم الحمولة بصيغة gzip مع الترويسة Content-Encoding: gzip). أما طلبات القوائم فتُقسَّم إلى صفحات بحد أقصى 250 منتجًا في كل استدعاء باستخدام max-results وstart-token.

توجد المنتجات داخل متجر في Microsoft Merchant Center، ويمكن أن يحتوي المتجر اختياريًا على عدة كتالوجات (تُحدَّد بالمعامل bmc-catalog-id عند الإدراج). ويحتاج كل عرض ترسلونه إلى أفق انتهاء صلاحية: إذ تؤكد وثائق Microsoft أنه ما لم تحددوا expirationDate صريحًا، تنتهي صلاحية العرض تلقائيًا بعد 30 يومًا من كتابته في المتجر.

يوضح مرجع Content API من Microsoft بجلاء الحقول الإلزامية لإدراج عرض، وتلك التي تصبح إلزامية بشروط معينة. وفقًا للوثائق الرسمية لمورد Products:

تنشئ Feedance خلاصة Microsoft Merchant Center مباشرةً من بيانات المنتجات التي تديرونها أصلًا في متجركم أو نظام PIM، دون تصدير يدوي لجداول البيانات. ويربط محرك الربط حقولكم المصدرية بمخطط Microsoft، بما في ذلك حقول المعرّف المركّب (channel وcontentLanguage وtargetCountry وofferId) التي تقفلها Microsoft بعد الإرسال الأول، ولذلك فإن ضبطها بشكل صحيح منذ البداية أمر مهم.

1. اربطوا متجركم أو مصدر بياناتكم (منصة تجارة إلكترونية أو PIM أو ملف تصدير منتجات موجود) بـ Feedance.
2. اربطوا حقولكم بالسمات المطلوبة والمشروطة لدى Microsoft؛ تنبّه Feedance إلى المعرّفات المفقودة وتطبّق identifierExists: false تلقائيًا عندما لا تتوفر brand أو GTIN أو MPN فعلًا، فلا تتراكم عليكم تحذيرات يمكن تجنبها.
3. أنشئوا الخلاصة بالبنية التي يتوقعها Content API واستيعاب المتجر لدى Microsoft، وسلّموها عبر رفع خلاصة مجدول أو إرسال مباشر عبر API إلى معرّف متجركم في Microsoft Merchant Center.
4. تراقب Feedance حالات المنتجات الناتجة، وهي Approved وWarning وDisapproved وpending وexpiring، بحيث يمكنكم رؤية itemLevelIssues وإصلاحها دون الدخول إلى تطبيق الويب الخاص بـ Microsoft Advertising عند كل فحص.

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

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

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

تعيد Content API من Microsoft رموز حالة موثّقة وملموسة للعروض التي بها مشكلات بدلًا من رفض غامض. وفيما يلي مثالان حقيقيان من مرجع product-offer-statuses الخاص بـ Microsoft:

1. GtinPlusBrandRequiredWarn: «معرّف واحد أو أكثر مفقود: يلزم توفر Brand وGTIN أو Brand وMPN.» وهذا تحذير وليس رفضًا قاطعًا: إذ يضع حقل servability لدى Microsoft علامة «Unaffected»، أي أن العرض ما زال يُعرض، لكن ينبغي إصلاحه، إما بتزويد المعرّفات الفعلية أو بضبط identifierExists على false إذا لم توجد.
2. EVRejectedErr مقترنًا برمز سبب محدد مثل EV_39 («محتوى علامة تجارية»): وهذا رفض نهائي؛ إذ تُظهر وثائق Microsoft أن حقل status للعرض مضبوط على «Disapproved» وأن servability مضبوط على «Disapproved»، أي أن المنتج لن يُعرض إلى أن يتم تصحيح المحتوى المُشار إليه.

وبعيدًا عن مشكلات العناصر الفردية، تؤكد وثائق Microsoft أنه بعد اجتياز التحقق الأساسي، يمر كل عرض بـ«عمليات تحقق ومراجعات إضافية خارج الاتصال، مثل المراجعات التحريرية، وقد تستغرق ما يصل إلى 36 ساعة» قبل أن يصبح مؤهلًا للعرض؛ ولذلك فإن بقاء عرض جديد أو محدَّث بحالة «pending» ليوم كامل سلوك متوقع وليس خللًا. ويعرض ملخص على مستوى المتجر (يمكن الوصول إليه عبر مورد ProductStatuses) أعداد العروض في الحالات approved وdisapproved وexpiring وpending، وهو أسرع طريقة لمعرفة سلامة الكتالوج بنظرة واحدة.

1. قدّموا المعرّفات الثلاثة جميعًا عند وجودها. توضح وثائق Microsoft أنه إذا كان المصنّع قد حدّد GTIN أو brand أو MPN، فيجب عليكم تضمينه؛ فإغفال معرّف معروف يؤدي إلى التحذير GtinPlusBrandRequiredWarn حتى مع استمرار عرض العرض. وإذا لم ينطبق أي منها فعلًا، فاضبطوا identifierExists على false بدلًا من ترك الحقول فارغة.
2. جمّعوا المتغيرات باستخدام itemGroupId. بالنسبة إلى المنتج الذي يُباع بعدة ألوان أو مقاسات أو أنماط، توصي وثائق Microsoft بإنشاء عرض واحد لكل متغير وربطها بقيمة itemGroupId مشتركة، بدلًا من محاولة حشر كل الخيارات في عرض واحد.
3. استخدموا customLabel0 حتى customLabel4 لتقسيم الحملات. هذه الحقول الخمسة موجودة تحديدًا لتتمكنوا من تصفية أجزاء من الكتالوج والمزايدة عليها داخل حملات Microsoft Shopping.
4. أبقوا العناوين والأوصاف خالية من الترويج. كلا الحقلين «قد لا يتضمن نصًا ترويجيًا» صراحةً، وكلاهما يخضع للمراجعة التحريرية؛ فإدراج لغة التخفيضات في العنوان يعرّضه للرفض بدلًا من زيادة النقرات.
5. تتبّعوا انتهاء الصلاحية استباقيًا. بما أن العروض تنتهي صلاحيتها بصمت بعد 30 يومًا من آخر تحديث ما لم تحددوا expirationDate خاصًا بكم، فإن خلاصات الكتالوجات بطيئة الحركة لا تزال بحاجة إلى وتيرة تحديث، حتى لو لم تتغير أي من بيانات المنتج الأساسية.
6. املؤوا shipping للقوائم الألمانية. تحدد وثائق Microsoft الشحن وتسمية الشحن ووزن الشحن على أنها مطلوبة تحديدًا عندما يكون targetCountry هو DE، وهي قاعدة يسهل إغفالها إذا كان سوقكم الرئيسي في مكان آخر.

هل «Bing Ads» ما زال اسمًا فعليًا للمنتج؟ لا، فقد أعادت Microsoft تسمية Bing Ads إلى Microsoft Advertising في عام 2019. و«Bing Merchant Center» أصبح الآن Microsoft Merchant Center. المنصة الأساسية وآليات حملات Shopping لم تتغير؛ الاسم وحده هو الذي تغيّر.

هل يمكنني إعادة استخدام خلاصة Google Merchant Center مع Microsoft؟ إلى حد كبير نعم. يحاكي مخطط Product لدى Microsoft كثيرًا من أسماء حقول Google Merchant Center، كما تُقبل عدة حقول موجّهة لـ Google (destinations وtaxes وadwordsGrouping وadwordsLabels وadditionalImageLinks) لأغراض التوافق فقط، مع أن وثائق Microsoft تؤكد أنها لا تستخدمها. وسيظل عليكم مراجعة الحقول المطلوبة الخاصة بـ Microsoft مثل channel والقواعد المشروطة مثل متطلبات الشحن الخاصة بألمانيا.

هل GTIN إلزامي لكل منتج؟ فقط إذا كان المصنّع قد حدّد واحدًا. تشترط وثائق Microsoft الحقول gtin وbrand وmpn عند وجودها؛ وإذا لم توجد فعلًا، فاضبطوا identifierExists على false بدلًا من تركها فارغة.

ماذا يحدث إذا توقفت عن تحديث الخلاصة؟ وفق وثائق Microsoft، تنتهي صلاحية كل عرض تلقائيًا بعد 30 يومًا من آخر تحديث له (ما لم تكونوا قد حددتم expirationDate خاصًا بكم)، ولا يعود العرض منتهي الصلاحية مؤهلًا للعرض.

كم تستغرق المراجعة بعد إرسال منتج أو تحديثه؟ تفيد وثائق Microsoft بأنه بعد التحقق الأساسي، تمر العروض بمراجعات إضافية خارج الاتصال، منها المراجعة التحريرية، و«قد تستغرق ما يصل إلى 36 ساعة» قبل أن يصبح العرض مؤهلًا للعرض.

هل يمكنني إرسال الخلاصة عبر FTP بدلًا من API؟ نعم، يدعم Microsoft Merchant Center إرسال ملفات الخلاصة بشكل متكرر إضافةً إلى Content API القائم على JSON، بحيث يمكن للفرق التي لا تملك موارد تطوير أتمتة التسليم أيضًا.

Bing Ads هو الاسم السابق لـ Microsoft Advertising، منصة الإعلانات في محركات البحث من Microsoft، التي أُعيدت تسميتها في عام 2019. أما أداة كتالوج المنتجات الخاصة بها، والتي لا تزال تُسمّى غالبًا Bing Merchant Center، فهي اليوم Microsoft Merchant Center.

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

يمكن إرسال الخلاصات على شكل ملفات عبر تطبيق الويب الخاص بـ Microsoft Advertising، أو رفعها وفق جدول زمني عبر FTP أو SFTP، أو إرسالها من خلال Content API. ومخطط المنتجات لدى Microsoft متوافق إلى حد كبير مع مخطط Google، لذلك فإن جزءًا كبيرًا من البيانات نفسها، مثل title وprice وimage وGTIN وbrand وMPN، يغذّي القوائم على المنصتين، مع أن بعض حقول Google يتم تجاهلها وأن العروض تنتهي صلاحيتها بعد 30 يومًا ما لم يتم تحديثها.

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