Як розмір налаштованої ROAS на рівні кампанії в Performance max впливає на вашу фактичну ROAS?
Або науковий підхід до аналізу причин, щоб оптимізувати результати рк команди ADWSERVICE.
Коротко кейс:
Маємо проєкт - непогано ідуть обороти, але треба підняти ROAS.
🔁Робимо тест - знижуємо tROAS і потім підвищуємо.
👁Бачимо, що середній чек не міняється загалом (+/- 10 грн), конверсія піднялася навіть. Але є нюанс.
🔎В попередньому періоді при нижчому CR мали вищу окупність!!!! Аналіз товарів показує про недостачу бюджету, але загалом міняючи товари в приорітетах - рентабельність не росте. Ідемо глибше.
🧩Дивимося на СРС. БАчимо, що різниця наче пару грн в загальному за період початку і кінця. Але…
Якщо провести аналіз більше глибоко, бачимо, що СРС і її зростання і падіння критично впливає на даний п макс в окупності.
Зниження tROAS → у середньому спостерігаємо зростання CPC у найближчі 3 дні (частіше в діапазоні +8…+20%),
а фактичний ROAS має тенденцію просідати (типово –10…–25%), при цьому конверсії зростають (часто +10…+30%) за рахунок ширшого охоплення й агресивніших ставок.
Підвищення tROAS → навпаки, CPC знижується (часто –8…–15%), фактичний ROAS стабілізується/підростає (через перехід у більш конверсійні аукціони), але обсяги конверсій звужуються (часто –10…–25%).
На графіку синя - це СРС
Зелена - фактична РОАС.
При чому я к бачите було тестовано різну роас, яка відразу показувала результ в падінні чи зростанні СРС.
Висновок:
1. Після правок памятаємо про буферний період 3-4 дні (про який Яна говорить бог зна скільки на каналі і в постах). Це період коли накладаються старі і попередні зміни. Тому аналізуйте комплексно 7-10 днів.
2. Вище ROAS - нижча СРС.
Нижче ROAS - вища СРС.
Як гугл розуміє, що він може отримати конверсію під вашу ROAS чи ні?
Він додає прогнозований коеф. конверісії для розрахунків.
Якщо складається 1+1 = отрим продаж під ту ROAS, що хочете.
Якщо ROAS вірний, але прогноз. кеф. конв. невистачає - правильного показу не буде.
Або науковий підхід до аналізу причин, щоб оптимізувати результати рк команди ADWSERVICE.
Коротко кейс:
Маємо проєкт - непогано ідуть обороти, але треба підняти ROAS.
🔁Робимо тест - знижуємо tROAS і потім підвищуємо.
👁Бачимо, що середній чек не міняється загалом (+/- 10 грн), конверсія піднялася навіть. Але є нюанс.
🔎В попередньому періоді при нижчому CR мали вищу окупність!!!! Аналіз товарів показує про недостачу бюджету, але загалом міняючи товари в приорітетах - рентабельність не росте. Ідемо глибше.
🧩Дивимося на СРС. БАчимо, що різниця наче пару грн в загальному за період початку і кінця. Але…
Якщо провести аналіз більше глибоко, бачимо, що СРС і її зростання і падіння критично впливає на даний п макс в окупності.
Зниження tROAS → у середньому спостерігаємо зростання CPC у найближчі 3 дні (частіше в діапазоні +8…+20%),
а фактичний ROAS має тенденцію просідати (типово –10…–25%), при цьому конверсії зростають (часто +10…+30%) за рахунок ширшого охоплення й агресивніших ставок.
Підвищення tROAS → навпаки, CPC знижується (часто –8…–15%), фактичний ROAS стабілізується/підростає (через перехід у більш конверсійні аукціони), але обсяги конверсій звужуються (часто –10…–25%).
На графіку синя - це СРС
Зелена - фактична РОАС.
При чому я к бачите було тестовано різну роас, яка відразу показувала результ в падінні чи зростанні СРС.
Висновок:
1. Після правок памятаємо про буферний період 3-4 дні (про який Яна говорить бог зна скільки на каналі і в постах). Це період коли накладаються старі і попередні зміни. Тому аналізуйте комплексно 7-10 днів.
2. Вище ROAS - нижча СРС.
Нижче ROAS - вища СРС.
Як гугл розуміє, що він може отримати конверсію під вашу ROAS чи ні?
Він додає прогнозований коеф. конверісії для розрахунків.
Якщо складається 1+1 = отрим продаж під ту ROAS, що хочете.
Якщо ROAS вірний, але прогноз. кеф. конв. невистачає - правильного показу не буде.
👍17❤1🔥1
Хотіла поділитись прикольною фічею в налаштуваннях кампаній, при виборі гео, але меню по вибору розбиває серденько😭.
Для зрівняння дві області:
- Запорізька
- Чернігівська
Для зрівняння дві області:
- Запорізька
- Чернігівська
😢13😁1
Цікава фіча в гуглі при виборі гео для локального бізнесу.
Вона давно є - але можливо хтось не знає, бо на консультації у людини був «культурний шок в гарному плані».
Бізнес очікує легкого в налаштуванні рекламного інструменту. Але інколи при високій ціні за клік доводиться «ковиряти» рекламні кампанії «в глубину». І це часто - гео.
Це офіційні таргетовані межі з баз Google Maps/Ads (адмінкордони, поштові зони), які географічно прилягають або входять до міської агломерації.
Для локального бізнесу може бути досить непоганою підказкою при пошуку де показуватись на невеликих бюджетах/ або що підрізати для економії бюджетів.
І цей же принцип показую на прикладі українських адмін. територій, але цей же принцип і для інших країн діє.
Вона давно є - але можливо хтось не знає, бо на консультації у людини був «культурний шок в гарному плані».
Бізнес очікує легкого в налаштуванні рекламного інструменту. Але інколи при високій ціні за клік доводиться «ковиряти» рекламні кампанії «в глубину». І це часто - гео.
Це офіційні таргетовані межі з баз Google Maps/Ads (адмінкордони, поштові зони), які географічно прилягають або входять до міської агломерації.
Для локального бізнесу може бути досить непоганою підказкою при пошуку де показуватись на невеликих бюджетах/ або що підрізати для економії бюджетів.
І цей же принцип показую на прикладі українських адмін. територій, але цей же принцип і для інших країн діє.
👍15🔥8❤3
Привіт! Це Яна, ваша Google-логістка 😊
Ми з командою AdwService беремо участь у рейтингу агенцій Ringostat в Україні.
Якщо мої відео на YouTube, пости в Telegram чи консультації допомогли вам розібратися з рекламою або покращити результати, буду рада вашій підтримці голосом за нашу агенцію.
Ось посилання для голосування:
https://rating.ringostat.ua/
Це займе менше 1 хвилини, а для мене й команди це буде сильним сигналом, що те, що ми робимо, для вас справді корисне 💛
Ми з командою AdwService беремо участь у рейтингу агенцій Ringostat в Україні.
Якщо мої відео на YouTube, пости в Telegram чи консультації допомогли вам розібратися з рекламою або покращити результати, буду рада вашій підтримці голосом за нашу агенцію.
Ось посилання для голосування:
https://rating.ringostat.ua/
Це займе менше 1 хвилини, а для мене й команди це буде сильним сигналом, що те, що ми робимо, для вас справді корисне 💛
rating.ringostat.ua
Ringostat — TOП digital-агенцій України 2025
ТОП digital-агенцій України 2025
❤22👍9👎2🔥1👌1
BF-2025_Google_Ads_Playbook_RFM_PRINT (2) (1).html
26.8 KB
1. Коли запускаємо.
2. Що запускаємо.
3. Тактичні дії по бюджетам.
4. Важлива інформація по базам клієнтів.
5. Отримуємо профіт.
https://youtu.be/kLC7sc0SQIE
Беремо і робимо. Не дамо блекаутам та «сусідам» зупинити єкомерс в країні 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
❤23🔥10👍2👎1
Forwarded from Розблокування Мерчант центр Merchant Center: Введення в оману (искажение фактов) Misrepresentation
🧨 Жовтень 2025: Misrepresentation після оновлення може бути квитком в один кінець для Merchant Center?
З жовтня Google уточнив і конкретизував політику Misrepresentation для Merchant Center і Shopping. Формально вони кажуть “ми просто пояснили”, але по факту:
❗ Стало значно простіше втратити акаунт назавжди і значно складніше його повернути.
Що саме змінилося - простою мовою 👇
1. Недоставка товарів = Misrepresentation, а не “помилки в логістиці”
Раніше “не встигли відправити, щось загубили, щось не доїхало” було скоріше про поганий сервіс.
Тепер Google чітко прописав:
+ якщо ви отримуєте оплату і системно не доставляєте товар,
+ прикидаєтесь “дисконт-магазином”, але замовлення “висять” тижнями,
+ клієнти не можуть ані отримати товар, ані повернути гроші -
це вже обман користувача на рівні політики, а не просто поганий досвід.
👉 Тобто збій у логістиці + пара скарг = вже не просто поганий відгук, а чіткий сигнал по Misrepresentation.
2. Повернення і рефанди: “написано, але не працює” = порушення політики
Ще один жорсткий акцент у оновленнях жовтня:
Якщо на сайті написано, що повернення “легкі, прості, протягом 14 днів”, але на практиці клієнти не можуть добитися повернення, ігнорується підтримка та звернення користувачів “відфутболюють” — це прямий кейс Misrepresentation.
Що тепер підозріло для Google:
- обіцяєте повернення, але:
- не відповідаєте на листи/дзвінки,
- тягнете час, поки сплине дедлайн,
-додаєте раптові “умови”, про які не було ні слова на сайті;
- політика повернення:
- захована глибоко, дрібним шрифтом, під спойлером
- написана розмито (“по узгодженню з адміністрацією” або "після комунікації з менеджером" ).
Коротко: обіцяв — виконуй. Або не обіцяй.
3. Відсутність прозорих умов = окремий вид Misrepresentation
Google окремо підсвітив блок “Omission of relevant information”:
- немає чітких умов доставки,
- незрозуміло, хто платить за повернення,
- повна вартість (доставка, комісії, підписки) стає видна тільки на останньому кроці checkout’у,
- немає нормальної сторінки “Про нас”, “Контакти”, “Повернення”, “Гарантія” — або вони взагалі пусті.
Це все тепер не просто “не дуже”, це прямий тригер до перевірки на Misrepresentation.
4. “Ми майже офіціали бренду” — тепер ще більш токсична історія
Особливо боляче прилітає тим, хто:
- продає брендові товари (електроніка, косметика, взуття тощо),
- любить писати:
“офіційний інтернет-магазин бренду”,
“офіційний дистриб’ютор в Україні”,
- ставити лого бренду так, ніби це їх власний офіційний сайт.
Якщо на сайті бренду вас немає у списку офіційних партнерів, якщо немає реального договору дистрибуції — це виглядає як брендовий Misrepresentation.
👉 Навіть якщо товар у вас реально оригінальний, але подача виглядає як “ми офіційний сайт бренду” — ризик блоку зараз набагато вищий.
5. Головний критичний момен: апеляцій мало, а новий акаунт = обхід системи
З жовтня Google уточнив і конкретизував політику Misrepresentation для Merchant Center і Shopping. Формально вони кажуть “ми просто пояснили”, але по факту:
❗ Стало значно простіше втратити акаунт назавжди і значно складніше його повернути.
Що саме змінилося - простою мовою 👇
1. Недоставка товарів = Misrepresentation, а не “помилки в логістиці”
Раніше “не встигли відправити, щось загубили, щось не доїхало” було скоріше про поганий сервіс.
Тепер Google чітко прописав:
+ якщо ви отримуєте оплату і системно не доставляєте товар,
+ прикидаєтесь “дисконт-магазином”, але замовлення “висять” тижнями,
+ клієнти не можуть ані отримати товар, ані повернути гроші -
це вже обман користувача на рівні політики, а не просто поганий досвід.
👉 Тобто збій у логістиці + пара скарг = вже не просто поганий відгук, а чіткий сигнал по Misrepresentation.
2. Повернення і рефанди: “написано, але не працює” = порушення політики
Ще один жорсткий акцент у оновленнях жовтня:
Якщо на сайті написано, що повернення “легкі, прості, протягом 14 днів”, але на практиці клієнти не можуть добитися повернення, ігнорується підтримка та звернення користувачів “відфутболюють” — це прямий кейс Misrepresentation.
Що тепер підозріло для Google:
- обіцяєте повернення, але:
- не відповідаєте на листи/дзвінки,
- тягнете час, поки сплине дедлайн,
-додаєте раптові “умови”, про які не було ні слова на сайті;
- політика повернення:
- захована глибоко, дрібним шрифтом, під спойлером
- написана розмито (“по узгодженню з адміністрацією” або "після комунікації з менеджером" ).
Коротко: обіцяв — виконуй. Або не обіцяй.
3. Відсутність прозорих умов = окремий вид Misrepresentation
Google окремо підсвітив блок “Omission of relevant information”:
- немає чітких умов доставки,
- незрозуміло, хто платить за повернення,
- повна вартість (доставка, комісії, підписки) стає видна тільки на останньому кроці checkout’у,
- немає нормальної сторінки “Про нас”, “Контакти”, “Повернення”, “Гарантія” — або вони взагалі пусті.
Це все тепер не просто “не дуже”, це прямий тригер до перевірки на Misrepresentation.
4. “Ми майже офіціали бренду” — тепер ще більш токсична історія
Особливо боляче прилітає тим, хто:
- продає брендові товари (електроніка, косметика, взуття тощо),
- любить писати:
“офіційний інтернет-магазин бренду”,
“офіційний дистриб’ютор в Україні”,
- ставити лого бренду так, ніби це їх власний офіційний сайт.
Якщо на сайті бренду вас немає у списку офіційних партнерів, якщо немає реального договору дистрибуції — це виглядає як брендовий Misrepresentation.
👉 Навіть якщо товар у вас реально оригінальний, але подача виглядає як “ми офіційний сайт бренду” — ризик блоку зараз набагато вищий.
5. Головний критичний момен: апеляцій мало, а новий акаунт = обхід системи
👍7❤6
Forwarded from Розблокування Мерчант центр Merchant Center: Введення в оману (искажение фактов) Misrepresentation
Ось тут починається саме цікаве: 👇
1. Misrepresentation = egregious violation.
Це не “дрібна помилка”. Акаунт можуть заблокувати без попередженнь і в політиці прямо написано, що можете більше ніколи не отримати право рекламуватися в Shopping.
2. Кількість апеляцій обмежена.
З досвіду ринку — у більшості кейсів це 2–3 реальні спроби. Далі ваш акаунт в очах системи практично “мертвий”.
3. Створити новий Merchant / Ads після бану = показати Google, що ви обходите політику.
Google прямо забороняє:
- створювати нові Ads-акаунти, якщо старий заблокований;
- в Merchant Center офіційно пише, що видалення заблокованого акаунта і створення нового для того ж бізнесу проблему не вирішить — новий з великою ймовірністю теж полетить в бан.
4. Google бере до уваги не тільки на ID акаунта.
Той самий домен, та сама юрособа/ФОП, та сама платіжка, ті ж логіни, ті ж IP, той же MCC, ті ж GTM/GA — це все лінки, за якими система розуміє:
“Це той самий бізнес, який ми вже заблокували. Він просто перелогінився і намагається зайти з чорного ходу”.
Результат:
❌ пару непідготовлених апеляцій “на відчепись” + спроба завести новий акаунт = шансів на розблокування майже не лишається.
5. Що це означає для власників інтернет-магазинів
Якщо коротко і чесно:
- підхід “ну давайте самі щось напишемо в апеляції” більше не працює.
- Кожна апеляція має бути підготовленою.
- Неправильний крок = мінус Merchant Center, мінус Shopping, мінус Performance Max не на тиждень, а практично назавжди.
Тепер розблокування — це не формальність, а окремий вид діяльності:
- аудит сайту + фіда під Misrepresentation (логістика, повернення, тексти, бренди, GTIN, легальність позиціонування);
- пакет доказів (інвойси, політики, скріни до/після, документи від постачальників);
- грамотна апеляція, яка говорить мовою Google-політик, а не “будь ласка, розбаньте, ми все виправили”.
6. Які дії я виконую в таких кейсах:
Я не просто жму кнопку «подати апеляцію».
Я використовую такий підхід до розбану Merchant Center:
- розбираюся, що саме тригернуло Misrepresentation у вашому кейсі (часто там не одна, а кілька проблем: бренди, логістика, політики, цінові розбіжності);
- даю конкретний деталізований чек-лист правок по сайту, фіду, політиках, позиціонуванню бренду;
- збираю з вами пакет доказів, які Google реально дивиться;
- фіксую, що знову потенційно не сподобалося модератору.
Тому що в 2025 натиснути кнопку “Request review” - це найпростіша частина.
Значно складніше, зробити так, щоб у вас взагалі були шанси, що її схвалять.
Якщо у вас уже є:
🔴 Misrepresentation / “Введення в оману”,
🔴 підозра, що скоро прилетить (брендова ніша, підозріле повернення, дивна логістика),
🔴 або ви вже один раз апелювали й вам відмовили -...
1. Misrepresentation = egregious violation.
Це не “дрібна помилка”. Акаунт можуть заблокувати без попередженнь і в політиці прямо написано, що можете більше ніколи не отримати право рекламуватися в Shopping.
2. Кількість апеляцій обмежена.
З досвіду ринку — у більшості кейсів це 2–3 реальні спроби. Далі ваш акаунт в очах системи практично “мертвий”.
3. Створити новий Merchant / Ads після бану = показати Google, що ви обходите політику.
Google прямо забороняє:
- створювати нові Ads-акаунти, якщо старий заблокований;
- в Merchant Center офіційно пише, що видалення заблокованого акаунта і створення нового для того ж бізнесу проблему не вирішить — новий з великою ймовірністю теж полетить в бан.
4. Google бере до уваги не тільки на ID акаунта.
Той самий домен, та сама юрособа/ФОП, та сама платіжка, ті ж логіни, ті ж IP, той же MCC, ті ж GTM/GA — це все лінки, за якими система розуміє:
“Це той самий бізнес, який ми вже заблокували. Він просто перелогінився і намагається зайти з чорного ходу”.
Результат:
❌ пару непідготовлених апеляцій “на відчепись” + спроба завести новий акаунт = шансів на розблокування майже не лишається.
5. Що це означає для власників інтернет-магазинів
Якщо коротко і чесно:
- підхід “ну давайте самі щось напишемо в апеляції” більше не працює.
- Кожна апеляція має бути підготовленою.
- Неправильний крок = мінус Merchant Center, мінус Shopping, мінус Performance Max не на тиждень, а практично назавжди.
Тепер розблокування — це не формальність, а окремий вид діяльності:
- аудит сайту + фіда під Misrepresentation (логістика, повернення, тексти, бренди, GTIN, легальність позиціонування);
- пакет доказів (інвойси, політики, скріни до/після, документи від постачальників);
- грамотна апеляція, яка говорить мовою Google-політик, а не “будь ласка, розбаньте, ми все виправили”.
6. Які дії я виконую в таких кейсах:
Я не просто жму кнопку «подати апеляцію».
Я використовую такий підхід до розбану Merchant Center:
- розбираюся, що саме тригернуло Misrepresentation у вашому кейсі (часто там не одна, а кілька проблем: бренди, логістика, політики, цінові розбіжності);
- даю конкретний деталізований чек-лист правок по сайту, фіду, політиках, позиціонуванню бренду;
- збираю з вами пакет доказів, які Google реально дивиться;
- фіксую, що знову потенційно не сподобалося модератору.
Тому що в 2025 натиснути кнопку “Request review” - це найпростіша частина.
Значно складніше, зробити так, щоб у вас взагалі були шанси, що її схвалять.
Якщо у вас уже є:
🔴 Misrepresentation / “Введення в оману”,
🔴 підозра, що скоро прилетить (брендова ніша, підозріле повернення, дивна логістика),
🔴 або ви вже один раз апелювали й вам відмовили -...
👍6🤯5🔥1
Зараз спостерігається масштабний збій у глобальному провайдері Cloudflare, через якого проходить DNS і трафік великої кількості сайтів у всьому світі.
Це зовнішній технічний інцидент, а не проблема саме сайту чи налаштувань.
Як тільки Cloudflare повністю відновить роботу, сайт автоматично почне відкриватися коректно.
Cloudflare вже офіційно підтвердив глобальний outage, про це пишуть тех-ЗМІ (Techzine, Tom’s Guide тощо): багато сайтів, включно з X (Twitter), частиною чат-ботів і сервісів, відкриваються через раз або взагалі не вантажаться.
https://www.cloudflarestatus.com/
Що робити?
Вирубити рк, якщо сайт непрацює і включити після відновлення.
Або залишаємо так як є/менше бюджету +
І тут можна відкоригувати вже трафік в кабінеті
Ось тут ця фіча буде корисною. Яку ви часто для коригування фейків користуєте невірно.
Це зовнішній технічний інцидент, а не проблема саме сайту чи налаштувань.
Як тільки Cloudflare повністю відновить роботу, сайт автоматично почне відкриватися коректно.
Cloudflare вже офіційно підтвердив глобальний outage, про це пишуть тех-ЗМІ (Techzine, Tom’s Guide тощо): багато сайтів, включно з X (Twitter), частиною чат-ботів і сервісів, відкриваються через раз або взагалі не вантажаться.
https://www.cloudflarestatus.com/
Що робити?
Вирубити рк, якщо сайт непрацює і включити після відновлення.
Або залишаємо так як є/менше бюджету +
І тут можна відкоригувати вже трафік в кабінеті
Ось тут ця фіча буде корисною. Яку ви часто для коригування фейків користуєте невірно.
👍12❤3🔥2
Чи можна поповнювати рекламний кабінет крипто-гаманцями? Якщо це допустим буде віртуальна картка?
Як Google бачить віртуальну / crypto-карту
Для Google важливо не те, “віртуальна чи пластик”, а:
- тип картки (credit / debit / prepaid),
- BIN (перші 6–8 цифр) – по ньому видно країну й тип емітента, у т.ч. деякі crypto-/high-risk-фінтехи,
- чи збігається країна картки з країною білінгу,
- чи не виглядає вона як “одноразова для фарму акаунтів”.
Якщо це звичайна віртуальна Visa/Mastercard від банку або легального фінтеху, з повною KYC, і BIN не належить до high-risk/crypto – у більшості кейсів такі карти нормально працюють у Google Ads. Є купа фінтехів, які прямо просувають свої віртуалки “для Google Ads”.
Проблеми частіше з:
- prepaid-картками, особливо для automatic payments – Google їх далеко не завжди приймає.
- картками з BIN-ами, які пов’язані з крипто-сервісами чи сірими провайдерами – вище шанс блокування або запиту додаткової верифікації.
Що з crypto-картами типу “поповнюю криптою, але виглядає як звичайна Visa/Mastercard”
Фактично це:
- або нормальний фінтех-банк (з повною ліцензією), який просто дозволяє завести гроші з біржі;
- або crypto-фінтех з BIN, який у risk-системах іде як “high-risk / crypto”.
Google не бачить, що саме вони поповнені криптою, але:
- по BIN-у й MCC емітента може розуміти, що це специфічний провайдер;
- такі карти частіше потрапляють у ручну перевірку або дають відхили платежів.
Тобто це не гарантійний бан → але ризик “suspicious payments” точно вищий, ніж у класичної банківської карти.
Найбезпечніший варіант для довгострокового акаунта:
- звичайна кредитна/дебетова карта компанії або власника бізнесу (Visa/Mastercard/AmEx),
- емітована банком/фінтехом з нормальною репутацією,
- країна карти = країна білінгу акаунта,
- ім’я власника карти збігається з білінговими даними.
Віртуальна карта ок, якщо:
- вона не позиціонується як “анонімна / одноразова / для арбітражу”;
- це звичайний банківський продукт, просто без пластику;
- є повні реквізити (ім’я, CVV, дата, адреса),
- не використовується масово на десятках акаунтів з різними компаніями.
Crypto-карту я б користувала обережно:
- “Технічно може працювати, якщо емітент – легальний банк/фінтех і карта виглядає як стандартна Visa/Mastercard.
- ❗️❗️❗️Але Google офіційно рекомендує не використовувати віртуальні/препейд-карти, бо з ними частіше трапляються блокування та відхили платежів. Тому ми не можемо гарантувати стабільну роботу такої карти й радимо мати ‘резервну’ класичну карту на випадок перевірок”.
Якщо у вас інша інфа - поділіться в коментах - буде всім корисно.
Як Google бачить віртуальну / crypto-карту
Для Google важливо не те, “віртуальна чи пластик”, а:
- тип картки (credit / debit / prepaid),
- BIN (перші 6–8 цифр) – по ньому видно країну й тип емітента, у т.ч. деякі crypto-/high-risk-фінтехи,
- чи збігається країна картки з країною білінгу,
- чи не виглядає вона як “одноразова для фарму акаунтів”.
Якщо це звичайна віртуальна Visa/Mastercard від банку або легального фінтеху, з повною KYC, і BIN не належить до high-risk/crypto – у більшості кейсів такі карти нормально працюють у Google Ads. Є купа фінтехів, які прямо просувають свої віртуалки “для Google Ads”.
Проблеми частіше з:
- prepaid-картками, особливо для automatic payments – Google їх далеко не завжди приймає.
- картками з BIN-ами, які пов’язані з крипто-сервісами чи сірими провайдерами – вище шанс блокування або запиту додаткової верифікації.
Що з crypto-картами типу “поповнюю криптою, але виглядає як звичайна Visa/Mastercard”
Фактично це:
- або нормальний фінтех-банк (з повною ліцензією), який просто дозволяє завести гроші з біржі;
- або crypto-фінтех з BIN, який у risk-системах іде як “high-risk / crypto”.
Google не бачить, що саме вони поповнені криптою, але:
- по BIN-у й MCC емітента може розуміти, що це специфічний провайдер;
- такі карти частіше потрапляють у ручну перевірку або дають відхили платежів.
Тобто це не гарантійний бан → але ризик “suspicious payments” точно вищий, ніж у класичної банківської карти.
Найбезпечніший варіант для довгострокового акаунта:
- звичайна кредитна/дебетова карта компанії або власника бізнесу (Visa/Mastercard/AmEx),
- емітована банком/фінтехом з нормальною репутацією,
- країна карти = країна білінгу акаунта,
- ім’я власника карти збігається з білінговими даними.
Віртуальна карта ок, якщо:
- вона не позиціонується як “анонімна / одноразова / для арбітражу”;
- це звичайний банківський продукт, просто без пластику;
- є повні реквізити (ім’я, CVV, дата, адреса),
- не використовується масово на десятках акаунтів з різними компаніями.
Crypto-карту я б користувала обережно:
- “Технічно може працювати, якщо емітент – легальний банк/фінтех і карта виглядає як стандартна Visa/Mastercard.
- ❗️❗️❗️Але Google офіційно рекомендує не використовувати віртуальні/препейд-карти, бо з ними частіше трапляються блокування та відхили платежів. Тому ми не можемо гарантувати стабільну роботу такої карти й радимо мати ‘резервну’ класичну карту на випадок перевірок”.
Якщо у вас інша інфа - поділіться в коментах - буде всім корисно.
❤7👍7👎2
У багатьох останнім часом мерчант центр свариться на ось цю помилку Download failed due to authentication error. Please check username and password in your feed configuration and try again або така як на картинці (тут корінь проблеми той самий).
Якщо ви не задавали ніяких паролів і тд і наче все ок, файл відкривається в іншому вікні, а мерчант вперся і каже що ні, то проблема в тому, що на рівні вашого сайту заблочений доступ певного виду РОБОТА від гугла, який читає ці дані.
У одного з клієнтів була така ситуація і розробник просто під час спілкування сказав, що бачить дуже багато блоків на звернення якогось боту. І як тільки він його пропустив - то фід відразу пішов на завантаження. Буквально 1 хв.
Що ще може бути причиною?
1) Редіректи, токени, cookies, “людські” сторінки
- Якщо URL робить 301/302 на сторінку, що вимагає cookie/сесію/JS-рендерінг (Google Drive/Dropbox “view” замість прямого “download”), Google отримає HTML-сторінку з вимогою увійти і трактує це як “authentication error”. Для Drive потрібен прямий лінк на файл (export=download / uc?export=download).
2) WAF / CDN (Cloudflare та ін.)
WAF може показувати челендж/блок для ботів (навіть якщо людині все ок). Результат для Google — 401/403. Перевірте правила: зніміть челенджі для запитів з Google-івських фетчерів, дозвольте їх IP/UA. Є типові кейси з Cloudflare, де саме це спричиняє “Authentication failed”.
3. Обмеження по IP/гео на сервері
Якщо сервер або хостинг обмежує доступ за країною/IP, Google не потрапляє. Гугл публікує діапазони для “user-triggered fetchers” та методику перевірки справжності ботів — використайте це для allowlist.
4. Помилкове трактування “логіну” сайтом
Інколи бекенд вимагає заголовки/реферер/UA інакші, або підкладає “login wall” при відсутності певних cookies. Для бота це виглядає як вимога авторизації (401/“login required”). У довідці GMC це описано як загальний випадок “логін потрібен для перегляду” — такого бути не повинно.
Але зазвичай причина:
Сервер блокує Google IP / ботів
Наприклад:
Cloudflare
інший WAF / firewall
anti-bot rules
👉 Для людини у браузері все відкривається
👉 Для Google Fetcher — TCP/HTTP connection не встановлюється
🔴 Це топ-1 причина такої помилки.
Якщо ви не задавали ніяких паролів і тд і наче все ок, файл відкривається в іншому вікні, а мерчант вперся і каже що ні, то проблема в тому, що на рівні вашого сайту заблочений доступ певного виду РОБОТА від гугла, який читає ці дані.
У одного з клієнтів була така ситуація і розробник просто під час спілкування сказав, що бачить дуже багато блоків на звернення якогось боту. І як тільки він його пропустив - то фід відразу пішов на завантаження. Буквально 1 хв.
Що ще може бути причиною?
1) Редіректи, токени, cookies, “людські” сторінки
- Якщо URL робить 301/302 на сторінку, що вимагає cookie/сесію/JS-рендерінг (Google Drive/Dropbox “view” замість прямого “download”), Google отримає HTML-сторінку з вимогою увійти і трактує це як “authentication error”. Для Drive потрібен прямий лінк на файл (export=download / uc?export=download).
2) WAF / CDN (Cloudflare та ін.)
WAF може показувати челендж/блок для ботів (навіть якщо людині все ок). Результат для Google — 401/403. Перевірте правила: зніміть челенджі для запитів з Google-івських фетчерів, дозвольте їх IP/UA. Є типові кейси з Cloudflare, де саме це спричиняє “Authentication failed”.
3. Обмеження по IP/гео на сервері
Якщо сервер або хостинг обмежує доступ за країною/IP, Google не потрапляє. Гугл публікує діапазони для “user-triggered fetchers” та методику перевірки справжності ботів — використайте це для allowlist.
4. Помилкове трактування “логіну” сайтом
Інколи бекенд вимагає заголовки/реферер/UA інакші, або підкладає “login wall” при відсутності певних cookies. Для бота це виглядає як вимога авторизації (401/“login required”). У довідці GMC це описано як загальний випадок “логін потрібен для перегляду” — такого бути не повинно.
Але зазвичай причина:
Сервер блокує Google IP / ботів
Наприклад:
Cloudflare
інший WAF / firewall
anti-bot rules
👉 Для людини у браузері все відкривається
👉 Для Google Fetcher — TCP/HTTP connection не встановлюється
🔴 Це топ-1 причина такої помилки.
👍11👎4❤1
Повторення.
Google Merchant Center: масова помилка Authentication error / Failed to connect
Останнім часом бачу однакову проблему на різних платформах - WordPress, Prom.ua, кастомні сайти:
При цьому:
• фід публічний
• у браузері відкривається
• логінів/паролів не існує
Через це багато хто починає:
• міняти плагіни
• перевстановлювати сайт
• шукати “кривий фід”
🔴 Але проблема, як правило, не в CMS і не у фіді.
⸻
🌍 Що пишуть за кордоном
Це не локальний кейс. Такі ж помилки масово обговорюють:
• Cloudflare Community
Люди описують ситуацію, коли Google Merchant Center не може забрати фід, а Cloudflare / WAF / Bot Fight Mode блокує або челенджить запит. Для Google це виглядає як auth / connection error.
• Reddit (WordPress, Google Ads, Merchant Center сабреддіти)
Типовий патерн:
“Feed is public, works in browser, but Merchant Center says authentication error”
І майже завжди рішення — послаблення bot protection або винесення фіда на інший хостинг.
• StackExchange / SEO-форуми
Старі треди з тією ж логікою: Google не отримує XML, а HTML / challenge / 403 — і трактує це як проблему авторизації.
Ця помилка не означає, що Google реально просить логін і пароль.
У 80–90% випадків це означає:
• блокування на рівні Cloudflare / firewall / anti-bot
• geo / IP restrictions
• security-плагіни
• або динамічний фід, який Google просто не може стабільно забрати
Тобто Merchant Center не “авторизується”, бо його туди не пускають.
✅ Що реально працює
• allowlist / bypass правил для Google Merchant Fetcher
• послаблення bot-захисту саме для URL фіда
• або винесення фіда на нейтральний хостинг (SFTP / GCS / Drive)
❌ Перевстановлення сайту — не рішення
❌ Заміна плагінів — рідко допомагає
❌ “Це баг WordPress / Prom” — ні
Google Merchant Center: масова помилка Authentication error / Failed to connect
Останнім часом бачу однакову проблему на різних платформах - WordPress, Prom.ua, кастомні сайти:
Download failed due to authentication error
Failed to connect to the remote server
При цьому:
• фід публічний
• у браузері відкривається
• логінів/паролів не існує
Через це багато хто починає:
• міняти плагіни
• перевстановлювати сайт
• шукати “кривий фід”
🔴 Але проблема, як правило, не в CMS і не у фіді.
⸻
🌍 Що пишуть за кордоном
Це не локальний кейс. Такі ж помилки масово обговорюють:
• Cloudflare Community
Люди описують ситуацію, коли Google Merchant Center не може забрати фід, а Cloudflare / WAF / Bot Fight Mode блокує або челенджить запит. Для Google це виглядає як auth / connection error.
• Reddit (WordPress, Google Ads, Merchant Center сабреддіти)
Типовий патерн:
“Feed is public, works in browser, but Merchant Center says authentication error”
І майже завжди рішення — послаблення bot protection або винесення фіда на інший хостинг.
• StackExchange / SEO-форуми
Старі треди з тією ж логікою: Google не отримує XML, а HTML / challenge / 403 — і трактує це як проблему авторизації.
Ця помилка не означає, що Google реально просить логін і пароль.
У 80–90% випадків це означає:
• блокування на рівні Cloudflare / firewall / anti-bot
• geo / IP restrictions
• security-плагіни
• або динамічний фід, який Google просто не може стабільно забрати
Тобто Merchant Center не “авторизується”, бо його туди не пускають.
✅ Що реально працює
• allowlist / bypass правил для Google Merchant Fetcher
• послаблення bot-захисту саме для URL фіда
• або винесення фіда на нейтральний хостинг (SFTP / GCS / Drive)
❌ Перевстановлення сайту — не рішення
❌ Заміна плагінів — рідко допомагає
❌ “Це баг WordPress / Prom” — ні
🔥3❤1
Чому раніше Google Merchant Center забирав фіди без проблем, а зараз — ні?
Якщо покопатися на іноз ресурсах, блогах і тд.
Це питання зараз звучить найчастіше.
Коротка відповідь: зміни відбулися з двох сторін одночасно — і з боку Google, і з боку систем безпеки сайтів.
⸻
🕰 Як це працювало раніше
Раніше схема була дуже проста:
• Google Merchant Center приходив за посиланням на фід
• сервер сайту віддавав файл
• системи захисту майже не втручались
Scheduled Fetch (планове завантаження фіда) —
це коли Google автоматично, за розкладом, сам приходить по URL і забирає файл.
Тоді цей запит:
• виглядав “нормально”
• не викликав підозр
• спокійно проходив через захист сайту
⸻
🔄 Що змінилося з боку Google
Google не робив гучних анонсів, але по факту:
• Google чітко відокремив сканування сайтів і забір даних
• для фідів використовується окремий бот — FeedFetcher
(це не Googlebot, а спеціальний “збирач” даних для Merchant Center)
FeedFetcher:
• працює автоматично
• приходить регулярно
• не використовує браузер (без JS, cookies, кліків)
• забирає великі файли (XML, CSV)
➡️ Тобто виглядає як чистий машинний запит.
⸻
🔐 Що змінилося з боку Cloudflare та інших систем захисту
Cloudflare — це популярна система захисту сайтів
(антибот, firewall, захист від атак).
За останній час Cloudflare та подібні системи:
• стали агресивніше фільтрувати ботів
• перейшли з простих правил на поведінковий аналіз
• більше не довіряють просто назві бота
Тепер перевіряється:
• чи є взаємодія, як у людини
• чи працює JavaScript
• чи є cookies
• як часто повторюються запити
• який обʼєм даних запитується
FeedFetcher:
• не клікає
• не виконує JS
• приходить регулярно
➡️ І часто потрапляє під підозру, навіть будучи легальним Google.
⸻
⚠️ Важливий момент
Це не помилка фіда і не баг Merchant Center.
Це результат того, що:
Google оптимізував автоматичний забір даних
а системи захисту посилили боротьбу з ботами
І ці два процеси почали конфліктувати.
⸻
🧩 Чому це видно одразу на різних платформах
Тому що проблема:
• не у WordPress
• не у Prom.ua
• не в плагінах
А в тому, що автоматичний забір фідів більше не є “безпечним за замовчуванням”.
⸻
🟢 Що з цього випливає
Те, що раніше “просто працювало”, тепер:
• або потребує окремих дозволів у захисті
• або потребує проміжного шару між сайтом і Merchant Center
📌 Головна думка
Проблема зʼявилась не раптово.
Просто Google і системи безпеки сайтів перестали “розуміти один одного” за замовчуванням.
П.С. Не перетендую на істинність, але погуглила і прийшла до цього висновку. Якщо є специ які розуміються на цьому краще - відпишіть будь ласка.
Якщо покопатися на іноз ресурсах, блогах і тд.
Це питання зараз звучить найчастіше.
Коротка відповідь: зміни відбулися з двох сторін одночасно — і з боку Google, і з боку систем безпеки сайтів.
⸻
🕰 Як це працювало раніше
Раніше схема була дуже проста:
• Google Merchant Center приходив за посиланням на фід
• сервер сайту віддавав файл
• системи захисту майже не втручались
Scheduled Fetch (планове завантаження фіда) —
це коли Google автоматично, за розкладом, сам приходить по URL і забирає файл.
Тоді цей запит:
• виглядав “нормально”
• не викликав підозр
• спокійно проходив через захист сайту
⸻
🔄 Що змінилося з боку Google
Google не робив гучних анонсів, але по факту:
• Google чітко відокремив сканування сайтів і забір даних
• для фідів використовується окремий бот — FeedFetcher
(це не Googlebot, а спеціальний “збирач” даних для Merchant Center)
FeedFetcher:
• працює автоматично
• приходить регулярно
• не використовує браузер (без JS, cookies, кліків)
• забирає великі файли (XML, CSV)
➡️ Тобто виглядає як чистий машинний запит.
⸻
🔐 Що змінилося з боку Cloudflare та інших систем захисту
Cloudflare — це популярна система захисту сайтів
(антибот, firewall, захист від атак).
За останній час Cloudflare та подібні системи:
• стали агресивніше фільтрувати ботів
• перейшли з простих правил на поведінковий аналіз
• більше не довіряють просто назві бота
Тепер перевіряється:
• чи є взаємодія, як у людини
• чи працює JavaScript
• чи є cookies
• як часто повторюються запити
• який обʼєм даних запитується
FeedFetcher:
• не клікає
• не виконує JS
• приходить регулярно
➡️ І часто потрапляє під підозру, навіть будучи легальним Google.
⸻
⚠️ Важливий момент
Це не помилка фіда і не баг Merchant Center.
Це результат того, що:
Google оптимізував автоматичний забір даних
а системи захисту посилили боротьбу з ботами
І ці два процеси почали конфліктувати.
⸻
🧩 Чому це видно одразу на різних платформах
Тому що проблема:
• не у WordPress
• не у Prom.ua
• не в плагінах
А в тому, що автоматичний забір фідів більше не є “безпечним за замовчуванням”.
⸻
🟢 Що з цього випливає
Те, що раніше “просто працювало”, тепер:
• або потребує окремих дозволів у захисті
• або потребує проміжного шару між сайтом і Merchant Center
📌 Головна думка
Проблема зʼявилась не раптово.
Просто Google і системи безпеки сайтів перестали “розуміти один одного” за замовчуванням.
П.С. Не перетендую на істинність, але погуглила і прийшла до цього висновку. Якщо є специ які розуміються на цьому краще - відпишіть будь ласка.
👍12❤1