إضافة cost_of_goods_sold إلى خلاصة المنتجات لتقارير الربح

تعرض معظم تقارير Performance Max الإيرادات وROAS، وقليل منها يعرض الربح الإجمالي، لأن Google لا تستطيع احتسابه إلا عندما يحمل كل منتج في خلاصة المنتجات تكلفةً محددة. وتشير Google إلى أن هذه التكلفة يمكن أن تكون تقريبية: فدليل الإعداد الخاص بها يقترح تقدير COGS بنسبة 80% من سعر المنتج عند غياب الأرقام الدقيقة. هذا الدليل موجّه لمديري الخلاصات وقادة الإعلانات المدفوعة الذين لديهم عمود تكلفة في مكان ما (تصدير من نظام ERP أو قائمة أسعار الموردين) ويرغبون في إدراجه داخل خلاصة Merchant Center. في نهاية الدليل ستحصلون على سمة cost_of_goods_sold مهيأة بالشكل الصحيح، ووسم تحويل متوافق معها، وأول تقرير للهامش يمكنكم تحويله إلى شرائح في custom labels.

ما الذي تفعله cost_of_goods_sold وما الذي لا تفعله

cost_of_goods_sold هي سمة في Merchant Center تدعم تقارير الربح الإجمالي. وتصف Google الربح الإجمالي بأنه الإيرادات مطروحًا منها COGS. لا تغيّر هذه السمة المنتجات التي تتم الموافقة عليها، ولا ترتيبها، ولا قيمة مزايداتكم. فهي تمنح Google Ads فقط تكلفةً تطرحها من الإيراد الذي تسجله أصلًا لكل عنصر مباع.

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

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

الخطوة 1: حدّدوا مصدر تكلفة كل منتج

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

مصدر التكلفة	الدقة	عبء الصيانة	متى تستخدمونه
تصدير من نظام ERP أو المخزون، لكل SKU	عالية	منخفض بعد الأتمتة	عندما تكون التكاليف مخزنة أصلًا لكل متغيّر
قائمة أسعار الموردين مربوطة بحسب SKU	متوسطة إلى عالية	متوسط؛ تتغير القوائم بتغير الموسم	لا يوجد ERP، لكن لديكم ملف موردين نظيف
متوسط الفئة (مثلًا 0.62 × السعر لفئة معينة)	متوسطة	منخفض	عندما تكون الهوامش متقاربة داخل الفئة
نسبة ثابتة من السعر (مثال Google: 80%)	منخفضة	لا يوجد	تحتاجون إلى أول تقرير هذا الأسبوع وستُحسّنون الأرقام لاحقًا

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

الخطوة 2: نسّقوا السمة بدقة

تتطلب مواصفات Google للسمة cost_of_goods_sold رقمًا يتبعه رمز عملة بمعيار ISO 4217، دون تكرار، مع استخدام النقطة فاصلًا عشريًا. وقد يؤدي مخالفة أي من القاعدتين إلى استبعاد المنتجات من التقارير، مما ينتج بيانات ناقصة.

في خلاصة مفصولة بعلامات جدولة (tab) تبدو القيمة هكذا:

412.50 TRY

وفي XML:

<g:cost_of_goods_sold>412.50 TRY</g:cost_of_goods_sold>

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

هذه أكثر أخطاء التنسيق شيوعًا في أعمدة التكلفة التي نصادفها، وما الذي يسببه كل منها:

القيمة في المصدر	المشكلة	القيمة بعد التصحيح
`412,50 TRY`	فاصل عشري بالفاصلة، شائع في عمليات التصدير بالإعدادات المحلية التركية	`412.50 TRY`
`412.50`	لا يوجد رمز عملة	`412.50 TRY`
`TL 412.50`	ليس رمزًا بمعيار ISO 4217، والترتيب خاطئ	`412.50 TRY`
`1,412.50 TRY`	فاصل آلاف داخل الرقم	`1412.50 TRY`
`0.00 TRY`	تكلفة فارغة جرى تصديرها على أنها صفر، وهو ما يُقرأ كهامش 100%	احذفوا السمة لهذا المنتج

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

الخطوة 3: أوصلوا القيمة إلى Merchant Center

تذكر Google ثلاث طرق لتقديم بيانات COGS: خلاصة المنتجات، أو Content API (وخليفته Merchant API)، أو خلاصة تكميلية. وعادةً ما يكون مسار الخلاصة التكميلية هو الأكثر أمانًا عندما تأتي بيانات التكلفة من نظام مختلف عن كتالوج المنتجات، لأنه يمكنكم إرسال ملف من عمودين (id وcost_of_goods_sold) دون المساس بالخلاصة الأساسية.

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

الخطوة 4: تحققوا من أن بيانات السلة تتطابق مع معرّفات خلاصتكم

لا تُستخدم التكلفة إلا عندما تستطيع Google مطابقة عنصر مباع مع عنصر في الخلاصة. وتوضح مساعدة Google أن معرّفات العناصر في مصفوفة items داخل وسم التحويل يجب أن تتطابق تمامًا مع السمة id في خلاصة Merchant Center، وأنه لا تُعالَج إلا العناصر القادمة من حساب Merchant Center مرتبط بحساب Google Ads. ويجب أن تكون التحويلات المؤهلة تحويلات شراء قابلة للمزايدة وتستخدم وسم Google أو Google Tag Manager.

نفّذوا قائمة التحقق هذه قبل انتظار البيانات:

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

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

الخطوة 5: اقرأوا أول تقرير وقارنوه بأرقام القسم المالي

تعرض Google Ads النتائج في صورة الربح الإجمالي، وهامش الربح الإجمالي، وتكلفة البضاعة المباعة، والإيرادات، والوحدات المباعة. وبالنسبة لـ Performance Max، توثّق Google Ads API هذه المقاييس باسم metrics.gross_profit_micros وmetrics.gross_profit_margin وmetrics.cost_of_goods_sold_micros، وهي متاحة في asset_group_product_group_view وcampaign وcustomer وshopping_performance_view.

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

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

الخطوة 6: حوّلوا الربح الإجمالي إلى شرائح هامش

بمجرد أن يصبح هامش الربح الإجمالي ظاهرًا لكل منتج، قسّموا المنتجات إلى بضع شرائح واكتبوا الشريحة في custom label. تتيح Google استخدام custom_label_0 إلى custom_label_4، بحد أقصى 100 حرف لكل منها، وقيمة واحدة لكل منتج في كل سمة، وحتى 1,000 قيمة فريدة لكل label. وتكفي ثلاث إلى خمس شرائح.

مخطط توضيحي (الأرقام أمثلة وليست معايير مرجعية):

الهامش الإجمالي على سعر الخلاصة	قيمة `custom_label_1`	الاستخدام المعتاد
أقل من 20%	`margin_low`	مجموعة إدراج منفصلة؛ يُحكم عليها بالربح لكل نقرة لا بـ ROAS
من 20% إلى 40%	`margin_mid`	المجموعة الافتراضية
أكثر من 40%	`margin_high`	مرشحة لميزانية أكبر
لا يوجد COGS	`margin_unknown`	قائمة للمراجعة؛ أصلحوا البيانات

الشريحة هي حساب يتم من جهة الخلاصة انطلاقًا من price وcost_of_goods_sold، لذا يمكن لقاعدة خلاصة أن تكتبها تلقائيًا في كل مرة تُعاد فيها بناء الخلاصة. يتناول مقالنا السابق حول custom labels ونوع المنتج ومعرّف العنصر في مجموعات الإدراج في Performance Max عدد أبعاد الـ label التي تتحملها شجرة مجموعات الإدراج قبل أن تتفتت. وإذا أردتم التحقق مما إذا كان التغيير مفيدًا، فإن منهجيتنا لقياس أثر تغيير الخلاصة على ROAS تنطبق كما هي.

الخطوة 7: أبقوا عمود التكلفة حيًّا

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

أين تظهر حدود هذا الأسلوب

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

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

المتوسطات تخفي التباين. فإذا كانت فئة واحدة تجمع إكسسوارًا بهامش 15% ومنتجًا أساسيًا بهامش 55%، فسيُسيء متوسط الفئة تمثيل كليهما.

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

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

هل cost_of_goods_sold مطلوبة في Google Shopping؟

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

هل يجب أن تكون التكلفة دقيقة؟

لا. تقول Google إن البيانات مخصصة للتقارير ولا يلزم أن تكون دقيقة. وإذا كانت التكلفة تختلف بين المنتجات، فقدموا متوسطًا، أو تقديرًا تقريبيًا مثل 80% من السعر.

هل يستطيع العملاء رؤية التكلفة؟

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

لماذا تعرض تقاريري شرطة بدلًا من الربح الإجمالي؟

عادةً يكون السبب إما غياب السمة أو عدم تطابق المعرّفات في وسم التحويل مع id في الخلاصة. تحقّقوا أولًا من تشخيصات إجراء التحويل بحثًا عن معرّفات غير متطابقة.

ما العملة التي ينبغي استخدامها؟

عملة السعر الذي يُبلغ عنه وسم التحويل. وتوصي Google بالمطابقة بينهما لتجنب تباينات أسعار الصرف.

هل تعمل مع Performance Max؟

نعم. توثّق Google Ads API مقاييس بيانات السلة، بما فيها الربح الإجمالي وهامش الربح الإجمالي، لحملات Performance Max التي نُفّذت فيها التحويلات مع بيانات السلة.

أين أضيفها إذا لم أرغب في تعديل الخلاصة الأساسية؟

استخدموا خلاصة تكميلية أو Content API أو Merchant API. وتذكر Google هذه الطرق إلى جانب الخلاصة الأساسية كوسائل تسليم مقبولة.

ما الفرق بينها وبين custom labels؟

تغذي سمة التكلفة تقارير الربح في Google. أما custom label فهو شريحة تحددونها لهيكلة الحملات. تستخدمون الأولى لحساب الهامش والثانية للتصرف بناءً عليه.

افحصوا خلاصتكم قبل إضافة عمود التكلفة

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

المصادر

هل تريد رأيًا آخر في خلاصتك؟ سنراجعها معك ونوضح أين توجد الثغرات قبل الإرسال التالي.

احصل على تدقيق مجاني

بقلم

Cagdas Polat

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

إضافة cost_of_goods_sold إلى خلاصة Google: دليل عملي من تصدير COGS إلى شرائح الهامش