استخدام ملفات ads.txt و sellers.json لتحليل الإعلانات (دليل عملي)
ads.txt و sellers.json هما ملفان نصيان مجانيان ومتاحان للعموم يتيحان لك التحقق من الجهات المخولة فعليًا لبيع مخزون الناشر. إليك سير عمل عملي لاستخدامهما في أبحاث الإعلانات.

ads.txt و sellers.json هما ملفان نصيان صغيران ومستضافان للعموم، وعند قراءتهما معًا، يخبرانك من هو المخول لبيع مخزون إعلانات الناشر ومن يملك حقًا معرف بائع معين في السلسلة. بالنسبة لأبحاث المنافسة وسلسلة التوريد، فهما أحد المصادر القليلة حقًا الواقعية والقابلة للتحقق في صناعة لا يمكن فيها التحقق من معظم الادعاءات (الإنفاق، الوصول، "المخزون المميز"). إليك كيفية استخدامهما فعليًا.
ما يحتويه كل ملف، عمليًا#
ads.txt موجود في domain.com/ads.txt على المجال الجذري لأي ناشر، وهو قائمة نصية عادية لكل شركة مخولة لبيع مخزون ذلك الناشر، سطر واحد لكل علاقة. يبدو السطر النموذجي كالتالي:
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
هذا هو نطاق البورصة أو SSP، معرف حساب الناشر لدى تلك البورصة، ما إذا كانت العلاقة DIRECT (يتعامل الناشر معهم مباشرة) أو RESELLER (يوجد وسيط مشارك)، واختياريًا معرف سلطة الشهادة. sellers.json هو الصورة المعكوسة، مستضاف من قبل البورصة أو SSP في exchange.com/sellers.json، يسرد كل حساب بائع تتعامل معه تلك البورصة، واسمه (أحيانًا)، وما إذا كان PUBLISHER، أو INTERMEDIARY، أو BOTH. قارن بين الملفين ويمكنك تأكيد ما إذا كان البائع المزعوم لفتحة إعلانية معينة لديه علاقة مخولة بالفعل، أو ما إذا كان هناك شيء لا يتطابق.
لماذا يهم هذا لأبحاث المنافسة وسلامة العلامة التجارية#
سلسلة توريد الإعلانات بين ميزانية المعلن وصفحة الناشر نادرًا ما تكون قفزة واحدة. غالبًا ما تتدفق الإعلانات عبر علاقة واحدة أو أكثر من المخزون المعاد بيعه قبل الهبوط، وكل قفزة تمثل فرصة للتضليل، أو انتحال النطاق، أو مجرد ارتباك حول من يدير الإعلان حقًا. ads.txt و sellers.json موجودان تحديدًا لجعل هذه السلسلة قابلة للتدقيق:
- التحقق من ادعاء شبكة. إذا ادعت شبكة أصلية أو DSP وصولاً مباشرًا إلى مخزون ناشر، فسيسردها ملف ads.txt لذلك الناشر كـ DIRECT. إذا ظهرت فقط كوسيط إعادة بيع بعد عدة قفزات، أو لم تظهر على الإطلاق، فهذه معلومات مفيدة قبل الشراء.
- اكتشاف انتحال النطاق. العمليات الاحتيالية تدعي أحيانًا تمثيل مخزون ناشر مميز دون أي تفويض. التحقق من ads.txt مقابل نطاق طلب العطاء الفعلي هو طريقة قياسية مجانية لاكتشاف هذا.
- فهم سبب ظهور الإعلان بالشكل الذي يبدو عليه. عندما تتبع كيف تلتقط أدوات تجسس الإعلانات الإعلانات الأصلية، فإن اقتران ads.txt/sellers.json هو غالبًا أسرع طريقة لتأكيد الشبكة التي قدمت مكانًا معينًا بالفعل، بدلاً من التخمين من النمط المرئي للودجت وحده.
- تدقيق مسارات التوريد الخاصة بك. إذا كنت ناشرًا، فإن ملف ads.txt الخاص بك هو أيضًا أسرع طريقة للتحقق مما إذا كان الشريك الذي قطعت العلاقة معه (أو لم تخوله أبدًا) لا يزال مدرجًا، أو ما إذا كانت إحدى عمليات التكامل أضافت أسطرًا لم تتوقعها.
سير عمل عملي من خمس خطوات#
- جلب ملف ads.txt للناشر. احصل على
https://[publisher-domain]/ads.txtمباشرة في المتصفح أو باستخدام برنامج نصي بسيط. إنه نص عادي، لا حاجة لمصادقة. - ابحث عن السطر الخاص بالبورصة أو الشبكة التي تتحقق منها. ابحث عن النطاق (مثل
taboola.com،outbrain.com، أو SSP ذي الصلة) ولاحظ معرف حساب الناشر وما إذا كان محددًا كـ DIRECT أو RESELLER. - جلب ملف sellers.json لتلك البورصة. احصل على
https://[exchange-domain]/sellers.jsonوابحث عن معرف البائع الذي وجدته في الخطوة 2. - قارن اسم البائع ونوعه. هل إدخال sellers.json يطابق الناشر الذي بدأت به؟ هل هو مدرج كـ PUBLISHER (كما هو متوقع لعلاقة مباشرة) أو INTERMEDIARY (متوقع لسلسلة وسيط إعادة بيع)؟
- اتبع السلسلة إذا كانت علاقة RESELLER. سطر RESELLER يعني وجود كيان آخر بين الناشر والبورصة. من الناحية المثالية، يجب أن يحمل هذا الوسيط بيانات كائن SupplyChain (schain) الخاصة به في طلب العطاء، والتي تسجل كل قفزة لإمكانية التدقيق الكامل، على الرغم من أن بيانات schain غير مرئية من ملفات ads.txt/sellers.json وحدها؛ فهي تتطلب الوصول إلى دفق العطاءات الفعلي أو أداة تلتقطه.
النتائج الشائعة، وماذا تعني#
| ما تجده | المعنى المحتمل |
|---|---|
| الشبكة التي تتحقق منها غير موجودة في ملف ads.txt للناشر على الإطلاق | إما أن المخزون غير مخول، أو أنك تبحث في نطاق الناشر الخطأ لهذا المكان المحدد (شائع مع النطاقات الفرعية والهجينة بين التطبيق والويب) |
| مدرج كـ RESELLER فقط، على عدة طبقات عميقة | يتم إعادة بيع المخزون عبر وسطاء؛ يستحق مزيدًا من التدقيق قبل الشراء بكميات كبيرة |
| إدخال sellers.json محدد بـ "CONFIDENTIAL" | البورصة تحجب اسم البائع، وهو مسموح به في المواصفات لكنه يقلل الشفافية |
| معرف الناشر يظهر مع عدة نطاقات بورصة مختلفة كـ DIRECT | طبيعي؛ معظم الناشرين يعملون مباشرة مع عدة بورصات في وقت واحد |
أين يتناسب هذا مع تحديد شبكة الإعلانات على نطاق أوسع#
ads.txt و sellers.json أقوى في التحقق من علاقات جانب العرض، وليس في تحديد الشبكة التي قدمت بالفعل إعلانًا محددًا تنظر إليه كمشتري. لذلك، فأنت تعمل عادةً من سلسلة إعادة التوجيه للإبداع، والتوقيع المرئي للودجت، ونطاقات بكسل التتبع المشاركة، وهي الطريقة المغطاة في كيفية تحديد شبكة الإعلانات خلف أي إعلان. فكر في ads.txt و sellers.json كأثر تدقيق لعلاقات التوريد، وتحليل الإبداع/إعادة التوجيه كأثر تدقيق لما يديره المعلن فعليًا.
ملاحظات حول الأدوات#
كلا تنسيقي الملفين يحكمهما مواصفات IAB Tech Lab، والمواصفات المصدر هي المرجع الحاسم إذا واجهت حالة متطرفة لا تغطيها هذه الملفات بشكل نظيف، مثل إعدادات الحسابات المتعددة أو حقول OWNERDOMAIN. للفحص اليدوي العشوائي، المتصفح والبحث النصي كافيان حقًا؛ لا تحتاج إلى أدوات مدفوعة للتحقق العرضي. حيث يصبح الأمر مملًا هو القيام بذلك على نطاق واسع عبر عشرات الناشرين أو تتبع التغييرات بمرور الوقت، وهنا توفر المنصة التي تفهرس بالفعل سلسلة التوريد عبر الشبكات عمل الجلب والمقارنة المتكرر. فهرس تحليل الإعلانات في OpenAdLibrary يقترن هذا النوع من سياق مسار التوريد مع الإبداع الحي الفعلي وصفحة الهبوط المتتبعة، لذلك لا تقارن بين ثلاثة مصادر منفصلة يدويًا لكل مكان تريد التحقق منه.
لماذا يهم هذا للإعلانات الأصلية أكثر مما يبدو للوهلة الأولى#
شبكات الإعلانات الأصلية تعيد بيع المخزون باستمرار. قد تمر فتحة ودجت توصية محتوى واحدة على صفحة ناشر عبر الشبكة مباشرة، أو عبر وسيط إعادة بيع إقليمي، أو عبر غلاف عطاءات الرأس الذي يتوسط عدة مصادر طلب في وقت واحد. لأن الإعلانات الأصلية نادرًا ما تحمل نوع العلامة التجارية المرئية التي يحملها بانر العرض، ولأن الودجت نفسه غالبًا ما يبدو متطابقًا بغض النظر عن الشبكة التي تقف خلفه حقًا، فإن ads.txt و sellers.json هما أحيانًا الطريقة الوحيدة الموثوقة لتأكيد الشبكة التي تحمل علاقة ناشر معينة بشكل شرعي، خاصة عندما يعمل موقع ناشر على تشغيل عدة ودجات أصلية جنبًا إلى جنب من مزودين مختلفين. هذا أيضًا هو السبب في أن إعدادات عطاءات الرأس، حيث تتنافس عدة بورصات على نفس الفتحة في الوقت الفعلي، تستفيد من نفس التحقق: يجب أن يكون لكل بورصة مشاركة سطرها المخول الخاص في ملف ads.txt للناشر، وإدخال sellers.json المطابق الخاص بها.
القيام بذلك على نطاق واسع مقابل القيام به مرة واحدة#
التحقق من ملف ناشر واحد يدويًا يستغرق بضع دقائق. التحقق منه عبر قائمة مراقبة من خمسين ناشر، على أساس متكرر، لالتقاط علاقات جديدة أو منقطعة، هو مشكلة مختلفة، وهو النوع من الأشياء الذي يتوقف عن الحدوث بهدوء بمجرد أن يختفي الفضول الأولي، على الرغم من أن القيمة تأتي من القيام به بشكل متكرر. إذا كنت تبني هذا في عملية بحث دائمة بدلاً من فحص لمرة واحدة، فمن الجدير إقرانه بأي مراقبة لسلسلة توريد الإعلانات تقوم بها بالفعل للتغييرات في الإبداع وصفحة الهبوط، بحيث يتم تحديث صورة جانب العرض وجانب الإبداع معًا بدلاً من الانحراف عن المزامنة.
ملاحظة حول الحدود#
هذه الملفات يتم الإعلان عنها ذاتيًا من قبل الناشرين والبورصات. لا شيء يجبر ناشرًا على الحفاظ على تحديث ads.txt، والملف القديم أو غير المكتمل شائع، خاصة على المواقع الصغيرة. تعامل مع الإدخال المفقود أو غير المتسق كمحفز للتحقيق أكثر، وليس كدليل تلقائي على الاحتيال؛ الكثير من الناشرين الصغار الشرعيين ببساطة لم يقوموا بتحديث ملفهم مؤخرًا. قيمة ads.txt و sellers.json هي أنها تجعل سلسلة التوريد قابلة للفحص من الأساس، وليس أنها تجعلها معصومة من الخطأ.







