الانتقال إلى المحتوى

الرئيسية/المدونة

ads.txt وsellers.json: ما هما وما فائدتهما

2026-09-087 دقائق للقراءة

بين حين وآخر يطلب منك شريك طلب أن تضيف سطرًا إلى ملف ads.txt، ولا يشرح أحد ما هذا الملف ولا لماذا وُجد. إليك المشكلة التي جاء ليحلها، وكيف يُقرأ محتواه، وبماذا يختلف عن sellers.json، وما الذي يتعطل حين يكون خاطئًا.

الاحتيال الذي جاء ads.txt ليوقفه

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

كان الضرر مزدوجًا: فالمعلِن يدفع سعر وسيلة إعلامية جيدة مقابل مرات ظهور عُرضت في أي مكان آخر، والوسيلة المنتحَلة لا ترى قرشًا واحدًا. وحين اتضح أن المخزون المعروض للبيع يفوق مشاهدات الصفحات الحقيقية، صار لا بد من آلية يعلن بها كل ناشر علنًا من يحق له البيع باسمه. وهذه الآلية هي ads.txt.

لا يمنع ads.txt أحدًا من الكذب بشأن مخزونك. لكنه يجعل تلك الكذبة قابلة للتحقق في ثانية واحدة.

ما هو ads.txt بالضبط

الاسم اختصار لـ Authorized Digital Sellers: البائعون الرقميون المخوَّلون. وهو ملف نصي بسيط يوضع في جذر نطاقك ويُقدَّم في هذا العنوان بالضبط: example-news.com/ads.txt. لا يوضع في مجلد فرعي ولا في لوحة إدارة، ولا يعتمد على نظام إدارة المحتوى. إنه ملف يُنزَّل ويُقرأ.

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

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

كيف يُقرأ سطر في ads.txt

يبدو السطر النموذجي هكذا: ssp-example.com, 12345, DIRECT, f1a2b3c4d5e6f7a8. وهي أربعة حقول تفصل بينها فواصل، ويجيب كل منها عن سؤال مختلف.

  • نطاق النظام الإعلاني. ليس الاسم التجاري لـ SSP، بل النطاق الذي يُنفَّذ فيه الشراء؛ وتحدده المنصة دائمًا، لأنه لا يطابق موقعها المؤسسي في كل الأحوال.
  • معرّف الناشر. معرّف حسابك في تلك المنصة: وهو ما يفصل مخزونك عن مخزون أي وسيلة أخرى تستخدم SSP نفسه.
  • العلاقة: DIRECT أو RESELLER. وهي إلزامية، وتبيّن ما إذا كانت تلك المنصة تعمل بحساب باسمك أو تعيد بيع مخزونك عبر حسابها.
  • معرّف الاعتماد، وهو اختياري. يحدد تلك الشركة في سجل TAG (Trustworthy Accountability Group) ويؤكد أن النطاق المعلَن يعود فعلًا لمن يدّعي ذلك.

ترتيب الأسطر لا يعني شيئًا: إنها قائمة لا سلسلة متدرجة. والأسطر التي تبدأ بعلامة # تعليقات تُتجاهل. وهناك أيضًا أسطر متغيرات، مثل CONTACT= لترك بريد إلكتروني مرجعي، أو OWNERDOMAIN= لإعلان المالك الحقيقي للموقع.

DIRECT وRESELLER: ما الذي يميز كلًّا منهما

تعني DIRECT أن لديك علاقة تعاقدية مباشرة مع تلك المنصة، وأن الحساب المذكور في الحقل الثاني حسابك. وتعني RESELLER أنك خوّلت تلك المنصة بإعادة بيع مخزونك رغم أن الحساب ليس باسمك. وهذا هو المعتاد حين تعمل مع شريك تحقيق دخل يربطك بالطلب عبر حساباته الخاصة في عدة منصات SSP.

يهم هذا التمييز المشتري، لأن السلسلة التي تضم عدة معيدي بيع متتالين تمر بأيدٍ أكثر وتقتطع عمولات أكثر قبل أن تصل إليك. ولا جدوى من تجميلها: فوسم ما هو RESELLER على أنه DIRECT لا يحسّن شيئًا، لأن ذلك المعرّف يُطابَق مع ملف sellers.json لدى المنصة فيظهر التناقض من تلقاء نفسه.

sellers.json: النصف الآخر من السلسلة

ينظر ads.txt إلى الخارج من جهة الوسيلة الإعلامية: يقول من أخوّله بالبيع. أما sellers.json فينظر في الاتجاه المعاكس، من جهة المنصة: يقول من أمثّل أنا. وتنشره كل منصة SSP أو exchange في جذر نطاقها، في ssp-example.com/sellers.json، وتتولى المنصة صيانته. أنت لا تعدّله، لكن يمكنك قراءته، ومن المفيد أن تفعل.

صيغته JSON لا نص بسيط. وكل مدخل يربط معرّف بائع بهويته الحقيقية: الاسم والنطاق والنوع. ويمكن أن يكون النوع PUBLISHER إن كان الحساب لمالك المخزون، أو INTERMEDIARY إن كان يعيد بيع مخزون الآخرين، أو BOTH. وهناك أيضًا مدخلات موسومة بأنها سرية، بلا اسم ولا نطاق ظاهرين: وهذا مسموح، وهو النقطة التي تتوقف عندها إمكانية تدقيق السلسلة.

يُقرأ الملفان معًا، وهنا تكمن الفائدة. فملف ads.txt لديك يقول إن ssp-example.com يمكنه البيع لك بالمعرّف 12345؛ وملف sellers.json لدى ssp-example.com يجب أن يقول إن ذلك المعرّف يخص نطاقك. فإن تطابقا، أعاد المشتري بناء السلسلة كاملة من المعلِن حتى يصل إليك. وإن لم يتطابقا، فقد العرض قيمته أو استُبعد.

ماذا يحدث حين يغيب أو يكون خاطئًا

  • لا يوجد ملف. يتوقف المشترون الذين لا يقبلون إلا المخزون المخوَّل عن المزايدة عليك: لا يختفي المخزون، لكنه يبقى ينافس على الميزانيات الأرخص.
  • سطر شريك جديد مفقود. يُستبعد الطلب الذي يربطه لعدم وجود سند في ملفك، ويظهر ذلك كمعدل تعبئة (fill rate) منخفض بلا سبب واضح.
  • خطأ في الصياغة. فاصلة زائدة تُبطل ذلك السطر بأكمله؛ ويستمر قراءة بقية الملف. وهو أكثر الأخطاء صمتًا على الإطلاق.
  • الملف لا يصل. يعيد خطأ 404، أو يحوّل إلى نطاق آخر، أو يحجبه جدار حماية أمام الزاحف. وبالنسبة إلى المشتري، هذا يساوي عدم وجوده.
  • أسطر قديمة زائدة. شريك توقفت عن العمل معه منذ عام يظل مخوَّلًا بالبيع باسمك ما دام سطره موجودًا.

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

app-ads.txt: الأمر نفسه للتطبيقات

لا يملك تطبيق الهاتف أو التلفزيون المتصل جذر نطاق يوضع فيه ملف، لذلك تسلك الآلية طريقًا ملتفًّا: يدخل الزاحف إلى صفحة التطبيق في المتجر، ويقرأ الموقع الذي أعلنه المطوّر، ويبحث عن الملف في جذر ذلك النطاق: example-apps.com/app-ads.txt. وصيغة الأسطر مطابقة تمامًا.

لهذا فإن الخطأ الأكثر شيوعًا لا يكون في محتوى الملف بل في الطريق إليه: صفحة المتجر تشير إلى نطاق لا يقدّم الملف، أو لا تعلن أي نطاق. وإن كان لديك موقع وتطبيق، فهما ملفان منفصلان بقائمتين مستقلتين؛ فلا ads.txt يغطي التطبيق، ولا app-ads.txt يغطي الموقع.

لماذا يجب تحديثهما باستمرار

هذا ليس شيئًا يُكتب مرة ويُنسى. فكل شريك جديد سطر جديد، وكل شريك يغادر سطر زائد. وهناك أيضًا فارق زمني: المشترون لا يعيدون قراءة ملفك كل يوم، لذا قد تمر عدة أيام بين نشر سطر وسريان مفعوله. يُضاف السطر قبل أن يبدأ الشريك البيع، لا بعده.

حين يمر تحقيق الدخل عبر شريك، فهو من يخبرك بالأسطر التي يجب إضافتها. وفي ADEQ Media نعطي الوسائل التي نعمل معها الأسطر التي توضع في ملف ads.txt الخاص بها ونتحقق من صحتها؛ وتتولى كل وسيلة رفعها إلى نطاقها، أما ملف sellers.json الخاص بنا فنتولى نحن صيانته. وهكذا لا يتوقف ربط الطلب المميز عبر Header Bidding مع SmartTag، أو تفعيل الحملات المباشرة، على تخمين ما يجب كتابته في ملف. وكل ما عليك هو Header Script وملف ads.txt الخاص بك، مع تنفيذ خلال 48 ساعة.

ومع ذلك، هناك فحص يستغرق نصف دقيقة يحسن إجراؤه من وقت لآخر: افتح yourdomain.com/ads.txt في المتصفح وانظر إلى ما يظهر. فإن لم تشبه تلك القائمة قائمة من يبيعون مخزونك اليوم، فهنا يكمن العمل المتبقي.

كيف يتم ذلك مع ADEQ Media

عمليًّا، لا يتعين عليك معرفة الأسطر التي تخصك. نعطيك الأسطر التي توضع في ads.txt وأنت ترفعها: وهي إحدى الخطوات الثلاث للتكامل، إلى جانب Header Script والإعدادات التي نتولاها نحن.

يتحقق الـ account manager من أنها وُضعت بشكل صحيح قبل أن تبدأ في الاحتساب، وهذا بالضبط حيث تفشل هذه الأمور عادةً: فالسطر المنسوخ خطأً لا يعطي رسالة خطأ، بل يجعل المشترين يستبعدون مرات ظهورك ببساطة دون أن تعلم.

أما ملف sellers.json الخاص بنا فننشره ونتولى صيانته بأنفسنا. وبقية العملية موجودة في الأسئلة الشائعة.

كم يمكن أن يحقق مخزونك الإعلاني؟

نحلل موقعك ونخبرك بما يمكن تحسينه. دون أي التزام.

سجّل الآن
تقييم مجاني رد خلال أقل من 24 ساعة دون التزام