ikas مقابل Ticimax مقابل T-Soft مقابل İdeaSoft: أي خلاصة منتجات أصلية جاهزة فعلًا لـ Google وMeta

ستبدأ Google Merchant Center بتطبيق حد أدنى لأبعاد الصور قدره 500x500 بكسل اعتبارًا من 31 يناير 2027، وهي ترفض بالفعل المنتجات فور غياب قيمة item_group_id أو gtin لأي متغير أو وجودها بصيغة خاطئة. لا جديد في ذلك. أما الخطأ الشائع فهو افتراض أن منصة التجارة الإلكترونية التركية التي تستخدمونها تتولى هذه المهمة عنكم. قارنّا كيف تُنشئ ikas وTicimax وT-Soft وİdeaSoft خلاصات المنتجات محليًا، اعتمادًا على الوثائق الرسمية لكل مزوّد، ووجدنا فجوات حقيقية بين عبارة «يوجد رابط XML» وعبارة «ستقبل Google وMeta ما بداخله». هذا المقال موجّه للتجار والوكالات العاملين على إحدى هذه المنصات الأربع ممن يريدون تقرير ما إذا كان التصدير الأصلي كافيًا، أم أنهم بحاجة إلى طبقة خلاصة منتجات فوقه.

ماذا تعني عبارة «جاهزة للخلاصة مباشرة» فعلًا

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

كيف يعمل التصدير الأصلي في كل منصة فعليًا

ikas

توفّر ikas تكاملًا مباشرًا مع Google Merchant Center: تنسخون رابط الكتالوج من لوحة ikas إلى إعدادات مصدر البيانات في Merchant Center، ووفق وثائق الدعم الرسمية لدى ikas فإن «التغييرات التي تجرونها على المنتجات في لوحة ikas ستنعكس تلقائيًا» في الخلاصة. تُرسل الباركودات بوصفها GTIN افتراضيًا، وتتيح ikas خيارًا لإرسالها بوصفها MPN بدلًا من ذلك إذا كانت صيغ الباركود لديكم لا تستوفي معيار GTIN لدى Google، وهو إقرار صريح ومفيد بأن باركود كل تاجر ليس بالضرورة GTIN حقيقيًا. أما ما لا تصفه الوثائق فهو تكامل أصلي مع كتالوج Meta، ولا كيفية إسناد item_group_id عبر متغيرات المقاس واللون، لذا فأنتم تعتمدون على أن يُترجم نموذج المتغيرات في ikas بشكل سليم، دون إمكانية التحقق من ذلك.

Ticimax

تُمرّر وثائق الدعم الرسمية لدى Ticimax بيانات Google Shopping عبر حقول تسميها «Adwords alanları» في تبويب التسويق لكل منتج، وتُملأ يدويًا لكل منتج أو بالجملة عبر دورة تصدير/استيراد Excel. وهذا نموذج مختلف جوهريًا عن ikas: فربط السمات ليس تلقائيًا، بل هو إدخال بيانات تقع مسؤوليته عليكم. كما أن بيانات الشحن في مخرجات XML اختيارية لكل خلاصة، وتُفعَّل من خلال إعداد شحن مخصص بدلًا من وراثتها من إعدادات متجركم المباشر، وهذا مصدر شائع لرفض المنتجات بسبب عدم تطابق الأسعار حين يختلف الإعداد عن المتجر.

T-Soft

تُنشئ T-Soft الخلاصات من روابط ثابتة يمكن توقعها، مثل siteadresiniz.com/xml/googleshopping.com.php لـ Google ونقطة نهاية منفصلة facebookmagaza.com.php لـ Meta، وفق وثائق تكامل T-Soft الصادرة عن مستشار معتمد في التجارة الإلكترونية (أعاد مركز المساعدة الرسمي لدى T-Soft الخطأ 404 للمقال المحدد وقت كتابة هذا النص، لذا تحققوا من المسار الحالي في لوحتكم قبل الاعتماد عليه). يتم التحكم في إدراج المنتجات عبر آلية «مجموعة الأعضاء» للموزعين: تُسندون ظهور فئات أو علامات تجارية إلى مجموعة تحمل اسم القناة، ولا تظهر في XML الخاص بتلك القناة إلا المنتجات المرئية. وهذا نموذج عملي للتحكم في الوصول، لكنه ليس بديلًا عن ربط السمات، ولا تصف وثائق نقطة النهاية ولا ما كتبه المستشار تعبئة تلقائية لـ GTIN أو MPN أو item_group_id.

İdeaSoft

يُعد التصدير في İdeaSoft، الذي يمكن الوصول إليه عبر Entegrasyonlar ← Idea Output Çıktı Sistemi في لوحة الإدارة، الأكثر وعيًا بالسمات بين المنصات الأربع من الناحية النظرية. ووفق وثائق المساعدة الرسمية لدى İdeaSoft، يتضمن مخرج XML العلامة التجارية وGTIN/الباركود وMPN «عند توفرها»، إلى جانب حقول الاسم والوصف والسعر والمخزون والصورة المعتادة. كما يحمل أوضح تحذير بين جميع المنصات التي فحصناها: إذا لم تكن الباركودات لديكم GTIN صالحة دوليًا، فعليكم تعطيل حقل GTIN يدويًا، لأن إرسال قيمة غير صالحة يؤدي إلى رفض المنتج بدلًا من الرجوع إلى بديل مناسب. أما سلامة المتغيرات من حيث اللون والمقاس وتجميع المنتجات فتُعد مسؤولية التاجر وليست مؤتمتة.

المقارنة

كيف تبدو الفجوة الحقيقية في صف داخل الخلاصة

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

الصف 1: id=SKU-TSHIRT-S, title=Cotton T-Shirt, item_group_id=(فارغ)
الصف 2: id=SKU-TSHIRT-M, title=Cotton T-Shirt, item_group_id=(فارغ)
الصف 3: id=SKU-TSHIRT-L, title=Cotton T-Shirt, item_group_id=TSHIRT-GROUP-04

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

أين تفقد هذه المقارنة قوتها

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

إذا كان كتالوجكم يعمل على منصة عالمية لا على إحدى هذه المنصات الأربع، فلا تنطبق المقارنة مباشرة: فكل من DataFeedWatch وChannable يوفّر مكتبة موصّلات جاهزة أوسع عبر عشرات المنصات غير التركية، وإذا كان نشاطكم يعمل على إحداها بدلًا من ikas أو Ticimax أو T-Soft أو İdeaSoft، فإن اتساع الموصّلات سبب حقيقي للنظر فيهما أولًا. أما لمتجر صغير واحد بكتالوج بسيط بلا متغيرات، فقد يكفي التصدير الأصلي للمنصة مع ضبط جودة يدوي دقيق، وشراء أداة خلاصة منتجات لعشرة SKU ليس استخدامًا جيدًا للميزانية.

قائمة تحقق موجزة قبل الإرسال

• كل صف متغير يشترك في item_group_id متطابق وغير فارغ مع كل تركيبات المقاس/اللون الأخرى للمنتج نفسه
• قيم GTIN هي باركودات حقيقية قابلة للمسح، وليست SKU داخلية أُعيدت تسميتها GTIN — وإذا شككتم فانتقلوا إلى نمط MPN مع العلامة التجارية
• صور المنتجات تستوفي الحد الأدنى 500x500 بكسل الآن، لا بعد موعد تطبيق Google في يناير 2027
• السعر والتوفر في الخلاصة يطابقان ما يعرضه المتجر في اللحظة نفسها، لا ما كان يعرضه حين ضُبط التصدير آخر مرة
• يوجد ملف ثانٍ بالشكل الصحيح لـ Meta إذا كان التصدير الأصلي في منصتكم مبنيًا لـ Google أولًا

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

هل تدعم ikas تصدير كتالوج Meta بشكل أصلي، كما تفعل مع Google Merchant Center؟

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

لماذا تطلب Ticimax ملء حقول Adwords يدويًا بدلًا من ربطها تلقائيًا؟

يتعامل نموذج بيانات المنتجات في Ticimax مع سمات Google Shopping بوصفها حقولًا تسويقية قابلة للتحرير في سجل كل منتج، بدلًا من قيم تُشتق تلقائيًا من بنية الكتالوج، ولهذا فإن التعديل بالجملة عبر Excel هو الحل البديل الموثّق لتحديث عدد كبير من المنتجات دفعة واحدة.

ماذا يحدث إذا تضمّن مخرج XML في T-Soft منتجًا بلا GTIN صالح؟

لا تحدد وثائق T-Soft المتاحة ولا ما كتبه المستشار الذي استشهدنا به معالجة تلقائية لـ GTIN، لذا سيظهر المعرّف غير الصالح أو المفقود في صورة رفض عادي من Google Merchant Center بدلًا من أن يُكتشف قبل الإرسال.

لماذا تحذّرني İdeaSoft من تعطيل حقل GTIN يدويًا؟

لأن İdeaSoft قد تُدرج بيانات الباركود بوصفها GTIN تلقائيًا، وإذا لم يكن هذا الباركود صالحًا دوليًا فإن Google ترفض المنتج بدلًا من قبوله مع تحذير، ولذلك تُحمّل وثائق İdeaSoft التاجرَ مسؤولية اكتشاف الباركودات غير الصالحة قبل وصولها إلى الخلاصة.

هل item_group_id هو نفسه SKU؟

لا. يجب أن يكون SKU (المربوط بـ id) فريدًا لكل صف متغير للمنتج. أما item_group_id فهو قيمة مشتركة منفصلة تجمع صفوف المتغيرات معًا بوصفها منتجًا واحدًا بخيارات متعددة، ووفق وثائق Google ينبغي أن تظهر كل تركيبة سمات مرة واحدة فقط داخل المجموعة.

هل يمكنني إرسال خلاصة XML نفسها إلى Google وMeta معًا؟

ليس بشكل موثوق. تقبل Google صيغة TSV أو XML أو Content API؛ وتقبل Meta صيغة CSV أو TSV أو RSS XML أو ATOM XML أو Google Sheets، وتختلف الحقول المطلوبة قليلًا بين الاثنتين (تشترط Meta مثلًا condition وbrand في كل صف، بينما متطلب العلامة التجارية لدى Google مشروط). والخلاصة المبنية لتلبية مخطط قناة واحدة كثيرًا ما تفشل في التحقق لدى القناة الأخرى حتى لو كانت بيانات المنتج الأساسية صحيحة.

هل يعالج تغيير المنصة هذه الفجوات في الخلاصة؟

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

كم مرة ينبغي أن أعيد فحص التصدير الأصلي مقابل متطلبات Google وMeta الحالية؟

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

تتصل Feedance بخلاصات أي من هذه المنصات الأربع، وتُثري السمات التي تتطلبها كل قناة فعليًا، وتنشر إلى أكثر من 200 قناة إعلانية وسوق إلكترونية — منها Akakçe وCimri وN11 وÇiçekSepeti إلى جانب Google وMeta — دون أن تضطروا إلى صيانة ملفي تصدير منفصلين على شكل Google وعلى شكل Meta يدويًا. وإذا أردتم معرفة السمات الناقصة في خلاصتكم الحالية قبل أن تكتشفها Google أو Meta، فمرّروها عبر أداة تدقيق خلاصة المنتجات المجانية.