Як виправити ads.txt та схвалення розміщення в Adgora

Як виправити проблеми з ads.txt та схваленням розміщення в Adgora

Дві проблеми часто плутають між собою: помилки ads.txt і проблеми зі схваленням розміщення. Це не одне й те саме. Одна блокує дозволений показ реклами на рівні файлу, а інша не дає запустити конкретне розміщення. Якщо ви намагаєтеся зрозуміти, як виправити ads.txt в Adgora, спершу розділіть ці дві перевірки, перш ніж щось змінювати.

Помилка ads.txt Adgora зазвичай означає, що запис продавця не вдається знайти, прочитати або зіставити з правильним доменом. Проблема зі схваленням розміщення — інша: сайт може бути в порядку, але саме розміщення все ще можуть відхилити, залишити на перевірці або обмежити через політику, трафік чи якість сторінки. У видавця може бути чинний файл ads.txt, але він усе одно чекатиме на схвалення. Таке трапляється.

Уявіть це як двоє воріт. Перші ворота — технічні. Другі — редакційні та політичні. Якщо не проходять перші, Adgora може неправильно розпізнати інвентар. Якщо не проходять другі, розміщення може зависнути на перевірці, навіть якщо файл виглядає ідеально. Саме тому схвалення розміщення Adgora варто розглядати окремо від технічної валідації файлу.

1. Зрозумійте дві проблеми

ads.txt — це текстовий файл, розміщений у корені вашого домену. Він повідомляє покупцям, хто має право продавати ваш інвентар. Схвалення розміщення — це перевірка конкретного рекламного блоку, віджета або рекламної одиниці на вашому сайті чи в застосунку. Одне стосується права власності й авторизації. Друге — конкретного місця, де з’являтиметься реклама.

Якщо рядок у ads.txt відсутній, записаний неправильно або розміщений не на тому домені, рекламна система може вважати інвентар неавторизованим або неповним. Якщо ваше розміщення не схвалено, система може й надалі знати ваш домен, але не показуватиме рекламу в цьому блоці, доки перевірка не завершиться успішно. Різне виправлення. Різний результат.

Ось практичний приклад. Видавець додає рекламний блок на головну сторінку, але сторінка розміщена на example.com, тоді як файл ads.txt опублікований на www.example.com. Така невелика невідповідність може зламати перевірку. Розміщення також може не пройти, якщо сторінка має мало контенту, зламану навігацію або підозріле джерело трафіку.

Перевірте обидві сторони. Один файл. Одне розміщення.

2. Перевірте налаштування файлу ads.txt

Знайдіть файл ads.txt у корені основного домену, зазвичай https://yourdomain.com/ads.txt. Не розміщуйте його в папці й не ховайте за заблокованим шляхом. Якщо сайт використовує і «голий» домен, і версію з www, переконайтеся, що ви знаєте, яку саме версію очікує Adgora.

Редагуйте файл у простому текстовому редакторі. Збережіть його як ads.txt, а не ads.txt.html і не як документ Word із назвою, схожою на текстовий файл. Потім опублікуйте його на живому домені. Допомагає простий тест у браузері: відкрийте файл у новій вкладці й переконайтеся, що він завантажується як звичайний текст.

Рядок продавця Adgora потрібно додати точно так, як це вказано в інструкції Adgora. Не вгадуйте назву акаунта або ID. Використовуйте значення з панелі видавця Adgora або з повідомлення підтримки. Одна неправильна літера може зупинити перевірку.

Якщо сайт працює через CMS або CDN, переконайтеся, що файл не кешується некоректно. Застаріла копія може й далі показувати старий рядок навіть після оновлення. Це дратує, і трапляється частіше, ніж багато команд готові визнати.

Деякі видавці ведуть кілька доменів. У такому разі кожен домен має свій файл ads.txt, якщо кожен домен призначений для показу інвентарю. Файл на одному домені не дає автоматичного дозволу іншому. Просте правило. Окремий файл.

3. Перевірте формат запису в ads.txt

Рядок ads.txt має точно відповідати вимогам синтаксису. Зазвичай структура містить домен рекламної системи, ID акаунта видавця, прапорець відносин і, інколи, необов’язковий ID органу сертифікації. Якщо будь-яке поле відсутнє або неправильне, перевірка може не пройти.

Типові помилки форматування зробити легко. Зайві пробіли на початку рядка. Невидимі символи, скопійовані з таблиці. Коми там, де мають бути лише перенесення рядка. Помилка в домені продавця. ID видавця, що належить іншому акаунту. Кожна з них може спричинити збій, і жодна не виглядає драматично в редакторі.

Тримайте файл чистим. Один рядок продавця на один рядок. Жодних коментарів, якщо Adgora прямо цього не дозволяє. Жодних HTML-тегів. Жодних «розумних» лапок. Жодних приміток про те, звідки ви взяли цей рядок. Лише потрібний текст.

Якщо перевіряєте файл вручну, скористайтеся такою таблицею:

Не вставляйте рядок спочатку в редактор форматованого тексту. Це може додати непомітний сміттєвий формат. Скопіюйте один раз. Вставте один раз. Збережіть один раз.

4. Підтвердьте відповідність домену й акаунта

Домен вашого сайту в Adgora має збігатися з доменом, указаним в ads.txt, і з доменом у вашому акаунті видавця. Якщо в панелі зазначено example.com, а сайт використовує blog.example.com, така невідповідність може створити плутанину під час перевірки або показу. Піддомени не завжди вважаються однаковою власністю.

Перевірте точне написання. http і https не є проблемою; проблема — у назві хоста. Кінцевий слеш теж не має значення, а от помилка в домені — має. Одна пропущена літера може перетворити звернення в підтримку на значно довшу історію, ніж потрібно.

Якщо ви керуєте кількома сайтами, ведіть простий список із трьома колонками: домен, запис акаунта Adgora та розташування ads.txt. Це звучить просто, бо так і є. Базові перевірки допомагають уникати повільних помилок. Неправильно вказаний домен — одна з найчастіших причин, чому файл виглядає правильним, але все одно не проходить перевірку.

Для видавців, які також читають про інші моделі трафіку, така сама уважність до відповідності важлива й у випадках на кшталт CPC проти CPM проти CPA, де неправильне налаштування може спотворити уявлення про те, що працює. Інша тема, та сама звичка: зіставляйте запис із реальною власністю.

5. Перевірте вимоги до подання розміщення

Перед поданням розміщення перевірте сторінку, де воно буде знаходитися. Контент має бути видимим, читабельним і релевантним. Сторінка з 50 словами та одним зображенням — не найкращий кандидат. Сторінка з чіткими розділами, нормальною навігацією та достатньою кількістю оригінального контенту зазвичай показує кращий результат.

Джерело трафіку теж має значення. Якщо ваш сайт отримує трафік із джерел, що порушують політику або виглядають штучно, розміщення можуть не схвалити. Це можуть бути примусові кліки, оманливі перенаправлення або низькоякісні патерни трафіку. Команда перевірки не шукає ідеалу; вона шукає послідовність і легітимний користувацький досвід.

Навігація також важлива. Перевіряльник має змогти перейти з головної сторінки на сторінки контенту без боротьби зі спливаючими вікнами чи битими посиланнями. Якщо меню приховане, зламане або перевантажене рекламою, це може погіршити шанси на схвалення. Одне чисте меню краще за п’ять захаращених.

Видавцям у нішах на кшталт рекламної мережі для криптопублішерів часто потрібно бути особливо уважними, оскільки категоризація та ясність контенту впливають на швидкість перевірки. Сторінка про гаманці, біржі чи токени має прямо говорити, що це. Без загадок. Без здогадок.

Перед поданням перевірте такі пункти:

• На сторінці видно оригінальний контент
• Навігація працює на комп’ютері й мобільному
• Не залишилося битих сторінок або порожніх розділів
• Джерела трафіку відповідають політиці
• Рекламний блок розміщено на живій сторінці, а не в чернетці

6. Усуньте типові блокери схвалення

Найпоширеніший блокер — тонкий контент. Якщо сторінка існує лише для того, щоб тримати рекламний блок, це зазвичай помітно. Додайте реальний текст, чіткі заголовки розділів і мету сторінки. Лендинг із одним абзацом і трьома кнопками рідко буває достатнім.

Інший блокер — слабка структура сайту. Якщо сторінка захована за битими посиланнями або недосяжна з меню, розміщення може залишитися в статусі очікування. Виправте шлях. Зробіть сторінку легкою для пошуку — бажано в два кліки або менше.

Проблеми з політикою інколи складніше помітити. Контент для дорослих, оманливі обіцянки, попередження про шкідливе ПЗ, агресивні спливаючі вікна або скопійовані матеріали можуть сповільнити схвалення або спричинити відхилення. Приберіть проблемний елемент, а потім зачекайте повторної перевірки сторінки. Не надсилайте одну й ту саму зламану версію знову й знову.

Деякі розміщення зависають, бо рекламний код встановили на сторінку, яка ще будується. Це легка помилка. Якщо сторінка не завершена, призупиніть подання, доки контент і макет не будуть готові остаточно. Перевіряльники оцінюють живу сторінку, а не ваші наміри.

Якщо сторінка належить до вертикалі на кшталт реклами дейтинг-оферів, контент має бути особливо чітким щодо аудиторії, вікового обмеження та меж політики. Неоднозначні сторінки зазвичай перевіряють довше. Ясність пришвидшує процес.

7. Повторно подайте й відстежуйте статус

Після виправлення ads.txt або оновлення розміщення повторно подайте запит у панелі Adgora. Намагайтеся не змінювати три речі одночасно, якщо це можливо. Якщо ви одночасно зміните файл, домен і рекламний блок, ви не зрозумієте, яке саме виправлення вирішило проблему.

Потім зачекайте, доки статус у панелі оновиться. Шукайте повідомлення про схвалення, очікування, відхилення або помилку. Якщо інтерфейс показує конкретну примітку, скопіюйте її дослівно. Саме формулювання має значення, коли ви порівнюєте повідомлення з останніми змінами.

Також перевірте час оновлення. Деякі системи оновлюються швидко, а іншим потрібно більше часу. Якщо файл уже доступний, а панель і далі показує старий стан після розумного інтервалу, перевірте публічний URL ads.txt і код сторінки. Кешована сторінка може створити враження, що оновлення не спрацювало.

Зберігайте скриншоти стану до й після. Один скриншот живого файлу ads.txt. Один скриншот сторінки розміщення. Один скриншот повідомлення в панелі. Три зображення можуть зекономити довге листування з підтримкою пізніше.

Якщо ви також працюєте з кількома каналами, та сама дисципліна повторного подання допомагає і в кампаніях із встановлення мобільних застосунків, де версія креативу та кінцева сторінка мають збігатися точно. Інший формат, та сама дисципліна.

8. Зверніться до підтримки Adgora з правильними деталями

Якщо проблема все ще не зникла, надішліть у підтримку точний домен, ID розміщення та повний текст помилки. Не пишіть лише «не працює» й не зупиняйтеся на цьому. Команди підтримки рухаються значно швидше, коли мають точну сторінку, точний блок і точний текст збою.

Додайте скриншоти файлу ads.txt так, як він виглядає в браузері, а не лише в редакторі. Додайте часову позначку, якщо вона є в панелі. Якщо проблема виникає лише на одному піддомені або в одному шаблоні сторінки, прямо скажіть про це. Одна така деталь може скоротити переписку вдвічі.

Якщо ваше звернення стосується того, як виправити ads.txt в Adgora, напишіть це в першому рядку. Потім перелічіть кроки, які ви вже зробили. Наприклад: оновив ads.txt, перевірив домен, повторно подав розміщення, очистив кеш і підтвердив, що сторінка активна. Підтримці не потрібна історія. Їй потрібен слід дій.

Використовуйте чіткі теми листа. «ads.txt validation fails on example.com» краще, ніж «help please». Додайте рядок продавця, якщо не впевнені, чи проблема в синтаксисі, і вкажіть, чи стосується проблема одного розміщення, чи всього акаунта. Одна примітка для всього акаунта може зекономити багато повторів. Якщо йдеться про схвалення розміщення Adgora, уточніть це прямо в темі та описі звернення.

Якщо хочете звірити терміни, поки чекаєте, допоможе глосарій ad tech. Це важливо, коли в одному зверненні ви порівнюєте записи продавця, статус розміщення та відповідність домену. Змішані терміни дають змішані відповіді.

Тікети в підтримку рухаються швидше, коли в них є цифри. Домен. ID розміщення. Код помилки. Дата подання. Навіть коротка примітка на кшталт «перевірено на 2 сторінках і 1 піддомені» дає команді щось конкретне для тесту. Факти завжди кращі за роздратування.