Привіт! Це Яна, ваша Google-логістка 😊
Ми з командою AdwService беремо участь у рейтингу агенцій Ringostat в Україні.
Якщо мої відео на YouTube, пости в Telegram чи консультації допомогли вам розібратися з рекламою або покращити результати, буду рада вашій підтримці голосом за нашу агенцію.
Ось посилання для голосування:
https://rating.ringostat.ua/
Це займе менше 1 хвилини, а для мене й команди це буде сильним сигналом, що те, що ми робимо, для вас справді корисне 💛
Ми з командою AdwService беремо участь у рейтингу агенцій Ringostat в Україні.
Якщо мої відео на YouTube, пости в Telegram чи консультації допомогли вам розібратися з рекламою або покращити результати, буду рада вашій підтримці голосом за нашу агенцію.
Ось посилання для голосування:
https://rating.ringostat.ua/
Це займе менше 1 хвилини, а для мене й команди це буде сильним сигналом, що те, що ми робимо, для вас справді корисне 💛
rating.ringostat.ua
ТОП digital-агенцій України 2025
Це відкрите відображення digital-ринку України. Ми формуємо ТОП агенцій, які здатні комплексно закривати потреби бізнесу у digital-просуванні.
❤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🔥11👍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. Головний критичний момен: апеляцій мало, а новий акаунт = обхід системи
👍8❤7
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 / “Введення в оману”,
🔴 підозра, що скоро прилетить (брендова ніша, підозріле повернення, дивна логістика),
🔴 або ви вже один раз апелювали й вам відмовили -...
👍7🤯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/
Що робити?
Вирубити рк, якщо сайт непрацює і включити після відновлення.
Або залишаємо так як є/менше бюджету +
І тут можна відкоригувати вже трафік в кабінеті
Ось тут ця фіча буде корисною. Яку ви часто для коригування фейків користуєте невірно.
👍13❤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 офіційно рекомендує не використовувати віртуальні/препейд-карти, бо з ними частіше трапляються блокування та відхили платежів. Тому ми не можемо гарантувати стабільну роботу такої карти й радимо мати ‘резервну’ класичну карту на випадок перевірок”.
Якщо у вас інша інфа - поділіться в коментах - буде всім корисно.
❤8👍8👎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 причина такої помилки.
👍13👎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” — ні
🔥6❤2
Чому раніше 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 і системи безпеки сайтів перестали “розуміти один одного” за замовчуванням.
П.С. Не перетендую на істинність, але погуглила і прийшла до цього висновку. Якщо є специ які розуміються на цьому краще - відпишіть будь ласка.
👍15❤3🔥1
🧩 Відео не для всіх.
Це для людей, які:
— люблять докопатися до логіки
— хочуть знати “чому саме так”
— і тримати систему за горло, а не за хвіст
Я показую, як ROAS на старті реально впливає на трафік через аукціон.👉 https://www.youtube.com/watch?v=LOU-V8HTN6g
🔥 Я зняла відео, яке економить вам тижні “а чого не крутиться?”
Так, це про ROAS на старті.
Так, я буду душнити.
Бо мені важливо, щоб у вас витрачалося, навчалося, і зароблялося, а не “поставили 2500% і чекаємо дива”.
Такого вам на курсах не розкажуть :)🌈
Це для людей, які:
— люблять докопатися до логіки
— хочуть знати “чому саме так”
— і тримати систему за горло, а не за хвіст
Я показую, як ROAS на старті реально впливає на трафік через аукціон.👉 https://www.youtube.com/watch?v=LOU-V8HTN6g
🔥 Я зняла відео, яке економить вам тижні “а чого не крутиться?”
Так, це про ROAS на старті.
Так, я буду душнити.
Бо мені важливо, щоб у вас витрачалося, навчалося, і зароблялося, а не “поставили 2500% і чекаємо дива”.
Такого вам на курсах не розкажуть :)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥35❤7😁5👍3
Google AI по фотці асоціює з Temu — головне фото треба інше.”
Пу-пу-пу....
Google Shopping алгоритм бачить не тільки title, ціну чи бренд. Він бачить ще й сам товар візуально.
Якщо у вас фото з фабричного каталогу, яке вже об’їхало пів інтернету, то для алгоритму і для користувача ви не виглядаєте як окремий бренд.
Ви виглядаєте як ще одна копія Temu / Shein / no-name маркетплейсу.
І ось тут починається найнеприємніше.
Ви можете:
— мати нормальний сайт
— мати кращу доставку
— мати реальний сервіс
— мати кращу якість товару
— мати вищу ціну, бо ви не демпінгуєте
Але в аукціоні вас зчитують за 1 секунду.
І якщо головне фото кричить:
“я такий самий, як усі дешеві копії”,
то далі вже можете скільки завгодно розказувати про переваги.
Ніхто їх не побачить.
Бо клікнуть не туди.
в Shopping головне фото — це не просто картинка. Це частина алгоритмічного позиціонування товару.
Гдє ваши доказатєльства, Яна - запитаєте ви мене.
У мене немає прямої статті від гугла, але ж ми знаємо що все взаємоповязано (якщо десь інструмент гугл допилив для зручності пошуку товару під користувачв.- то це напряму буде впливати на те як Гугл буде шукати той товар серед нас рекламодавців).
Які пункти можуть говорити про це?
- Vision Match (запущений березень 2025) — AI генерує зображення і шукає "visually similar shoppable products"
- Google's shopping assistant може аналізувати і інтерпретувати зображення, використовуючи візуальні дані для матчингу продуктів — це називається visual search або image recognition
- Сучасна AI-пошукова система у 3 шарах: detection (знаходить об'єкти і атрибути — "dress, floral, sleeveless"), matching (порівнює з каталогом), ranking
- Ризик: візуальний пошук не розрізняє оригінальні продукти від lookalikes. Результати можуть включати counterfeit listings або дешеві "dupe" продукти які візуально нагадують item
Пу-пу-пу....
Google Shopping алгоритм бачить не тільки title, ціну чи бренд. Він бачить ще й сам товар візуально.
Якщо у вас фото з фабричного каталогу, яке вже об’їхало пів інтернету, то для алгоритму і для користувача ви не виглядаєте як окремий бренд.
Ви виглядаєте як ще одна копія Temu / Shein / no-name маркетплейсу.
І ось тут починається найнеприємніше.
Ви можете:
— мати нормальний сайт
— мати кращу доставку
— мати реальний сервіс
— мати кращу якість товару
— мати вищу ціну, бо ви не демпінгуєте
Але в аукціоні вас зчитують за 1 секунду.
І якщо головне фото кричить:
“я такий самий, як усі дешеві копії”,
то далі вже можете скільки завгодно розказувати про переваги.
Ніхто їх не побачить.
Бо клікнуть не туди.
в Shopping головне фото — це не просто картинка. Це частина алгоритмічного позиціонування товару.
Гдє ваши доказатєльства, Яна - запитаєте ви мене.
У мене немає прямої статті від гугла, але ж ми знаємо що все взаємоповязано (якщо десь інструмент гугл допилив для зручності пошуку товару під користувачв.- то це напряму буде впливати на те як Гугл буде шукати той товар серед нас рекламодавців).
Які пункти можуть говорити про це?
- Vision Match (запущений березень 2025) — AI генерує зображення і шукає "visually similar shoppable products"
- Google's shopping assistant може аналізувати і інтерпретувати зображення, використовуючи візуальні дані для матчингу продуктів — це називається visual search або image recognition
- Сучасна AI-пошукова система у 3 шарах: detection (знаходить об'єкти і атрибути — "dress, floral, sleeveless"), matching (порівнює з каталогом), ranking
- Ризик: візуальний пошук не розрізняє оригінальні продукти від lookalikes. Результати можуть включати counterfeit listings або дешеві "dupe" продукти які візуально нагадують item
👍8❤7🔥4🤝2
Бачимо такі запити як "круасани оптом", "журавлина посадка", "діловодство в ЗСУ" — алгоритм підмішує товари, які не мають жодного відношення до фіду (а продаємо ми взагалі канцелярію)
📌PMax не «збожеволів». Він робить свою роботу
PMax — це не Search 2014-го. Він вміє доганяти людину, яка вже була на сайті. Зайшла, переглянула, пішла. Через два дні гуглить «журавлина посадка» — бо дача, весна, життя триває. Алгоритм її впізнає і показує ваше оголошення.
Це не помилка. Це ремаркетинг по людині, а не по запиту. Архітектурно PMax змішує Search, Display, YouTube, Gmail, Discover і ремаркетинг в один котел. SQR показує вам хвіст цього котла. Ви дивитесь на хвіст і робите висновки про котел цілком. Це помилка інструменту аналізу, а не алгоритму.
📌Низький ROAS — це не вирок конкретного запиту
Запит «купити кросівки» → ROAS 1.5 → виписуємо в червоне → ріжемо.
Стоп. Це нормальний цільовий запит. Просто людина на ранньому етапі — порівнює, читає відгуки. Повернеться через тиждень з конкретною моделлю — і конверсія зарахується вже іншому запиту.
Ви оплатили вхід у воронку. Потім вирубали цей вхід, бо «не окупається». Через місяць — *«незрозуміло чому впали брендові»*. Зрозуміло чому.
📌Як читати SQR по нормальному
Три кроки. В такому порядку.
*Крок 1. Відсіяти за обсягом.* Один клік з ROAS 0 — це шум, випадковість, погода. Не варто витрачати 30 хвилин життя на аналіз одного кліка. Рівень значущості — від 6+ кліків, краще 20+.
*Крок 2. Розділити за наміром.* Генерики («купити [категорія]») — це upper-funnel. Вони роблять ваші брендові запити через два тижні. Конкретика («[модель] купити») — це low-funnel, тут ви маєте право вимагати ROAS. Назви конкурентів — окрема категорія, рішення залежить від стратегії.
*Крок 3. Дивитись на assist, не тільки на last-click.* GA4, Path Exploration, роль «помічника». Якщо запит системно відкриває ланцюжок, який закривається в іншому місці — він заробляє. Просто не в тій графі звіту, в яку ви дивитесь.
**Картинка нижче — реальний акаунт, 15 місяців**
— 84% «запитів» — покази без кліків. Бюджет нуль. Це фон.
— 64% грошей — у запитах з 6+ кліками. Ось де реальні рішення.
— 332 топ-запити дають ROAS 11. Золотий хвіст, який ніхто не помічає, бо всі дивляться на круасани.
Що різати МОЖНА (бо зараз будете питати)
Щоб не було враження, що я захищаю все підряд.
Правдиві червоні прапорці: запити з 50+ кліками і 0 конверсій, включно з assist; тематично нерелевантні без жодного зв'язку з нішею (не «людина була раніше на сайті» — а реальний лівий трафік); бренди конкурентів, якщо ви не хочете за них платити. Це ріжете — без рефлексії.
Решту — розбираєте за алгоритмом вище.
Підсумок
Аудит — це не «знайди все смішне і вимкни». Це робота зрозуміти систему, перш ніж її ламати.
«Вимкнути все дивне» звучить як рішення. Виглядає як рішення. Не є рішення.
Рішення — вище.
📌PMax не «збожеволів». Він робить свою роботу
PMax — це не Search 2014-го. Він вміє доганяти людину, яка вже була на сайті. Зайшла, переглянула, пішла. Через два дні гуглить «журавлина посадка» — бо дача, весна, життя триває. Алгоритм її впізнає і показує ваше оголошення.
Це не помилка. Це ремаркетинг по людині, а не по запиту. Архітектурно PMax змішує Search, Display, YouTube, Gmail, Discover і ремаркетинг в один котел. SQR показує вам хвіст цього котла. Ви дивитесь на хвіст і робите висновки про котел цілком. Це помилка інструменту аналізу, а не алгоритму.
📌Низький ROAS — це не вирок конкретного запиту
Запит «купити кросівки» → ROAS 1.5 → виписуємо в червоне → ріжемо.
Стоп. Це нормальний цільовий запит. Просто людина на ранньому етапі — порівнює, читає відгуки. Повернеться через тиждень з конкретною моделлю — і конверсія зарахується вже іншому запиту.
Ви оплатили вхід у воронку. Потім вирубали цей вхід, бо «не окупається». Через місяць — *«незрозуміло чому впали брендові»*. Зрозуміло чому.
📌Як читати SQR по нормальному
Три кроки. В такому порядку.
*Крок 1. Відсіяти за обсягом.* Один клік з ROAS 0 — це шум, випадковість, погода. Не варто витрачати 30 хвилин життя на аналіз одного кліка. Рівень значущості — від 6+ кліків, краще 20+.
*Крок 2. Розділити за наміром.* Генерики («купити [категорія]») — це upper-funnel. Вони роблять ваші брендові запити через два тижні. Конкретика («[модель] купити») — це low-funnel, тут ви маєте право вимагати ROAS. Назви конкурентів — окрема категорія, рішення залежить від стратегії.
*Крок 3. Дивитись на assist, не тільки на last-click.* GA4, Path Exploration, роль «помічника». Якщо запит системно відкриває ланцюжок, який закривається в іншому місці — він заробляє. Просто не в тій графі звіту, в яку ви дивитесь.
**Картинка нижче — реальний акаунт, 15 місяців**
— 84% «запитів» — покази без кліків. Бюджет нуль. Це фон.
— 64% грошей — у запитах з 6+ кліками. Ось де реальні рішення.
— 332 топ-запити дають ROAS 11. Золотий хвіст, який ніхто не помічає, бо всі дивляться на круасани.
Що різати МОЖНА (бо зараз будете питати)
Щоб не було враження, що я захищаю все підряд.
Правдиві червоні прапорці: запити з 50+ кліками і 0 конверсій, включно з assist; тематично нерелевантні без жодного зв'язку з нішею (не «людина була раніше на сайті» — а реальний лівий трафік); бренди конкурентів, якщо ви не хочете за них платити. Це ріжете — без рефлексії.
Решту — розбираєте за алгоритмом вище.
Підсумок
Аудит — це не «знайди все смішне і вимкни». Це робота зрозуміти систему, перш ніж її ламати.
«Вимкнути все дивне» звучить як рішення. Виглядає як рішення. Не є рішення.
Рішення — вище.
🔥21❤7👍4😁2
Ось реальні дані за 15 місяців по проекту що вище описала. Читай вище - там корисне
І це не проблема - це просто відображення масштабу реальної роботи АІ в середині вашого кабінету.
Ваш пмакс реально працює в глибину і знаходить багато запитів, які вводять один раз і все. І круасани/журавлина ввійшли якраз в той сегмент без кліків.
П.С. Хвичайно це лише аналіз по тим запитам, що видно - бо частину гугл приховує від вас
Для самоосвіти рекомендую моє відео до перегляду на цю тему Конкуренція між пошуком і пмаксом
АЛЕ - друзі - тут пмакс такий хАроший - бо над ним ми працюємо - у вас може бути інша ситуація
Уточнюйте у своїх спеців а шо там з трафіком у нас
І це не проблема - це просто відображення масштабу реальної роботи АІ в середині вашого кабінету.
Ваш пмакс реально працює в глибину і знаходить багато запитів, які вводять один раз і все. І круасани/журавлина ввійшли якраз в той сегмент без кліків.
П.С. Хвичайно це лише аналіз по тим запитам, що видно - бо частину гугл приховує від вас
Для самоосвіти рекомендую моє відео до перегляду на цю тему Конкуренція між пошуком і пмаксом
АЛЕ - друзі - тут пмакс такий хАроший - бо над ним ми працюємо - у вас може бути інша ситуація
Уточнюйте у своїх спеців а шо там з трафіком у нас
🔥9❤6👍3
Скільки конверсій на місяць має робити кампанія, щоб ви назвали її зрілою — тобто готовою для tROAS, скейлу і агресивних бюджетів?
Final Results
24%
30+/- конв/міс
35%
50+/- конв/міс
24%
100+/- конв/міс
17%
250+/- конв/міс
👍7🤔2
Дякую всім, хто проголосував 🙌
Скільки конверсій на місяць має робити кампанія, щоб її можна було назвати зрілою?
Результат:
▫️ 24% — 30+ конв/міс
▫️ 35% — 50+ конв/міс ← найпоширеніша
▫️ 24% — 100+ конв/міс
▫️ 17% — 250+ конв/міс
Найпопулярніша відповідь — 50+ конверсій на місяць.
І це дуже показово.
Бо саме десь у цій зоні в голові часто з’являється відчуття:
«окей, кампанія вже не сира».
Її можна скейлити. Їй можна довіряти tROAS. Їй можна давати більше бюджету. Її можна вважати такою, що вже набрала достатньо даних.
Я теж довго дивилась на це приблизно так.
А потім вирішила перевірити цю логіку на реальних PMax-даних.
─────
📊 У дослідженні було:
▫️ 131 кампанія
▫️ 16 місяців історії
▫️ 3,78 млн рядків даних
▫️ 198 тис. конверсій
І перша цифра, яку я побачила, була неприємною:
🔻 95% кампаній, які вже проходили умовний поріг «зрілості», потім мали падіння на 50% і більше.
Не кампанії без даних.
Не кампанії, які «ще не навчилися».
Не кампанії з короткою історією.
А кампанії, які вже виглядали дорослими.
Одна з них 16 місяців трималась з медіаною 306 конверсій на місяць.
Зараз — 4 конверсії на тиждень.
І після цього питання «скільки конверсій потрібно для зрілості PMax» починає звучати трохи небезпечно.
Бо, можливо, кількість конверсій — це не ознака зрілості. А просто метрика, яка дуже добре маскує майбутню нестабільність.
─────
Виявилось, кампанії помирають не тоді, коли в них падають конверсії.
А набагато раніше — задовго до того, як це стає видно в інтерфейсі.
Сама смерть — це лише фінальний кадр. Цікавим є те, що було перед ним.
Що саме я побачила в даних — покажу в наступному пості.
Там уже буде повний розбір і посилання на статтю.
. . .
💬 P.S. Якщо у вас були PMax, які довго працювали нормально, а потім раптом просідали без очевидної причини — напишіть в коментарях. Мені цікаво, чи збігаються ваші кейси з тим, що показали дані.
Скільки конверсій на місяць має робити кампанія, щоб її можна було назвати зрілою?
Результат:
▫️ 24% — 30+ конв/міс
▫️ 35% — 50+ конв/міс ← найпоширеніша
▫️ 24% — 100+ конв/міс
▫️ 17% — 250+ конв/міс
Найпопулярніша відповідь — 50+ конверсій на місяць.
І це дуже показово.
Бо саме десь у цій зоні в голові часто з’являється відчуття:
«окей, кампанія вже не сира».
Її можна скейлити. Їй можна довіряти tROAS. Їй можна давати більше бюджету. Її можна вважати такою, що вже набрала достатньо даних.
Я теж довго дивилась на це приблизно так.
А потім вирішила перевірити цю логіку на реальних PMax-даних.
─────
📊 У дослідженні було:
▫️ 131 кампанія
▫️ 16 місяців історії
▫️ 3,78 млн рядків даних
▫️ 198 тис. конверсій
І перша цифра, яку я побачила, була неприємною:
🔻 95% кампаній, які вже проходили умовний поріг «зрілості», потім мали падіння на 50% і більше.
Не кампанії без даних.
Не кампанії, які «ще не навчилися».
Не кампанії з короткою історією.
А кампанії, які вже виглядали дорослими.
Одна з них 16 місяців трималась з медіаною 306 конверсій на місяць.
Зараз — 4 конверсії на тиждень.
І після цього питання «скільки конверсій потрібно для зрілості PMax» починає звучати трохи небезпечно.
Бо, можливо, кількість конверсій — це не ознака зрілості. А просто метрика, яка дуже добре маскує майбутню нестабільність.
─────
Виявилось, кампанії помирають не тоді, коли в них падають конверсії.
А набагато раніше — задовго до того, як це стає видно в інтерфейсі.
Сама смерть — це лише фінальний кадр. Цікавим є те, що було перед ним.
Що саме я побачила в даних — покажу в наступному пості.
Там уже буде повний розбір і посилання на статтю.
. . .
💬 P.S. Якщо у вас були PMax, які довго працювали нормально, а потім раптом просідали без очевидної причини — напишіть в коментарях. Мені цікаво, чи збігаються ваші кейси з тим, що показали дані.
❤28👍9🤔4🔥1
Дослідження вийшло.
«50+ конверсій на місяць» — це не зрілість PMax-кампанії. Це поріг навчання Smart Bidding. А зрілість — щось зовсім інше.
Ось що в дослідженні:
▫️ Аналіз 131 PMax-кампанії за 16 місяців
▫️ 198 тис. конверсій, 3.78 млн рядків даних
▫️ Класифікація 112 падінь на три типи — системні (68%), структурні (20%), контекстні (4%)
▫️ 6 кейсів — від кампанії, що 16 місяців жила з медіаною 306 conv/міс, до сезонного піку, який згорів за 2 тижні
▫️ Метод діагностики власних кампаній за 15 хвилин — без BigQuery, без коду
▫️ Що робити з кожним типом падіння — окремо, бо лікувати треба по-різному
Я назвала цю діагностичну рамку PMax Crash Classification (PCC) — щоб мати на що посилатися в наступних дослідженнях і у вашій практиці.
─────
Найважливіше, що я зрозуміла за ці 16 місяців:
Більшість падінь PMax-кампаній — передбачувані. Не «магія алгоритму». Не «погана сесія». Кампанії помирають за два-три тижні до того, як це стає видно в звіті — і той сигнал можна побачити, якщо дивитися в правильне місце.
Куди саме дивитися — у статті.
📖 Читати тут:
https://adwservice.com.ua/uk/pmax-50-conv-obman
─────
💬 Якщо знайдете цікаві патерни на власному акаунті — пишіть в коментарях або в особисті. Збираю кейси для наступного дослідження — хочу перевірити, чи розподіл 68/20/4 утримується на ширшій вибірці акаунтів.
Дякую всім, хто був з цим дослідженням від першого опитування.
«50+ конверсій на місяць» — це не зрілість PMax-кампанії. Це поріг навчання Smart Bidding. А зрілість — щось зовсім інше.
Ось що в дослідженні:
▫️ Аналіз 131 PMax-кампанії за 16 місяців
▫️ 198 тис. конверсій, 3.78 млн рядків даних
▫️ Класифікація 112 падінь на три типи — системні (68%), структурні (20%), контекстні (4%)
▫️ 6 кейсів — від кампанії, що 16 місяців жила з медіаною 306 conv/міс, до сезонного піку, який згорів за 2 тижні
▫️ Метод діагностики власних кампаній за 15 хвилин — без BigQuery, без коду
▫️ Що робити з кожним типом падіння — окремо, бо лікувати треба по-різному
Я назвала цю діагностичну рамку PMax Crash Classification (PCC) — щоб мати на що посилатися в наступних дослідженнях і у вашій практиці.
─────
Найважливіше, що я зрозуміла за ці 16 місяців:
Більшість падінь PMax-кампаній — передбачувані. Не «магія алгоритму». Не «погана сесія». Кампанії помирають за два-три тижні до того, як це стає видно в звіті — і той сигнал можна побачити, якщо дивитися в правильне місце.
Куди саме дивитися — у статті.
📖 Читати тут:
https://adwservice.com.ua/uk/pmax-50-conv-obman
─────
💬 Якщо знайдете цікаві патерни на власному акаунті — пишіть в коментарях або в особисті. Збираю кейси для наступного дослідження — хочу перевірити, чи розподіл 68/20/4 утримується на ширшій вибірці акаунтів.
Дякую всім, хто був з цим дослідженням від першого опитування.
🔥21👎3🤯3👍2❤1