جاهزية خلاصة المنتجات لـ Agentic Commerce: ما الذي تتطلبه UCP وACP وAI Mode فعلاً

حدث تحوّل بنيوي هادئ في التجارة الإلكترونية خلال الأشهر الثمانية عشر الماضية، وكان أغلب ما كُتب عنه إما مبالغاً فيه أو غامضاً.

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

كانت خلاصة المنتجات دائماً المُدخل الذي تقوم عليه إعلاناتكم. أما اليوم فقد أصبحت المُدخل الذي تقوم عليه التوصية نفسها.

تحدد ثلاثة أنظمة الآن آلية عمل ذلك: بروتوكول Google للتجارة الشاملة (Universal Commerce Protocol – UCP)، وبروتوكول التجارة الوكيلية (Agentic Commerce Protocol – ACP) من OpenAI وStripe، وبرنامج التجار من Perplexity. وكثيراً ما يُكتب عنها كما لو كانت شيئاً واحداً بشعارات مختلفة. وهي ليست كذلك. فهي تستهلك بيانات مختلفة، بصيغ مختلفة، وبمتطلبات مختلفة، وهي متاحة في دول مختلفة.

يتناول هذا الدليل ما يتطلبه كل نظام منها فعلاً على مستوى الحقول، وما يتقاطع بينها حقاً وما لا يتقاطع، وما يستحق العمل عليه إذا لم يصل الدفع الوكيلي (agentic checkout) إلى سوقكم بعد — لأن أغلب قرّاء هذه المدونة لا يبيعون أساساً في الولايات المتحدة.

المشهد العام بصراحة

ملاحظتان قبل المتابعة.

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

الثانية: البروتوكولات تتقارب في البنية التحتية لا في البيانات. تعمل UCP صراحةً إلى جانب A2A وAP2 وMCP. وتقوم ACP على الفكرة العامة نفسها. لكن مخططات المنتجات لديهما تظل مختلفة فعلاً، والخلاصة المبنية لأحدهما لا تصلح مباشرة للآخر. وهذه مشكلة إدارة خلاصات لا مشكلة استراتيجية، وحلها واضح: احتفظوا بمصدر داخلي واحد مُثرى للحقيقة، وولّدوا منه ملفات تصدير مخصصة لكل وجهة.

الطبقة 1: الحد الأدنى للاكتشاف (ينطبق في كل مكان، اليوم)

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

معرّفات المنتجات

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

غياب GTIN لا يُنتج رسالة خطأ. بل يُنتج صمتاً: ببساطة لا يكون منتجكم جزءاً من المقارنة التي يجريها الوكيل. ويُذكر أن Perplexity تحديداً تمنح اكتمال المعرّفات وزناً أكبر مما تمنحه Google.

راجعوا تغطية GTIN كنسبة مئوية من SKU النشطة. وإذا كانت أقل من 90%، فهذا الرقم هو مشروعكم الأول.

اكتمال السمات

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

والتحول الذهني المطلوب هو التالي: لم تعد السمة قيمة تصفية. إنها حجّة. فـ material: full-grain leather ليست مجرد facet — بل هي الجملة التي يستخدمها الوكيل حين يسأل متسوّق عن أي الحقيبتين ستتقادم بشكل أفضل.

الاتساق عبر كل الواجهات

هذا هو المتطلب الأكثر تجاهلاً والأكثر احتمالاً لأن يضر بكم.

المتسوّق البشري الذي يرى ₺2,499 في صفحة منتجكم و₺2,399 في نتيجة مقارنة يهز كتفيه ويمضي. أما الوكيل فيعامل هذا التباين كإشارة على مدى موثوقية بياناتكم — وفشل عملية الدفع لأن السعر تغيّر نتيجة أسوأ بكثير بالنسبة إلى مشغّل الوكيل من مجرد عدم التوصية بكم.

راجعوا الاتساق بين: صفحات منتجاتكم، وخلاصة Merchant Center، والبيانات المنظّمة في الصفحات، وأي قوائم على الأسواق الإلكترونية (marketplaces) تديرونها. يجب أن تتطابق الأسعار والتوافر وشروط الشحن وسياسة الإرجاع. وسياستا الإرجاع والشحن تحديداً باتتا تُقرآن من الوكلاء وتُنقلان إلى المتسوّقين.

الحداثة

<!-- İç link: /feed-update-frequency -->

لم يعد التحديث الليلي للخلاصة كافياً. فـ Shopping Graph من Google يتحدّث بمقياس يُقاس بمليارات القوائم في الساعة ويفضّل البيانات الحيّة؛ وتقبل OpenAI في استيعاب الخلاصات تحديثات بمعدل كل 15 دقيقة.

والسبب ليس شكلياً. فحين يكون الوكيل قادراً على إتمام معاملة، فإن بيانات المخزون القديمة لا تنتج متسوّقاً خاب أمله قليلاً — بل تنتج معاملة فاشلة. والأنظمة التي تُفشل المعاملات يتراجع وزنها.

الهدف العملي: انتشار تغييرات السعر والتوافر خلال 15 دقيقة للمخزون سريع الحركة، وكل ساعة على الأقل لما سواه. ويعني ذلك لأغلب التجار الانتقال من جلب الملفات المجدول إلى التحديثات المعتمدة على API أو على الدفع (push).

صلاحية الزحف

راجعوا ملف robots.txt فيما يخص زواحف الذكاء الاصطناعي. حجبها كثير من التجار بشكل انعكاسي في 2024 و2025 خلال نقاش «هل نسمح للذكاء الاصطناعي بالتدرب على محتوانا»، ولم يعيدوا النظر في القرار قط. وحجب الزاحف الذي يغذّي فهرس تسوق قرار مختلف عن حجب زاحف تدريب — وكثيراً ما يُتخذ بالصدفة، من فريق لم ينظر إليه يوماً كقرار تجاري.

الطبقة 2: Google — السمات الحوارية

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

إلى جانب UCP، أضافت Google مجموعة من السمات الحوارية (conversational attributes) إلى مواصفات بيانات منتجات Merchant Center. وهي اختيارية، وتكمّل بيانات منتجاتكم الحالية، وغايتها المعلنة مساعدة أنظمة الذكاء الاصطناعي والوكلاء الحواريين على فهم الفروق الدقيقة في منتجاتكم. وتؤكد Google أن إدراجها لا يؤثر في حالة الموافقة على منتجاتكم الحالية.

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

إليكم المجموعة:

ويجمع مثال Google التطبيقي، لأحد متغيّرات هاتف، بين item_group_title وvariant_option وquestion_and_answer وproduct_highlight وproduct_detail وrelated_product وpopularity_rank وdocument_link في عنصر واحد إلى جانب السمات القياسية.

لماذا هذه الست، ولماذا هي موجودة فعلاً

انظروا إلى ما تقدمه كل سمة للوكيل:

• question_and_answer هي نص الوكيل. يسأل متسوّق «هل هذه صالحة لغسالة الأطباق؟» فإما أن يملك الوكيل إجابتكم أو لا يملكها. وإن لم يملكها، فإما أن يقول إنه لا يعرف — وهذا يخسركم البيع — أو يوصي بمنافس عبّأ الحقل.
• document_link يمنح الوكيل مستنداً يمكنه الاستدلال به. فتعليمات التركيب تجيب عن «ما مدى صعوبة تركيبه؟». وأوراق المواصفات تجيب عن أسئلة التوافق التي لم تكن لتتوقعوها.
• related_product هي الطريقة التي ينجو بها البيع المتقاطع من اختفاء موقعكم من رحلة التسوق. وrequired_part تحديداً تمنع أسوأ نتيجة في التجارة الوكيلية: أن يشتري متسوّق شيئاً لا يعمل بمفرده.
• item_group_title وvariant_option تحلان المشكلة التي أرهقت خلاصات المتغيّرات منذ وجودها — وكيل يرى ثمانية صفوف ولا يفهم أنها منتج واحد بثمانية مقاسات. إنها مشكلة هيكلة المتغيّرات في سياق جديد.
• popularity_rank هي إخباركم الوكيل بأي منتجاتكم يُباع فعلاً. ولا أحد غيركم يستطيع تزويده بهذه الإشارة.

تعبئتها على نطاق واسع

العائق الصريح: لا أحد لديه عمود question_and_answer جاهز في نظام PIM.

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

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

وعلى مستوى الكتالوج الكامل تصبح المسألة مسألة قواعد: اشتقّوا item_group_title من اسم المنتج الأب، وابنوا variant_option من السمات المخزّنة لديكم أصلاً كاللون والمقاس، واحسبوا popularity_rank من بيانات مبيعاتكم كنسبة مئوية، وربطوا document_link بمكتبة الأدلة لديكم وفق نمط SKU. وفي Feedance تُطبَّق هذه عبر قواعد الخلاصة (Feed Rules) عند كل تحديث، ويمكن إعادة حساب popularity_rank تحديداً تلقائياً من بيانات المبيعات بدلاً من صيانته يدوياً.

ابدؤوا بأعلى 200 SKU من حيث الإيرادات وبثلاثة أزواج أسئلة وأجوبة لكل منها. هذا عمل أسبوع، ويغطي غالبية ظهوركم المرئي للوكلاء.

الطبقة 3: ACP من OpenAI — شكل مختلف فعلاً

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

المنتجات تحتوي على متغيّرات. خلاصة Google مسطّحة: كل متغيّر صف مستقل، يربط بينها item_group_id. أما ACP فتعكس ذلك — إذ يمثل كائن المنتج السجل المرجعي، ويحمل مصفوفة من كائنات المتغيّرات. ويحمل كل متغيّر معرّفه وعنوانه وسعره وتوافره ووسائطه وخياراته.

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

الأسعار أعداد صحيحة بالوحدات الصغرى. { "amount": 7999, "currency": "USD" } تعني 79.99 دولاراً أمريكياً. وليست سلسلة عشرية. وأي خط معالجة يجري حسابات الفاصلة العائمة على الأسعار يجب فحصه قبل أن ينتج بصمت شيئاً خاطئاً.

الأوصاف كائنات لا سلاسل نصية. يقبل كائن description الحقول plain وhtml وmarkdown — ويمكنكم تقديم أي توليفة منها.

روابط سياسات البائع عناصر أساسية. يحتوي كائن seller على links، وأنواعها privacy_policy أو terms_of_service أو refund_policy أو shipping_policy أو faq. أعيدوا قراءة هذه القائمة: الوكيل يريد سياسة الإرجاع لديكم كحقل منظّم. ففي عالم لا يرى فيه المتسوّق موقعكم أبداً، يجب أن تسافر سياساتكم مع المنتج.

الحالة (condition) مصفوفة. ["new"]، ويمكن أن تنطبق أكثر من قيمة — وهذا يستبق مخزون إعادة البيع والمنتجات المجددة.

شكل أدنى:

{
  "id": "SKU12345",
  "title": "Trail Running Shoe",
  "description": { "plain": "Waterproof trail shoe with cushioned sole." },
  "url": "https://example.com/products/SKU12345",
  "media": [
    { "type": "image", "url": "https://example.com/images/SKU12345.jpg",
      "alt_text": "Black trail running shoe", "width": 1200, "height": 1200 }
  ],
  "variants": [
    {
      "id": "SKU12345-BLK-10",
      "title": "Black / 10",
      "barcodes": [{ "type": "gtin", "value": "1234567890123" }],
      "price": { "amount": 7999, "currency": "USD" },
      "list_price": { "amount": 9999, "currency": "USD" },
      "availability": { "available": true, "status": "in_stock" },
      "variant_options": [
        { "name": "color", "value": "Black" },
        { "name": "size", "value": "10" }
      ],
      "categories": [
        { "value": "Apparel & Accessories > Shoes", "taxonomy": "merchant" }
      ],
      "condition": ["new"],
      "seller": {
        "name": "Example Store",
        "links": [
          { "type": "refund_policy", "title": "Returns policy",
            "url": "https://example.com/returns" }
        ]
      }
    }
  ]
}

يرافق ملف الخلاصة ترويسة تحمل feed_id وaccount_id وtarget_merchant وtarget_country — لاحظوا أن الدولة تُحدَّد على مستوى الخلاصة، مما يعني أن التجار متعددي الأسواق يرسلون خلاصة واحدة لكل سوق.

نمط التسليم الذي توصي به OpenAI هو خلاصة كاملة مرة يومياً عبر رفع ملف، مع تحديثات خلال اليوم تُدفع عبر API. ويمكن للكتالوجات الصغيرة تنفيذ الأمرين عبر API.

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

الطبقة 4: Perplexity

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

ما هو معروف:

• البرنامج مجاني ويعتمد على التقديم؛ وقد توسّع الانضمام خلال 2025 و2026.
• تُسلَّم الخلاصة بصيغة CSV أو XML، عبر API أو SFTP أو حاوية S3 مخصصة، بصيغة Google Shopping.
• اكتمال بيانات المنتج يعمل كمُدخل في الترتيب — فالبيانات الأكثر اكتمالاً تمنح النظام مادة أكبر عند توليد المقارنات وملخصات المزايا والعيوب.
• يبدو أن اكتمال المعرّفات وبيانات التقييمات وترميز Schema.org في الصفحات تُوزن بدرجة أكبر مما توزنها Google.
• لا تُشترط الخلاصة تحديداً كي يتم الاستشهاد بكم — فالكتالوج القابل للزحف مع مخطط Product سليم قد يظهر — لكن الخلاصة ترفع فرص أن يكون منتجكم موصى به.
• الميزات التعاملية مقتصرة على الولايات المتحدة. وخارجها يمكن الاستشهاد بكم وربط المستخدمين بكم، لا البيع عبرها.

الخلاصة العملية: في Perplexity، العمل المطلوب هو سلامة Schema.org في صفحات منتجاتكم إضافة إلى بيانات التقييمات، لا تكامل خلاصة جديد. فإذا كانت صفحات تفاصيل المنتج (PDP) لديكم تُصدر أصلاً ترميز Product وOffer صحيحاً مع GTIN والسعر والتوافر وaggregateRating، فقد أنجزتم معظم المطلوب.

الطبقة 5: الدفع — والجغرافيا بصراحة

هنا تنجرف التغطية الإعلامية عادةً، فلنكن دقيقين في ما هو متاح فعلاً.

دفع UCP. متاح لتجار مختارين، مع أهلية للمنتجات في الولايات المتحدة وكندا وأستراليا وقت كتابة هذا المقال. ويظهر كزر شراء (Buy) على القوائم المؤهلة في AI Mode وGemini. وتبقون أنتم البائع المسجّل. ويدفع العملاء عبر Google Pay باستخدام بيانات اعتماد موجودة أصلاً في Google Wallet. وتتطلب المشاركة استيفاء المتطلبات التقنية، وتقديم نموذج اهتمام، وإتمام التنفيذ — والأهم أن القوائم التي تحمل سمة المنتج native_commerce(checkout_eligibility) فقط هي التي ستُظهر زر الشراء.

هذا التفصيل الأخير هو الخلاصة على مستوى الخلاصة. فكل ما عداه في دفع UCP عمل تكامل خلفي؛ أما إشارة الأهلية نفسها فتعيش في بيانات منتجكم.

أعلنت Google في مارس 2026 عن تبسيط الانضمام إلى UCP عبر Merchant Center، إلى جانب إمكانات السلة والكتالوج وربط الهوية، وألمحت إلى توسّع عالمي خلال 2026.

دفع ACP. يتطلب تنفيذ ثلاثة مسارات — خلاصة منتجات، وAPI للدفع، ودفع مفوَّض عبر مزوّد خدمات دفع (PSP) مثل Stripe — وهو مفتوح للشركاء المعتمدين.

Perplexity Buy with Pro. مقتصر على الولايات المتحدة.

إذا كنتم تبيعون خارج الولايات المتحدة

معظم عملائنا يبيعون في تركيا والخليج وأوروبا. وهذا هو الموقف الصريح لهذه الحالة:

الدفع الوكيلي (agentic checkout) غير متاح لكم بعد. أما الاكتشاف الوكيلي فمتاح بالكامل، اليوم.

متسوّق في إسطنبول يطلب من Gemini أو ChatGPT مقارنة منتجات يحصل الآن على إجابة مبنية من بيانات منتجات منظّمة. وما إذا كانت تلك الإجابة تتضمن منتجاتكم يتحدد كلياً بالطبقتين 1 و2 أعلاه — تغطية المعرّفات، واكتمال السمات، والسمات الحوارية، والحداثة، والاتساق. ولا شيء من ذلك يتطلب تكامل بروتوكول، أو كياناً قانونياً أمريكياً، أو طلب وصول مبكر.

لذا فالتسلسل للتاجر خارج الولايات المتحدة واضح:

1. أنجزوا الطبقة 1 بالكامل. فهي مكسب خالص، وتحسّن كذلك أداء Shopping وPerformance Max لديكم حالياً.
2. ابدؤوا الطبقة 2 الآن. السمات الحوارية متاحة في مواصفات Merchant Center القياسية، ولا تحمل مخاطر على الموافقة، وبالكاد عبّأها أحد في سوقكم.
3. راقبوا الطبقة 5. حين يصل الدفع إلى سوقكم، سيتكامل التجار الذين أنجزوا الطبقتين 1 و2 خلال أسابيع. أما من لم يفعلوا فسيبدؤون من كتالوج غير مكتمل.

لا تكمن ميزة التحرك المبكر في أنكم ستبيعون عبر ChatGPT هذا الربع. بل في أن إصلاح جودة بيانات الكتالوج يستغرق شهوراً ولا يمكن شراؤه على عجل حين تُفتح النافذة.

⚠️ موعد نهائي واحد غير اختياري

بمعزل عن كل ما سبق، وبإلحاح أكبر بكثير: سيتوقف Content API for Shopping من Google في 18 أغسطس 2026. وبعد هذا التاريخ تتوقف الاستدعاءات الموجهة إلى نقاط النهاية القديمة v2.1 عن العمل.

ويؤثر ذلك في التكاملات البرمجية فقط — أما عمليات الرفع اليدوية والجلب المجدول وخلاصات Google Sheets فلا تتأثر. والتجار الذين يستخدمون تكاملات المنصات الرسمية (قناة Google & YouTube في Shopify، وGoogle Listings & Ads في WooCommerce) تتولى المنصة أمرهم. أما التكاملات المخصصة وبعض أدوات الأطراف الثالثة فيجب ترحيلها يدوياً إلى Merchant API v1.

أمران للفحص اليوم: في Merchant Center، انتقلوا إلى الإعدادات ← مصادر البيانات (Settings → Data Sources) وانظروا إلى عمود المصدر (Source). فإذا كان مكتوباً «Content API»، فلديكم بند عمل. وانتبهوا إلى أن تسميات الخلاصة (feed labels) لا تنتقل تلقائياً — فإذا كان هيكل حملات Google Ads لديكم يعتمد عليها، فقد يؤدي ترحيل متهاون إلى توقف الحملات عن العرض.

وإذا كانت خلاصتكم تصل إلى Merchant Center عبر Feedance، فإن هذا الترحيل يُعالَج من جانبنا ولا تتغير إعدادات التصدير لديكم.

ماذا يعني «الجاهزية للوكلاء» حقلاً بحقل

جمع الطبقات في رؤية تشغيلية واحدة:

والتمرين المفيد هو قراءة هذا الجدول بالعرض: لاحظوا مقدار السلوك في العمود الأيمن الذي تقوده حقول اختيارية تتركها معظم الكتالوجات فارغة.

قائمة فحص الجاهزية

الأساسيات الواجبة — ابدؤوا بها، فهي تنطبق على كل الواجهات

• [ ] تغطية GTIN أعلى من 90% من SKU النشطة
• [ ] انتشار السعر والتوافر خلال 15 دقيقة إلى ساعة، لا بين ليلة وضحاها
• [ ] اتساق السعر والتوافر والشحن والإرجاع بين الموقع والخلاصة والأسواق الإلكترونية
• [ ] جميع الصور بأبعاد 500×500 على الأقل (وهو أيضاً مطلوب من Google اعتباراً من 31 يناير 2027)
• [ ] ترميز Schema.org صحيح لـ Product وOffer في كل PDP، مع aggregateRating حيث توجد تقييمات
• [ ] عدم حجب زواحف الذكاء الاصطناعي في robots.txt عن طريق الخطأ
• [ ] ربط google_product_category بشكل صحيح، لا تركه للاستنتاج
• [ ] تأكيد اكتمال ترحيل Content API

تنافسي — لم يُنجز معظمها في سوقكم

• [ ] تعبئة question_and_answer لأعلى 200 SKU، بثلاثة أزواج فأكثر لكل منها
• [ ] item_group_title وvariant_option لكل عائلة متغيّرات
• [ ] popularity_rank محسوب من بيانات مبيعاتكم
• [ ] document_link مربوط بمكتبة الأدلة وأوراق المواصفات لديكم
• [ ] related_product للملحقات والقطع المطلوبة
• [ ] video_link للمنتجات الرئيسية
• [ ] اكتمال السمات أعلى من 95% في الشريحة العُشرية الأعلى إيراداً

الطليعة — للتجار في الأسواق المؤهلة

• [ ] توليد خلاصة ACP وتسليمها، خلاصة كاملة يومياً مع تحديثات API خلال اليوم
• [ ] تقديم طلب الانضمام إلى برنامج التجار من Perplexity
• [ ] تقديم نموذج الاهتمام بـ UCP، وإرسال إشارة أهلية native_commerce على القوائم المؤهلة
• [ ] وسم الزيارات والطلبات الصادرة عن الوكلاء بشكل منفصل في التحليلات

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

هل يستحق العناء؟

إجابة متوازنة، لأن الموضوع يجتذب يقيناً أكبر مما تدعمه الأدلة.

أسباب التشكك. كان تبنّي الدفع أبطأ مما أوحت به إعلانات الإطلاق. وأعادت OpenAI علناً ضبط نهجها بعد محاولة Instant Checkout الأولى. ومعظم الميزات التعاملية مقيّدة جغرافياً. والبيانات المنشورة عن الإيرادات الإضافية شحيحة، ومضاعفات النمو التي تبدو مبهرة تبدأ عادةً من قاعدة صغيرة جداً.

أسباب التحرك رغم ذلك. كل ما تقريباً في الطبقتين 1 و2 يحسّن أداءكم المدفوع الحالي بصرف النظر عن تحقق توقعات التجارة الوكيلية. فالسمات المكتملة والمعرّفات الدقيقة وبيانات المخزون الحديثة تجعل Performance Max يعمل بشكل أفضل اليوم. والسمات الحوارية لا تحمل أي خطر على الموافقة. وجودة بيانات الكتالوج مشروع يستغرق شهوراً بلا اختصار — ومن يبدأ حين تصبح الفرصة جلية سيبدأ متأخراً.

والإطار الذي نقترحه: لا تبنوا للتجارة الوكيلية، بل ابنوا كتالوجاً مكتملاً وصحيحاً. فالجاهزية الوكيلية هي ما يبدو عليه الكتالوج المكتمل والصحيح في 2026. وعمل البروتوكولات طبقة رقيقة فوق ذلك، وهو الجزء الذي يمكن إنجازه بسرعة متى صحّت البيانات التي تحته.

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

المصادر

• Google Merchant Center Help — About the Universal Commerce Protocol (UCP): https://support.google.com/merchants/answer/16837055
• Google Merchant Center Help — How to use conversational attributes: https://support.google.com/merchants/answer/17085370
• Google Merchant Center Help — Product data specification: https://support.google.com/merchants/answer/7052112
• Google Developers Blog — Under the Hood: Universal Commerce Protocol: https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
• Google for Developers — Migrate from Content API for Shopping to Merchant API: https://developers.google.com/merchant/api/guides/compatibility/overview
• OpenAI Developers — Product Feed Spec (Agentic Commerce): https://developers.openai.com/commerce/specs/spec
• OpenAI Developers — Agentic Commerce key concepts: https://developers.openai.com/commerce/guides/key-concepts
• Agentic Commerce Protocol: https://www.agenticcommerce.dev/
• Universal Commerce Protocol: https://ucp.dev