Проблеми рекламного акаунта часто спричиняє не погане середовище, а його постійні зміни. Дані акаунта й оплати мають бути стабільними, місця входу — зрозумілими, дії команди — зафіксованими, а перемикання — обмеженими.
Коли агенція керує десятками або навіть сотнями акаунтів рекламодавців, найбільший страх полягає не в тому, що не вдасться масштабувати обсяг. Небезпечніше, коли проблема одного акаунта тягне за собою цілий ланцюжок інших. Втрачається не лише бюджет, а й довіра клієнта до здатності агенції виконувати роботу.
Багато хто зосереджується на якості середовища: чи достатньо природно виглядає fingerprint, чи чиста IP-адреса. Ці показники важливі, але в Media Buy найчастіші проблеми нерідко виникають з інших причин.
Дані акаунта й платіжна інформація мають залишатися узгодженими в довгостроковій перспективі
Рекламна платформа оцінює акаунт не лише за пристроєм, з якого виконується вхід. Вона також дивиться, чи стабільні бізнес-дані, що стоять за акаунтом: власник, прив’язаний спосіб оплати, платіжні реквізити й контактна інформація. Якщо ці дані тривалий час залишаються узгодженими, історія акаунта виглядає для платформи зрозумілою. Часті зміни, особливо раптовий перехід з однієї платіжної схеми на іншу, можуть легко спричинити ручну перевірку.
Є ще один момент, який часто недооцінюють: якщо кілька акаунтів використовують одну картку або однакові платіжні дані, платформа може розглядати їх як пов’язані. Коли агенція веде кампанії для різних рекламодавців, платіжна інформація має бути розділена для кожного з них. Це підтримує відповідність вимогам і зменшує ризик взаємного впливу непов’язаних акаунтів.
Місце входу має бути логічно пояснюваним
Якщо акаунт, що працює на ринок США, протягом тривалого часу входить із регіону, який не має стосунку до бізнесу, такий шаблон потребує пояснення. Платформа не обов’язково заблокує акаунт лише через це, але може додати сигнал до історії ризику й повернутися до нього, якщо пізніше виникне інша проблема з поведінкою або контентом.
Раціональніше підтримувати зрозумілий зв’язок між місцем входу та ринком кампанії. Якщо акаунт здебільшого орієнтований на один ринок, вихід для входу за можливості має бути близьким до цього ринку. Якщо команда працює з різних міст, цей зв’язок потрібно продумати заздалегідь, а не виправляти після появи проблеми.
Командна робота ускладнюється, коли ніхто не може пояснити, що сталося
В агенціях завдання зазвичай ділять за функціями: хтось створює акаунти й займається онбордингом, хтось оптимізує креативи та ставки, а хтось відповідає за лендинги. Якщо всі використовують одне середовище, проблеми найчастіше зосереджуються у трьох місцях:
- Хтось змінює ставку або цільовий регіон, а потім ніхто не знає, хто саме це зробив
- Нотатки середовища або налаштування proxy перезаписуються, і дані під час передачі роботи вже не збігаються
- Коли в акаунта виникає проблема, незрозуміло, чи відповідальність лежить на етапі налаштування, чи на етапі оптимізації
Рольові права доступу розв’язують значну частину цих проблем. Роль налаштування може створювати середовища, прив’язувати IP і вводити дані для відкриття акаунта. Роль оптимізації може змінювати креативи та ставки, але не параметри середовища, такі як IP чи часовий пояс. Відповідальний працівник бачить усі середовища й журнали операцій. Окрім прав доступу, ще важливіше зберігати історію дій. Має бути видно, хто, коли й у яке середовище входив, а також які параметри змінював. У невеликій команді це може здаватися зайвим, але при одночасній роботі з кількома клієнтами без журналу важко чітко визначити відповідальність.
Часті зміни середовища можуть бути ризикованішими, ніж посереднє середовище
Це найменш очевидний пункт. Середовище звичайної якості, яке залишається незмінним, зазвичай безпечніше, ніж добре налаштоване середовище, де кожні кілька днів змінюються IP, пристрій або часовий пояс.
Причина в тому, що під час оцінювання ризику платформи дивляться на зміни. Якщо один і той самий акаунт за короткий час постійно переміщується між місцями входу або щоразу показує інші характеристики пристрою, такі відмінності стають аномаліями в історії. Натомість стабільне середовище, навіть зі звичайною резидентською IP-адресою, дає платформі менше причин для додаткової уваги.
Тому стратегія середовища має насамперед мінімізувати зайві зміни. Після прив’язки акаунта до середовища не варто переносити його без чіткої причини. IP слід змінювати лише за наявності конкретної підстави, наприклад якщо початковий вузол перестав працювати, а не регулярно лише заради «чистішої» адреси. Під час роботи кількох людей не варто по черзі входити в один і той самий акаунт із пристроїв різних членів команди.
Як реалізувати це на практиці
- Створюйте середовища за клієнтом і платформою, використовуйте єдиний формат назв, наприклад платформа, клієнт і регіон, та керуйте ними групами. Коли середовищ стає багато, стандарт іменування стає необхідним.
- Для кожного акаунта на одній платформі використовуйте окреме середовище, налаштовуйте різні fingerprint і повністю ізолюйте cookies та локальне сховище. PurpleMark надає саме таку ізоляцію: на одному комп’ютері можна керувати сотнями середовищ без спільного використання даних входу чи даних середовища.
- Перед запуском перегляньте креативи з середовища цільового регіону й перевірте заборонені формулювання та відповідність місцевим звичкам, щоб зменшити ризик відхилення після старту.
- У нотатках середовища вкажіть прив’язану IP-адресу, призначення акаунта й відповідальну особу, щоб спростити передачу роботи та пошук проблем.
Сам акаунт усе одно має відповідати правилам
Ізоляція середовища зменшує технічний взаємовплив між акаунтами. Вона не скасовує вимоги, щоб кожен акаунт відповідав політикам платформи. Вимоги до кваліфікації акаунта, креативів і лендингів не стають м’якшими лише через добре налаштоване середовище. Мета інфраструктури акаунтів — забезпечити стабільну роботу кількох легітимних акаунтів, а не щось інше.
Цей матеріал призначений лише для обміну досвідом керування акаунтами й не є рекомендацією щодо кампаній або доходів.
