معلمات خلاصة المنتجات بصيغة XML القياسية

تفترض معظم المقالات حول خلاصات XML أنكم تبيعون قمصانًا.

كان هذا الافتراض منطقيًا قبل عقد من الزمن، حين كانت «خلاصة المنتجات» تعني ملف Google Shopping لا غير. لكنه لم يعد صحيحًا اليوم. فوكالة السيارات، ومنصة الوظائف، ومجموعة الفنادق، وبوابة العقارات، ومنصة المراهنات، كلها تدير اليوم إعلانات قائمة على الخلاصات، ولا أحد منها يرسل size أو gtin. بل يرسلون أرقام VIN ورموز IATA وعدد غرف النوم وأنواع التوظيف وأوقات انطلاق المباريات.

الآليات الأساسية متطابقة. أما المعلمات فلا.

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

1. ما هي خلاصة XML فعلًا

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

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

تنتج عن ذلك نتيجتان، وهما سبب كون الخلاصات أصعب مما تبدو:

العقد خاص بكل وجهة. مواصفات منتجات Google ومواصفات كتالوج Meta وملف XML للوظائف لدى Indeed لا تكاد تتشارك أي اسم حقل. ولذلك يجب تحويل كتالوج المصدر الواحد بطريقة مختلفة لكل وجهة.

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

2. بنية الملف

تستخدم معظم خلاصات XML الإعلانية RSS 2.0 مع امتداد لمساحة الأسماء. والبنية دائمًا من ثلاث طبقات:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Example Store — Product Feed</title>
    <link>https://example.com</link>
    <description>Full catalogue, updated hourly</description>

    <item>
      <!-- one inventory item -->
    </item>

  </channel>
</rss>

• تصريح XML يحدد الترميز. ويجب أن يكون UTF-8 عمليًا؛ فأي ترميز آخر يسبب تلفًا في الأحرف داخل الكتالوجات غير الإنجليزية، وهو السبب الأكثر شيوعًا لتشوه عناوين المنتجات التركية والألمانية والتشيكية.
• تصريح مساحة الأسماء (xmlns:g="...") هو ما يجعل <g:price> صالحًا. وإذا أغفلتموه فسيتم تجاهل كل عنصر يحمل البادئة بصمت — يُحلَّل الملف، لكن لا يُستورد منه تقريبًا أي شيء.
• <channel> يحتوي على البيانات الوصفية على مستوى الخلاصة.
• <item> هو وحدة واحدة من المخزون. وما تعنيه «وحدة واحدة» قرار وليس أمرًا مسلّمًا به: SKU واحد، أو متغير واحد، أو مركبة واحدة، أو شاغر وظيفي واحد، أو فندق واحد، أو مباراة واحدة.

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

3. النواة العامة

تظهر سبع معلمات في كل مواصفات الخلاصات تقريبًا، بأسماء مختلفة. وإذا فهمتموها فبإمكانكم قراءة أي مواصفات.

ثلاث قواعد بشأن المعرّف تنطبق على الجميع وتسبب ضررًا أكبر من أي حقل آخر:

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

4. معلمات التجزئة / التجارة الإلكترونية

هذه هي المواصفات الأفضل توثيقًا، وهي الأساس الذي تستعير منه معظم القطاعات الأخرى.

المطلوبة

المعرّفات

brand وgtin وmpn وidentifier_exists. يُعدّ GTIN الحقل الذي يحدد ما إذا كان منتجكم يُطابَق مع الرسم المعرفي للمنتجات لدى Google — وبالتالي ما إذا كان سيظهر أصلًا في أسطح المقارنة والتسوق بالذكاء الاصطناعي. فهو ليس اختياريًا عمليًا، أيًّا كان ما تقوله المواصفات.

المتغيرات

item_group_id وitem_group_title وcolor وsize وsize_type وsize_system وmaterial وpattern وgender وage_group.

المتغيرات موضوع قائم بذاته؛ والخلاصة المختصرة أن item_group_id يجب أن يكون متطابقًا داخل المجموعة الواحدة ومشتقًا من بيانات مصدر ثابتة، وأن gender وage_group ثابتان على مستوى المجموعة بينما color وsize ليسا كذلك.

التصنيف

google_product_category (تصنيف Google، بالمعرّف أو بالمسار الكامل)، وproduct_type (تصنيفكم الخاص — وهو الحقل الذي يجعل بنية الحملات ممكنة، وهو حر الصياغة، فاستخدموه).

التجارية

sale_price وsale_price_effective_date وunit_pricing_measure وunit_pricing_base_measure وinstallment وsubscription_cost وloyalty_program.

اللوجستية

shipping وshipping_weight وshipping_length / _width / _height وshipping_label وtransit_time_label وmin_handling_time وmax_handling_time وtax.

التحكم في الحملات

excluded_destination وincluded_destination وads_redirect وcustom_label_0 حتى custom_label_4.

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

الوسائط

additional_image_link وlifestyle_image_link وvirtual_model_link وvideo_link.

منتج تجزئة بسيط لكنه مكتمل

<item>
  <g:id>KRC-4210-BLK</g:id>
  <g:title>Karaca Fine Pearl 6-Person Dinner Set — Black</g:title>
  <g:description>26-piece porcelain dinner set for six. Dishwasher and microwave safe.</g:description>
  <g:link>https://example.com/urun/fine-pearl-6-kisilik</g:link>
  <g:image_link>https://cdn.example.com/krc-4210-blk-01.jpg</g:image_link>
  <g:additional_image_link>https://cdn.example.com/krc-4210-blk-02.jpg</g:additional_image_link>
  <g:video_link>https://cdn.example.com/video/krc-4210.mp4</g:video_link>
  <g:availability>in_stock</g:availability>
  <g:price>4299.00 TRY</g:price>
  <g:sale_price>3499.00 TRY</g:sale_price>
  <g:sale_price_effective_date>2026-11-24T00:00+0300/2026-12-01T23:59+0300</g:sale_price_effective_date>
  <g:brand>Karaca</g:brand>
  <g:gtin>8680150042109</g:gtin>
  <g:condition>new</g:condition>
  <g:google_product_category>672</g:google_product_category>
  <g:product_type>Home &amp; Kitchen &gt; Dinnerware &gt; Dinner Sets</g:product_type>
  <g:custom_label_0>high-margin</g:custom_label_0>
  <g:custom_label_1>bf-2026</g:custom_label_1>
</item>

لاحظوا & و> في product_type. فأحرف & غير المهرّبة في الروابط ومسارات الفئات هي السبب الأكثر تكرارًا لملفات XML التي يفشل تحليلها بالكامل.

5. ما الذي تغيّر في 2026

ثلاثة تغييرات في مواصفات بيانات المنتجات لدى Google تستحق التحرك بشأنها الآن بدلًا من انتظار الموعد النهائي.

الحد الأدنى لدقة الصورة أصبح 500x500 بكسل لكل من image_link وadditional_image_link، في جميع الفئات وطرق التسويق. بدأت التحذيرات بالظهور في Merchant Center في أبريل 2026؛ ويبدأ التطبيق الفعلي في 31 يناير 2027. قد تقوم Google بتكبير بعض الصور الأصغر تلقائيًا، لكن اعتبار ذلك حلًا خطأ — فالصور المكبّرة تبدو مكبّرة، وجودة الصورة عامل مؤثر في نسبة النقر.

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

توسّعت ضوابط الشحن على مستوى المنتج. تحدد handling_cutoff_time موعدًا نهائيًا يوميًا لمعالجة الطلبات، وتحدد minimum_order_value الحد الأدنى للإنفاق المطلوب للتوصيل. كما اكتسبت السمة shipping سمتين فرعيتين هما loyalty_program_label وloyalty_tier_label لمزايا التوصيل الخاصة ببرامج الولاء.

اتجاه الحركة ثابت: تواصل Google نقل التفاصيل التي كانت تقع على مستوى الحساب إلى مستوى المنتج. وكل ما يُعبَّر عنه لكل منتج هو شيء تستطيع طبقة الخلاصة أتمتته ولا تستطيعه العملية اليدوية.

6. خريطة القطاعات

التجزئة صف واحد في هذا الجدول، وليست الجدول كله.

قاعدتان بنيويتان تستحقان الاستيعاب قبل بناء أي شيء:

كتالوج Meta يحتوي على نوع مخزون واحد فقط. لا يمكنكم الجمع بين الفنادق والمنتجات. وإذا كنتم تبيعون كليهما فستحتاجون إلى كتالوجين.

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

7. خلاصات المركبات

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

تقوم سمات المركبات لدى Google فوق النواة المشتركة:

<item>
  <g:id>STK-88214</g:id>
  <g:title>2023 Volkswagen Passat 1.5 TSI Business DSG</g:title>
  <g:description>Single owner, full service history, no accident record.</g:description>
  <g:link>https://example.com/ilan/88214</g:link>
  <g:image_link>https://cdn.example.com/88214-01.jpg</g:image_link>
  <g:price>1450000.00 TRY</g:price>
  <g:condition>used</g:condition>
  <g:brand>Volkswagen</g:brand>
  <g:model>Passat</g:model>
  <g:trim>1.5 TSI Business DSG</g:trim>
  <g:year>2023</g:year>
  <g:vin>WVWZZZ3CZPE000000</g:vin>
  <g:mileage>
    <g:value>42500</g:value>
    <g:unit>km</g:unit>
  </g:mileage>
  <g:body_style>sedan</g:body_style>
  <g:color>Grey</g:color>
  <g:vehicle_fulfillment>
    <g:option>in_store</g:option>
    <g:store_code>IST-01</g:store_code>
  </g:vehicle_fulfillment>
</item>

ما الذي يجعل خلاصات المركبات مختلفة تشغيليًا:

• المخزون بعمق وحدة واحدة. كل عنصر وحدة واحدة. وعندما تُباع يجب أن تغادر الخلاصة فورًا — وليس في مزامنة الغد. فقوائم المركبات القديمة تهدر نقرات مرتفعة التكلفة (CPC) على سيارات لم تعد موجودة وتضر بجودة الحساب.
• تكرار التحديث هو جوهر اللعبة. دورات التحديث كل أربع ساعات ممارسة معتادة في قطاع السيارات، وليست تحسينًا إضافيًا.
• اتساق صفحة الهبوط مفروض. يجب أن يطابق السعر وعدد الكيلومترات في الخلاصة صفحة تفاصيل المركبة تمامًا. فتغيير سعر شامل في المعرض يحدّث الموقع دون الخلاصة يتسبب بموجة من الرفض خلال ساعات.
• تستخدم إعلانات مخزون السيارات من Meta مفردات حقول منفصلة — state_of_vehicle وexterior_color وtransmission وdrivetrain وdealer_id — ولذلك تحتاج بيانات المصدر نفسها إلى تحويل مختلف لكل قناة.

8. خلاصات السفر

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

الفنادق

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

المعلمات الأساسية: hotel_id وname وdescription وbrand وurl وimage وlatitude وlongitude وaddress (مع city وregion وcountry وpostal_code) وbase_price وcurrency وstar_rating وneighborhood وphone وguest_ratings.

<item>
  <g:hotel_id>HTL-BDR-114</g:hotel_id>
  <g:name>Blue Bay Resort Bodrum</g:name>
  <g:description>Seafront resort with private beach, three restaurants and a spa.</g:description>
  <g:url>https://example.com/otel/blue-bay-bodrum</g:url>
  <g:image>https://cdn.example.com/htl-114-01.jpg</g:image>
  <g:latitude>37.0344</g:latitude>
  <g:longitude>27.4305</g:longitude>
  <g:address>Yalıkavak Mah. Sahil Cad. 12, Bodrum, Muğla, TR, 48990</g:address>
  <g:base_price>4200.00 TRY</g:base_price>
  <g:star_rating>5</g:star_rating>
  <g:neighborhood>Yalıkavak</g:neighborhood>
</item>

الرحلات الجوية

العنصر هنا هو مسار وليس مقعدًا. والهوية هي زوج نقطة الانطلاق والوصول: origin_airport وdestination_airport برمزي IATA، إضافة إلى price وurl وimage وdescription. الأسعار عادةً أسعار «ابتداءً من» وتتغير باستمرار، ما يجعل تكرار التحديث هو القيد الحاسم.

الوجهات

العنصر هنا هو مكان تبيعون السفر إليه: destination_id وname وaddress وneighborhood وtypes وprice وurl وimage. وهو مفيد للاستقطاب في أعلى مسار التحويل حين يكون لدى المسافر نية السفر دون أن تكون لديه منشأة محددة في ذهنه.

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

9. خلاصات العقارات

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

المعلمات الأساسية: home_listing_id وname وdescription وaddress وlatitude وlongitude وurl وimage وprice وcurrency وproperty_type (شقة، منزل، أرض، تجاري) وlisting_type (للبيع، للإيجار، قيد الإنشاء) وnum_beds وnum_baths وarea_size وarea_unit وyear_built وavailability وagent_name وagent_phone.

<item>
  <g:home_listing_id>EMK-2291</g:home_listing_id>
  <g:name>3+1 Apartment with Sea View — Kadıköy</g:name>
  <g:description>Renovated 3+1 apartment, 4th floor, elevator, closed parking.</g:description>
  <g:address>Caferağa Mah., Kadıköy, İstanbul, TR</g:address>
  <g:latitude>40.9862</g:latitude>
  <g:longitude>29.0299</g:longitude>
  <g:url>https://example.com/ilan/2291</g:url>
  <g:image>https://cdn.example.com/emk-2291-01.jpg</g:image>
  <g:price>12500000.00 TRY</g:price>
  <g:property_type>apartment</g:property_type>
  <g:listing_type>for_sale</g:listing_type>
  <g:num_beds>3</g:num_beds>
  <g:num_baths>2</g:num_baths>
  <g:area_size>135</g:area_size>
  <g:area_unit>sq_m</g:area_unit>
  <g:availability>available</g:availability>
</item>

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

10. خلاصات الوظائف

يستخدم التوظيف بنية مستند مختلفة تمامًا — <source> و<job> بدلًا من <rss> و<item> — ومن المفيد الاطلاع عليها لأنها توضح أن «خلاصة XML» نمط وليست مخططًا واحدًا.

<?xml version="1.0" encoding="UTF-8"?>
<source>
  <publisher>Example Company</publisher>
  <publisherurl>https://example.com</publisherurl>
  <lastBuildDate>Wed, 12 Aug 2026 09:00:00 GMT</lastBuildDate>

  <job>
    <title><![CDATA[Senior Backend Engineer]]></title>
    <date><![CDATA[Mon, 10 Aug 2026 08:00:00 GMT]]></date>
    <referencenumber><![CDATA[ENG-4471]]></referencenumber>
    <url><![CDATA[https://example.com/careers/eng-4471]]></url>
    <company><![CDATA[Example Company]]></company>
    <city><![CDATA[İstanbul]]></city>
    <state><![CDATA[İstanbul]]></state>
    <country><![CDATA[TR]]></country>
    <postalcode><![CDATA[34394]]></postalcode>
    <description><![CDATA[<p>We are hiring a senior backend engineer to work on our data pipeline...</p>]]></description>
    <salary><![CDATA[120000 - 160000 TRY monthly]]></salary>
    <jobtype><![CDATA[fulltime]]></jobtype>
    <category><![CDATA[Engineering]]></category>
    <experience><![CDATA[5+ years]]></experience>
  </job>

</source>

أربع قواعد خاصة بخلاصات الوظائف:

1. CDATA هو القاعدة وليس الاستثناء. تحتوي أوصاف الوظائف على HTML وعلامات & وفواصل علوية. ولف كل حقل بـ <![CDATA[...]]> يتجنب فئة كاملة من أخطاء التحليل.
2. الموقع يحتاج على الأقل إلى المدينة والولاية والدولة. وإذا أغفلتموها يفقد الإعلان الوظيفي ظهوره العضوي لدى كبرى المجمّعات افتراضيًا.
3. يجب حذف الوظائف المشغولة، لا وسمها كمغلقة. لا يوجد ما يعادل availability. فالوجود في الخلاصة هو إشارة التوفر، وتعاقب المجمّعات الخلاصات التي تحمل إعلانات قديمة.
4. لغة واحدة، إدخال وظيفي واحد. الإعلان المنشور بلغتين يحتاج إلى إدخالين منفصلين برقمي مرجع مختلفين.

وبمعزل عن الخلاصة، فإن بيانات JobPosting المنظمة بصيغة JSON-LD في صفحة الوظائف هي ما يجعل الوظيفة مؤهلة للظهور في قوائم الوظائف ضمن نتائج البحث. والاثنان متكاملان: الخلاصة تتولى التوزيع إلى المجمّعات، والبيانات المنظمة تتولى البحث العضوي. ومعظم فرق التوظيف تنفذ أحدهما دون الآخر.

11. المخزون المرتبط بوقت محدد

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

مباريات كرة القدم. الحفلات الموسيقية. عروض السينما. مغادرات الرحلات الجوية. لوطات المزادات. مواعيد حجز المطاعم. نوافذ التوصيل.

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

النهج الذي ينجح هو نمذجتها كمنتجات كتالوج عادية وترميز البعد الزمني في حقول تفهمها المنصة أصلًا:

<item>
  <g:id>MTC-2026-08-16-GS-FB</g:id>
  <g:title>Galatasaray - Fenerbahçe | Super League, Week 2</g:title>
  <g:description>Saturday 16 August, 19:00. Live odds and in-play betting.</g:description>
  <g:link>https://example.com/mac/2026-08-16-gs-fb</g:link>
  <g:image_link>https://cdn.example.com/creatives/mtc-2026-08-16-gs-fb.jpg</g:image_link>
  <g:availability>in_stock</g:availability>
  <g:price>1.00 TRY</g:price>
  <g:product_type>Football &gt; Super League &gt; Week 2</g:product_type>
  <g:custom_label_0>2026-08-16</g:custom_label_0>
  <g:custom_label_1>derby</g:custom_label_1>
  <g:custom_label_2>ms1-2.10</g:custom_label_2>
  <g:expiration_date>2026-08-16T19:00+0300</g:expiration_date>
</item>

ثلاثة أمور تجعل هذا النهج ناجحًا:

• expiration_date أو قاعدة إزالة مكافئة بحيث يغادر العنصر الكتالوج لحظة انطلاق المباراة وليس عند المزامنة المجدولة التالية.
• تسميات مخصصة تحمل البعد الزمني بحيث يمكن هيكلة الحملات حول «نهاية هذا الأسبوع» أو «الديربي» أو «الأودز فوق 2.0».
• تصميم إبداعي لكل عنصر. وهنا يتعثر النهج عادةً. فقائمة مباريات تضم عدة مئات من المباريات أسبوعيًا تحتاج إلى عدة مئات من الصور، تحمل كل منها الفريقين والتاريخ والوقت والأودز الحالية. ولا يستطيع أي فريق تصميم إنتاج ذلك. وتوليد التصميم من صف الخلاصة هو الطريقة الوحيدة التي تواكب هذا الحجم — وهكذا بالضبط شغّلت Bilyoner إعلانات الكتالوج للمرة الأولى، ورفعت ROAS بنسبة 49%.

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

12. خلاصات المخزون المحلي

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

المعلمات: id وstore_code وquantity وprice وsale_price وsale_price_effective_date وavailability وpickup_method (شراء، حجز، شحن إلى المتجر، غير مدعوم) وpickup_sla (في اليوم نفسه، اليوم التالي، عدة أيام).

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

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

13. قواعد التنسيق

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

الترميز. UTF-8 دائمًا، مصرّح به في تصريح XML ومقدَّم مع ترويسة Content-Type مطابقة. عدم التطابق بين الترميز المصرّح به والفعلي يُتلف كل حرف غير ASCII.

التهريب. يجب تهريب خمسة أحرف في محتوى XML: & ← &، < ← <، > ← >، " ← "، ' ← '. وعلامات & غير المهرّبة في روابط التتبع هي السبب الأول للخلاصات التي لا تُحلَّل. والبديل هو CDATA، وهو ممارسة قياسية في خلاصات الوظائف ومفيد في أي مكان تحتوي فيه الأوصاف على وسوم.

التواريخ. ISO 8601 مع إزاحة صريحة للمنطقة الزمنية. 2026-08-16T19:00+0300 وليس 16.08.2026 19:00. والخلاصات التي تخدم عدة أسواق من مصدر لا يراعي المناطق الزمنية تنتج عناصر تنتهي صلاحيتها قبل الأوان أو بعده بساعات.

الأسعار. القيمة مع رمز العملة وفق ISO 4217، وفاصلة عشرية بنقطة لا بفاصلة، ودون فاصل للآلاف. 4299.00 TRY. ويجب أن يطابق السعر في الخلاصة صفحة الهبوط — وهذا يُفرض بالزحف في معظم المنصات.

القيم المحددة مسبقًا حساسة لحالة الأحرف والصيغة، وتختلف من منصة لأخرى. تتوقع Google القيمة in_stock؛ بينما تتوقع Meta القيمة in stock. هذا الاختلاف وحده أفسد عمليات استيراد كتالوجات أكثر من أي أمر آخر. لا تفترضوا أبدًا أن قيمة محددة مسبقًا تنتقل بين الوجهات.

تسليم الملف. ضغط Gzip للملفات الكبيرة، ورابط HTTPS ثابت، ودون جدار مصادقة ما لم تدعمه المنصة صراحةً، وخادم يستجيب ضمن مهلة المنصة. فرابط الخلاصة خلف حماية Cloudflare من الروبوتات هو رابط خلاصة لا يتم جلبه.

تكرار التحديث ينبغي أن يتبع تقلب البيانات الأساسية لا عرفًا سائدًا: كل ساعة أو أسرع للأودز وأسعار الرحلات ومخزون التجزئة سريع الحركة؛ وكل بضع ساعات للمركبات والعقارات؛ ويوميًا للكتالوجات المستقرة.

14. XML مقابل CSV مقابل JSON مقابل API

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

إذا كانت عناوينكم تحتوي على فواصل — والعناوين التي تتضمن اللون والمقاس تحتوي عليها دائمًا تقريبًا — فاستخدموا TSV بدلًا من CSV. وبذلك تختفي فئة كاملة من أخطاء التحليل.

15. قائمة التحقق قبل الإطلاق

• [ ] يُحلَّل الملف في مدقق XML قبل أن يقترب من أي منصة
• [ ] تم التصريح بـ UTF-8 وتقديمه بشكل صحيح؛ والأحرف غير ASCII تُعرض بشكل سليم
• [ ] كل & في كل رابط مهرَّب، أو الحقل ملفوف بـ CDATA
• [ ] المعرّفات فريدة، وثابتة عبر المزامنات، وتطابق أحداث البكسل أو الوسم لديكم
• [ ] جميع السمات المطلوبة موجودة للوجهة المستهدفة — بعد التحقق منها وفق مواصفات تلك الوجهة، لا مواصفات عامة
• [ ] القيم المحددة مسبقًا محوّلة لكل وجهة، وليست منسوخة
• [ ] الأسعار تطابق صفحات الهبوط تمامًا، بما في ذلك العملة وأي معالجة ضريبية
• [ ] التواريخ بصيغة ISO 8601 مع إزاحات المنطقة الزمنية
• [ ] الصور تستوفي الحد الأدنى 500x500 وتُحلّ عبر HTTPS دون إعادة توجيه
• [ ] العناصر المباعة أو المشغولة أو المنتهية أو التي غادرت تخرج من الخلاصة وفق الجدول الصحيح
• [ ] تكرار التحديث يطابق سرعة تغيّر البيانات الأساسية فعليًا
• [ ] رابط الخلاصة متاح للعموم وغير محجوب بحماية الروبوتات
• [ ] توجد قاعدة مراقبة للتغيرات غير المتوقعة في عدد العناصر

16. الأسئلة الشائعة

هل ما زال XML هو الصيغة المناسبة في 2026؟
لكل ما فيه بيانات متداخلة، نعم. وللكتالوجات المسطحة، فإن TSV أبسط وأقل هشاشة. وللمتطلبات الفورية، يتفوق التكامل عبر API على أي ملف. ينبغي أن تتبع الصيغة البيانات، لا العادة.

هل يمكنني استخدام خلاصة واحدة لكل المنصات؟
مصدر واحد، نعم. أما ملف واحد، فلا. أسماء الحقول والقيم المحددة مسبقًا وحدود الأحرف والسمات المطلوبة تختلف باختلاف الوجهة، والاختلافات ليست شكلية. والبنية العملية هي كتالوج واحد معتمد مع تحويلات خاصة بكل قناة تُطبَّق عند التصدير.

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

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

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

أين تصبح المهمة صعبة

لا توجد قاعدة منفردة في هذه المقالة صعبة. الصعوبة أن عددها بالمئات، وأنها تختلف باختلاف الوجهة، وتتغير دون إنذار، وأن مخالفتها تفشل بصمت.

كتالوج واحد يُصدَّر إلى Google وMeta وTikTok وثلاثة أسواق إلكترونية يعني ستة عقود مختلفة تُستوفى في آن واحد من مصدر حقيقة واحد. وفعل ذلك يدويًا يعني صيانة ستة ملفات ومطابقتها في كل مرة يتغير فيها الكتالوج.

تلك هي الطبقة التي بُني Feedance من أجلها — Feed Rules لتوحيد السمات عند المصدر، وتصديرات القنوات التي تطبق التحويل الصحيح لكل وجهة من أكثر من 200 وجهة دون المساس ببيانات المصدر، وFeed Protection لاكتشاف السمات المفقودة والتغيرات غير المتوقعة في عدد العناصر قبل أن تكتشفها المنصة، وCreative Suite الذي يولّد صورة أو فيديو لكل صف في الخلاصة للكتالوجات التي لم يكن الإنتاج اليدوي لها واقعيًا يومًا.

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

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

آخر مراجعة: أغسطس 2026. مواصفات المنصات تتغير باستمرار؛ تحققوا من المتطلبات الحالية في الوثائق الرسمية لكل وجهة قبل التنفيذ.