Время, когда для прохождения модерации в Google Ads достаточно было создать за 30 мин простой одностраничный сайт, к сожалению, давно прошло. Сейчас алгоритмы оценивают не только контет насыщение, но и всю техническую составляющую.

Фактически на текущий момент Whitepage - это одна из ключевых составляющих сетапа, от которой непосредственно зависит срок жизни аккаунта и его результативность.

Поэтому в этой статье мы постараемся детально рассказать о нашей логике работы с вайтами, отталкиваясь от положительного и негативного опыта.

CMS против чистого HTML

Выбор платформы - тема, в которой споры никогда не заканчиваются.

WordPress.

Многие склоняются к мнению, что если сайт создан на популярной CMS вроде WordPress, то в таком случае Google будет больше доверять ему.

Массово тестировали эту теорию в различных сетапах: прямой корреляции/связи между движком и сроком жизни аккаунта вовсе не заметили.

Но во время работы с WordPress могут появляться некоторые осложнения:

• Конфликты: кэширование WP и его особенности часто ломают скрипты клоакинга и кастомные in-house скрипты, что выливается в проблемы с автоматизацией и необходимости лезть в ядро WP либо ставить множество различных плагинов, тем самым раздувая код.

Чистый HTML и ИИ

Для личных целей и задач мы используем только чистый HTML.
Главная причина - уникальность и вариативность интеграций.

Вайты, которые реализованы с помощью различных шаблонов, рано или поздно начинают детектиться со стороны Google и получать баны на этапе модерации кампании. Дабы избежать данной проблемы, мы используем Claude Code -с целью верстки и реализации уникального кода на каждом вайте.

Также это позволяет нам без каких-либо проблем интегрировать любые скрипты и прочие технические решения на наши вайты.

Домены, хостинг и проверка истории

Это самые базовые составляющие, которым в первую очередь нужно уделять внимание.

Регистрация и аудит доменов.

Мы закупаем домены через Regway, но перед покупкой каждый домен проверяем через Web Archive (Wayback Machine).

Если раньше на домене находился гемблинг, серые крипто-офферы или дорвеи - пропускаем.

Любая негативная история домена сводит практически к нулю все попытки создания качественного Whitepage.

Серверы.

В качестве проверенного хостинга мы выбираем пулы от Yotta SRC. ( Адекватная цена и качество )

Cloudflare.

Присутствует множество мнений касаемо Cloudflare, но фактически это лишь часть пазла, которая как уникальная единица не имеет весомого влияния на конечную результативность.

Google отлично видит, что сайт работает через CDN, и воспринимает это как норму, а не как повод доверять вам больше.

Единственное, для чего мы используем Cloudflare, дабы скрыть реальный IP-адрес сервера и отсеять самых примитивных ботов. В том числе базовая защита от скликивания.

Используйте CDN для защиты серверов, а не с целью получить больше траста.

Релевантность: Search против Demand Gen

Релевантность вайта относительно целевого оффера один из весомых факторов, на который тоже необходимо обратить внимание в определенных типах кампаний.

Например:

• Поиск: пользователь вводит конкретный запрос, и Google хочет показать ему логичный ответ. Если в объявлении мы говорим про финансы, а на сайте история керамики, алгоритм сразу видит обман. Итог: низкий Trust Score и бан.

Для запуска поиска мы всегда создаем сайты, которые максимально соответствуют офферу, данный сетап показывает себя наилучшим образом в рамках жизни аккаунта и открута.

• Demand Gen: в данном случае человек не ищет ваш продукт целенаправленно, он просто потребляет контент.

Главная задача сайта - не триггерить бота. Для таких кампаний отсутствие запрещенного контента важнее идеального совпадения с креативом. Нейтральный, технически чистый сайт работает лучше, чем попытка натянуть серый оффер на релевантный ленд.

Чек-лист

В этом разделе напишем основные критерии, которых придерживаемся при создании вайтов.

• Юр.составляющая: обязательно наличие всех политик под необходимую юрисдикцию - Privacy Policy, Terms of Service, Cookie Policy, Refund Policy, Affiliate Disclosure. (В зависимости от вашего оффера могут добавляться уникальные политики)
• Доп.уникальные метатеги: title, description, OG/X, canonical, hreflanf. Штатно добавляем на уровне привычки, так сказать. Но фактически можно избегать данного пункта.

• Consent v2: сейчас это просто стандарт. Если вы собираете данные без согласия пользователя, траст сайта падает моментально. (Если нет желаения/возможности писать кастомные скрипты, можно использовать готовые решение. К примеру, Cookie Bot)
• Микроразметка Schema.org + sitemap.xml: разметка JSON-LD под тип страницы (Organization, Review, Article, FAQPage, BreadcrumbList). Помогает Google понять, что за компания перед ним, где она находится и как с ней связаться.
• Google Search Console: подключаем GSC для Search-кампаний. (Не считаем, что это значительно увеличивает траст, подключаем для дополнительной аналитики в большинстве случаев).
• Интеграция Google сервисов: Cookiesbot + Consent Mode v2, reCAPTCHA v 3 на формах, Google Analytics 4, Google Maps (реальный адрес, телефон в футере и на странице контактов)

• Рабочая форма обратной связи: форма должна фактически отправлять данные и перекидывать человека на страницу "Спасибо".
• Понятная монетизация: В обязательном порядке интегрируем понятную и прозрачную модель монетизации бизнеса, с чего зарабатывает данный сайт.

Дополнительный критерии:

• Многостраничность (от 10 страниц): Минимум 10 контентных страниц .
• Отсутствие заглушек: все ссылки в меню и соцсетях должны вести на реальные внутренние страницы («"О нас", "Вакансии") или профили.
• Скорость (Core Web Vitals): не перегружаем сайт лишними скриптами, медленная скорость загрузки сайта - плохой пользовательский опыт по мнению Google.

Возможное будущее клоакинга: Edge-фильтрация и гибридный подход

Мы придерживаемся позиции, что время классического клоакинга через тяжелые PHP-скрипты постепенно уходит.

Алгоритмы Google все лучше вычисляют задержки ответа, странные HTTP-заголовки и серверные редиректы, в том числе начинают проксировать IP юзеров через свои серверы.

Вполне возможно, что новым стандартом станет Edge-фильтрация (на уровне DNS). В этой модели фильтрация происходит на уровне CDN - максимально близко к пользователю. Запрос проверяется еще до того, как дойдет до вашего сервера.

Варианты заполнения могут быть разными, к сожалению, описать все возможные примеры мы не можем, в силу того, что модель подачи зависит от многих динамических данных: тип аккаунта, предмет подачи (вайт, видео и т.д.).

Но для прогревочных YouTube-кампаний есть достаточно универсальный вариант подачи BOV, который в наших сетапах показывает хорошую проходимость на данный момент.

📋 Рассмотрим детальную инструкцию по которой мы подаем BOV :

◻️ Вопросы 1–2

В зависимости от того, что заливаем - вставляем ссылку либо на вайт, либо на YouTube-видео.

В данном примере мы заполняем апелляцию на аккаунте физ.лица, который был запущен на YouTube-видео.

◻️ Вопросы 3–5

Вопросы 3-5 всегда заполняем шаблонно.

В поле Legal Name в зависимости от типа аккаунта вставляем:

• ФИО физ. лица
• либо название организации

◻️ Вопросы 6–11

Вопросы 6-11 также заполняем шаблонно, используя данные:

• физ. лица
• либо юридического лица

В ячейках 6-7 вводим одинаковые данные.

◻️ Вопросы 12–14

В этой части необходимо при подачи придерживаемся определенных критериев:

• в текстах не должно быть обобщенных формулировок
• необходимо объяснить тип вашего бизнеса, бизнес-модель/модель заработка, в каких лидов мы таргетимся.

При подаче BOV через YouTube

Мы всегда указываем, что:

• хотим подключить монетизацию на свой канал и зарабатывать с него, рекламная кампания направлена на увеличение подписчиков, охватов и т.д.

📌 Пример ответа на вопрос 12

📌 Пример ответа на вопрос 13

📌 Пример ответа на вопрос 14

◻️ Вопрос 15

Мы сохраняем конкретные формулировки и полноту предоставляемой информации.

📌 Пример ответа на вопрос 15

◻️ Вопрос 16

Всегда шаблонно отвечаем: First party

Именно данный вариант показывает лучшую проходимость.

◻️ Вопрос 16.1

Мы всегда выбираем ответ:

No, we are a first party, and do not subcontract for the delivery of goods/services.

◻️ Вопрос 16.2

Все зависит от типа компании и куда заливаем.

В случае запуска кампании на YouTube

Загружаем скриншот из админ-панели, где должно быть видно:

• видео, на которое была запущена прогревочная рекламная кампания

Скриншот должен подтверждать, что у вас есть доступ к каналу и вы управляете этим контентом.

В случае подачи на вайты

Загружаем следующие документы:

• Аккаунт на физ.лицо: инвойс
• Аккаунт на организацию: любой уставной документ
• Агентские аккаунты: отрисованный уставной документ
• запрашиваем у владельца кредитлайна сайт компании
• используем данные с сайта для отрисовки документа

◻️ Вопрос 17

Шаблонно отвечаем: нет

◻️ Вопрос 18

Также отвечаем: нет

В наших тестах, когда мы заполняли от лица аффилейта, проходимость была существенно ниже.

◻️ Вопрос 18.1

Отвечаем: нет

◻️ Вопрос 18.2

Отвечаем: нет

◻️ Вопрос 19

Предоставляем конкретизированный ответ, без обобщения.

Ниже пример текста, который мы загружаем при подаче на YouTube:

◻️ Вопросы 20–21

Не так важны, но в основном указываем, что делаем все самостоятельно.

◻️ Вопросы 22–24

Ответы всегда статические, паттерн ответов не меняется.

◻️ Вопрос 25

При заполнении указываем:

• ФИО (в случае физ.аккаунта)
• либо название организации (если аккаунт зарегистрирован на юр.лицо)

Пример ответа:

◻️ Вопрос 26

Всегда отвечаем:

No additional licensing is required.

◻️ Вопрос 27

На некоторых аккаунтах не заполняем, но если подаем апелляцию после отклона - обязательно заполняем.

Если подаем на вайт

• Текста должны соответствовать, тому что написано у нас на вайте в Privacy policy.

📌 Пример ответа при подаче на YouTube:

Также если мы подаем на вайт, указываем ссылку на Privacy policy.

◻️ Вопрос 28

Мы загружаем инвойс. Это не обязательно при подаче через YouTube, так как и без этого проходимость достаточно хорошая.

В зависимости от типа аккаунта мы загружаем различные документы:

• Аккаунты на физ.лица: дублируем инвойс из вопроса 16.2
• Аккаунты на юр.лица: документы о владельцах компании, либо другой уставной документ
• Агентские: дублируем отрисовку из вопроса 16.2, либо делаем дополнительный уставной документ

◻️ Вопрос 29

Всегда детально описываем ситуацию, склоняя, что это False Positive срабатывание алгоритма.

📌 Пример ответа:

📞 Контакты

• Менеджер: koya.ads | manager
• Поддержка: koya.ads | support
• Телеграмм канал: koya.ads | channel

Добрый день!

Сегодня мы хотим обсудить и поделиться нашими решениями по прохождению достаточно частой верификации в Google Ads - BOV (Business Operations Verification)

Мы используем несколько способов прохождения BOV.

В этой статье мы опишем те методы, которые хорошо отрабатывают на практике и показывают высокую проходимость в наших сетапах.

📑 В статье разберем:

• универсальный способ прохождения BOV для всех типов аккаунтов
• прохождение BOV на аккаунтах, созданных на физических лиц
• прохождение BOV на аккаунтах, созданных на юридические лица
• прохождение BOV на агентских аккаунтах

1. Универсальный способ прохождения BOV (для всех типов аккаунтов)

👨‍💻 Шаги

1. Регистрируем YouTube-аккаунт на любую почту, к которой у вас есть полный доступ.
2. Загружаем на канал любое видео без авторских прав.
3. Запускаем рекламную кампанию на это видео. Достаточно потратить 2-3$ рекламного бюджета.
4. После этого можно переходить к прохождению BOV.

📨 Если аккаунт не вышел на BOV самостоятельно, мы можем пройти его принудительно, воспользовавшись данной формой:

📝 Как заполняем форму

Мы используем стандартный сценарий:

• указываем, что запускаем рекламу для привлечения подписчиков на наш YouTube-канал;
• в поле загрузки документов загружаем скриншот из админ-панели нашего YouTube-канала, где видно опубликованное видео.

Данный способ довольно простой в реализации и показывает хорошую проходимость.

Тажке мы подготовили отдельный мануал, в котором пошагово и детально разобрали каждый этап при заполнении BOV.

2. Прохождение BOV на аккаунтах, созданных на физическое лицо

Дабы пройти BOV на аккаунтах физических лиц, на нашем вайте нам необходимо разместить информацию о физическом лице, на которое мы проходили верификацию.

ФИО будет достаточно. Добавляем его как партнера бизнеса на любую из страниц нашего вайта.

Далее стандартно проходим BOV с помощью любой нейросети.

🖥 Документы для подтверждения

Мы используем:

• Invoice (счет на оплату услуг)
• договор между компанией (нашим сайтом) и физическим лицом, на которое зарегистрирован рекламный аккаунт.
  

Цель документа - подтвердить связь физического лица с бизнесом.

Если используется Invoice:

• отправителем должна быть компания (наш сайт)
• получателем - физическое лицо, на которое была пройдена верификация аккаунта.

3. Прохождение BOV на аккаунтах юридических лиц

Для аккаунтов, зарегистрированных на юридические лица, необходимо разместить на сайте информацию о компании, на которую был зарегистрирован рекламный аккаунт.

Мы проходим BOV как владелец бизнеса.

В целом, по Tier-1 гео документы юридических лиц находятся в открытом доступе.

📬 Для прохождения верификации мы используем:

• уставные документы
• документы учредителей бизнеса

4. Прохождение BOV на агентских аккаунтах

На агентских аккаунтах BOV обычно проходится проще всего.

У оператора агентских аккаунтов должен быть сайт компании, которая является владельцем кредитной линии.

Необходимо запросить данный сайт. На нем в обязательном порядке будет расположена юридическая информация и контакты компании.

Скопируйте и разместите их у себя на сайте и проходите BOV по ним.

Документы

В качестве документов можно использовать те же документы, что и на юридических лицах:

• уставные документы
• документы учредителей бизнеса

Либо использовать отрисованные документы на основе данных с сайта компании (владельца кредитной линии).

📞 Контакты

• Менеджер: koya.ads | manager
• Поддержка: koya.ads | support
• Телеграмм канал: koya.ads | channel

📸 Фото-верификация банковской карты - один из дополнительных этапов проверки платёжного метода в Google Ads.

На большинстве гео это не массовая проблема, однако в отдельных странах частота запроса фото-подтверждения достигает 80–90%.

📌 Где проблема появляется чаще всего

Локализируя перечень гео, отдельно выделим гео Аргентина.

При работе с аккаунтами, зарегистрированными на физическое лицо в данном гео, фото-верификация карты запрашивается значительно чаще среднего.

🚩 Факторы, повышающие вероятность фото-верификации карты

Отталкиваясь исключительно от практики, можно выделить три ключевых фактора:

• Гео аккаунта.
• БИН (BIN) банка-эмитента виртуальной карты.
• Платёжная сеть карты (VISA / Mastercard).

Если остановиться на гео Аргентина, то основные факторы, которые необходимо было менять:

• БИН банка-эмитента.
• Тип платёжной сети

Именно их сочетание напрямую повлияло на итоговый процент выхода на фото-верификацию.

❓ В чём заключалась основная проблема

Ранее прохождение фото-верификации не вызывало каких-либо затруднений.

Достаточно было:

• Использовать стандартную отрисовку карты.
• Загрузить скриншот карты из личного кабинета платёжного решения, в котором присутствует визуализация карты (к примеру, Flexcard);

Первый способ звучит достаточно абсурдно, но на практике он показывал хорошую проходимость.

Но в последнее время данные два способа попросту перестали работать в необходимых нам гео, независимо от способа работы с изображением.

❔ Что пробовали использовать?

На практике применялись следующие варианты:

• Отрисовка карт (разные гео, банки, тип сети, год выпуска и тд)
• Генерация изображений карт с подменой метаданных
• Скриншоты с изменением данных через «код элемента» различных платёжных решений

Результат во всех случаях оказался +- одинаковым - проходимость сводилась к нулю.

✅ Где оказалось фактическое решение

Решение оказалось там, где мы первоначально даже не думали искать - в типе сети карт.

На практике было выявлено:

• Фото-верификация системно появлялась на БИНах VISA в определённых гео, чего нельзя сказать о БИНах Mastercard.
• На БИНах Mastercard с похожей проблемой мы вовсе не сталкивались.

🖥 Практическое решение

Чтобы уйти от фото-верификации карты, необходимо было:

• Отвязать карту VISA из аккаунта.
• Перепривязать новую карту Mastercard через Google Payments (payments.google.com).
• Пройти стандартную верификацию карты - «принять миник».

При дальнейшей работе с данными аккаунтами мы повторно не сталкивались с подобной проблемой.

При реализации последующих паков аккаунтов гео Аргентины мы сразу использовали карты MasterCard, что сводило к нулю вылет на фото-верификацию.

Вполне возможно, что со временем данная ситуация изменится.

Добрый день, на связи команда koya.ads.

Сегодня мы хотели бы обсудить и предоставить готовое решение для одной из насущных проблем в Google ADS - «Видеоверификация».

Во многих популярных гео, например Британия и Испания, видеоверификация стала частой проблемой.

В этом мануале мы детально разберем данный процесс.

Сразу отметим: способов прохождения видеоверификации существует большое количество.

В этом материале мы разберем один конкретный вариант, который показывает хорошие результаты по проходимости в нашем сетапе.

Базовая подготовка

Для начала необходимо подготовить все, что потребуется для прохождения видеоверификации:

• Виртуальная камера с возможностью загрузки нескольких разных видео.
• Готовые видео для прохождения верификации.
• Антидетект с мобильными профилями или облачные телефоны.

Поэтапность и настройка

Виртуальная камера

На первом этапе необходимо корректно настроить виртуальную камеру, в которую мы загрузим несколько различных видео. Видео должно быть несколько, так как Google каждый раз просит поворачивать голову в разные стороны.

Решений на рынке достаточно много.

Среди самых популярных:

• OBS Studio
• Stream Labs
• Meld Studio
• StreamYard

После серии тестов мы остановились на OBS Studio.

При первом запуске OBS Studio мы выбираем пункт, что планируем использовать OBS только для виртуальной камеры.

Далее:

• Во вкладке «Источники» загружаем любое фото или видео.
• Запускаем виртуальную камеру.
• Переходим в антидетект и открываем профиль, на котором выпала видеоверификация.
• Переходим к тестированию камеры.

Сайты для тестирования камеры

Для проверки мы использовали следующие сервисы:

• https://ru.webcamtests.com/
• https://webcammictest.com/ru/
• https://webcamtest.net/
• https://www.onlinemictest.com/ru/webcam-test/

⚠ Важный момент
Необходимо в обязательном порядке проверить, чтобы камера не отображалась как OBS Virtual Cam.

Любой антидетект умеет фейковать устройства, поэтому нужно убедиться, что название камеры отображается иначе.

Если камера работает корректно, переходим к следующему этапу - генерации видео.

Генерация видео

Один из самых сложных этапов видеоверификации - качественная генерация видеоматериалов.

дин из самых сложных этапов видеоверификации - качественная генерация видеоматериалов.
В данном материале мы не будем рекомендовать одну конкретную модель для генерации видео.

Ниже приведен список нейросетей, с которыми мы работали и получали как положительные, так и отрицательные результаты:

• Sora 2 Pro
• Google Veo 3.1
• Wan 2.6
• Kling 2.6 Pro
• Seedance 1.5 Pro

Наш рабочий формат

С помощью любой ИИ для генерации фото мы апскейлим изображение с документа, на который ранее была пройдена верификация в аккаунте.

Сразу задаем:

• позу человека,
• фон
• видимые части тела

Полученную апскейл-генерацию пропускаем через одну из указанных выше нейросетей.

В итоге нам потребуется 5 видео с разными направлениями взгляда или поворотами головы:

• взгляд или поворот прямо в камеру
• взгляд или поворот вверх
• взгляд или поворот вниз
• взгляд или поворот вправо
• взгляд или поворот влево

На финальном этапе выгружаем все видео в OBS и называем их соответствующим образом, чтобы не путаться.

Далее переходим к заключающему этапу подготовки - создание мобильного профиля, использование облачного телефона.

Мобильные профили и облачные телефоны

Видеоверификацию можно пройти только с мобильного устройства.

Мы в большинстве случаев используем облачные телефоны, а не мобильные профили внутри антидетект-браузеров

Существует большое количество сервисов, предоставляющих облачные мобильные устройства. Что будет работать лучше - покажут только ваши индивидуальные тесты.

Часть сервисов по предоставлению облачных телефонов:

• VMOS Cloud
• Morelogin Cloud Phones
• Geelark

Также стоит учитывать, что большинство антидетект-браузеров поддерживают мобильные профили:

• OctoBrowser
• LinkenSphere
• Ads Power

⚠ В обязательном порядке при создании мобильного профиля или использовании облачного телефона необходимо установить тот же прокси, который использовался в основном профиле, где появился видеовериф.

Практическое применение

1. Заходим в OBS Studio.
2. В источниках выбираем видео, где человек смотрит прямо в камеру.
3. Включаем для него Loop эффект, чтобы видео проигрывалось бесконечно.
4. Делаем эту сцену первой, чтобы именно она транслировалась в виртуальную камеру.

После этого запускаем видео.

Запуск верификации

1. Открываем профиль, на котором запросило видеоверификацию.
2. Нажимаем «Пройти верификацию».
3. Копируем полученную ссылку.
4. Вставляем ее в мобильный профиль.

С мобильного профиля:

1. Логинимся в почту.
2. Нажимаем «Начать верификацию».

Далее:

• Далее:
  Выбираем тип документа, на который ранее проходили верификацию рекламодателя.
• Нажимаем «Далее».

Загружаем документы.

Сверяем ФИО и дату рождения с документом.

Прохождение видеоверификации

На этом этапе у вас уже запущено зацикленное видео с взглядом прямо.

Когда Google просит повернуть голову в определенную сторону:

1. В OBS Studio перетаскиваем нужное видео поверх текущего.
2. Нажимаем Play.
3. После завершения видео с поворотом головы автоматически снова запускается зацикленное видео с взглядом прямо.

На финальном этапе вы увидите бесконечную прогрузку страницы, которую Google просит не закрывать.

Возможные проблемы

❗Не всегда Google не пропускает/не подтверждает наше видео по причине плохой генерации.

Как показывает практика, в большинстве это связано с тем, что мы плохо изменили кадры и Google отчетливо видит, что это не live-трансляция с камеры, а статическое видео.

Если видеоверификация отклонена, мы повторно проходим ее, чтобы точно убедиться и определить истинную причину отказа.

Доброго времени суток!

Продолжая обсуждение насущной темы почт, в этот раз хотим затронуть и поделиться нашим опытом работы как с покупными, так и с саморег-почтами.

Расскажем о преимуществах, недостатках и проблемах, которые возникали у нас в процессе работы.

Ручная регистрация почт

Для реализации регистрации Gmail рассматривали только три варианта:

• Эмуляторы: Bluestacks, LD Player и т.д.
• Физические телефоны: Android, iPhone
• Виртуальные мобильные/облачные телефоны: Geelark, MoreLogin Cloud Phones, VMOS Cloud

При использовании антидетект-браузеров (OctoBrowser, Linken Sphere, AdsPower и т.д.), а также сервисов с облачными мобильными телефонами, мы с вероятностью 100% при регистрации получали вылет на QR Code.

В конечном итоге необходимо было сканировать QR и отправлять SMS на указанный номер телефона с указанным текстом.

Регистрация через эмуляторы

Дабы не дублировать информацию, напишем тезисно ключевые факторы, которые влияют на результативность:

• Качественные прокси
• Постоянное изменение параметров конфигураций:

1.1. Модель телефона.

1.2. Версия Android

                 1.3. Гео номеров

Важность прокси

При использовании некачественных прокси при регистрации почты с эмулятора, аккаунт будет уходить на дизейбл.

Бан крайне простой и снимается за день после подачи апелляции, но в таком случае вы теряете сутки в ожидании выхода аккаунта из бана.

Перенос аккаунтов в антидект-браузер

Для переноса аккаунтов Gmail в антидетект-браузер необходимо их прогревать.

В случае отсутствия прогрева почта с высокой вероятностью выпадет на холд 3 либо 7 дней, при котором вы не сможете запускать кампании в Google ADS.

Регистрация с физических телефонов

Регистрация с реальных физических телефонов является более эффективным, простым и быстрым способом.

На практике лучше всего показали себя iPhone, так как fingerprints на них одинаковые и нам не нужно ничего с ними делать.

Рабочий сетап

• iPhone с отключённой геолокацией
• Устройство подключено к модему с мобильной прокси в нужном гео
• При каждой новой регистрации - смена IP-адреса на модеме
• Включение и выключение режима полёта на телефоне
• Спустя 10–15 регистраций - полный сброс системы устройства с откатом версии на одну назад либо вперёд

При переносе данных почт в антидетект-браузер в 50% случаев для входа запрашивается уникальный номер телефона.

При регистрации почт с физических устройств - созданные аккаунты дофармливали от 5 дней.

Если этого не делать, вероятность блокировок и холдов в Google крайне высока.

Покупка Gmail

Последний вариант работы с почтами - их покупка.
Отталкиваясь от практического опыта и наших потребностей, мы пришли к единственному решению - старые покупные почты.

На это влияют различные факторы:

• Себестоимость (один уникальный номер на N-ное количество почт),
• Качество (старорег почты реальных пользователей)
• Наличие либо отсутствие необходимости в фарме.

Критерии подбора Gmail:

• Возраст почты - минимум от года отлёжки
• Отключена 2FA
• Подтверждены по SMS
• Почты реальных полтзователей (не автореги)

После подтверждения резервного адреса на почтах, которые соответствуют данным критериям, появляется следующее модальное окно:

Именно это окно позволяет нам добавить 1 номер на N-ное количество почт.

В случае привязки одного и того же номера в короткий временной промежуток, мы получали следующую ошибку:

Для снятия данного ограничения необходимо подождать около суток, после чего можно было заново отправить код на номер.

Смена данных

После покупки и смены данных на почтах мы никак не дофармливаем их.

Единственное - можем дать небольшую отлёгу.
Меняем все данные, добавляем 2FA, backup codes, reserve mail.

Исходя из наших тестов, у нас не получалось зайти в почты при использовании номеров некоторых гео.

При использовании номеров другого гео в рамках той же почты мы без каких-либо проблем заходили в неё.

Итог

В данном материале мы описываем исключительно наш опыт работы с почтами и наши действия при выборе почт.

Вся аргументация сводится исключительно к нашей потребности.
Наше мнение не является истинным. Решения, которые используем мы, могут вам не подойти.

При покупке почт - качество аккаунтов во многом зависит от селлера.

Команда koya.ads рада всех приветствовать!

В данном мануале представлена исключительно сухая выжимка - конечный алгоритм (ОДИН ИЗ), который точно работает в момент публикации данного материала.

Выбор устройства

Для регистрации в конечном итоге мы выбрали эмулятор BlueStacks.

Существует множество альтернативных эмуляторов и сервисов аренды виртуальных мобильных устройств. Каждый вариант необходимо тестировать.

1. Создание нового профиля в BlueStacks

Открываем BlueStacks. Нажимаем на пункт "Окно".

Выбираем "Новое (новый аккаунт)".

Выбираем версию Android:

• Android 11
• либо Android 13

Параметры конфигурации

В следующем модальном окне задаем параметры:

• CPU: 4 ядра
• ОЗУ: 8 GB

Нажимаем "Создать/Скачать". Ожидаем загрузку конфигурации.

После завершения нажимаем "Старт" - профиль запускается.

2. Установка APK для прокси

В открытом профиле BlueStacks справа находится панель управления с кнопкой «APK».

* Мы заранее скачали установочный файл Super Proxy с официального сайта.

Установка:

Нажимаем кнопку APK в эмуляторе.
Добавляем заранее скачанный файл Super Proxy. Ожидаем завершения установки.

После установки - приложение появится на рабочем столе эмулятора.

3. Настройка прокси в Super Proxy

Открываем Super Proxy. Нажимаем "Add proxy".

Параметры прокси:

• Profile name: любое название
• Protocol: SOCKS5
• Server/Port: данные сервера и порта
• Authentication method: Username / Password
• Username/Password: логин и пароль прокси
• DNS resolution: обязательно выбираем Google DNS

Сохраняем прокси. Нажимаем «Start».

После запуска:

• обязательно заходим обратно в профиль прокси, проверяем, что таймер работы запущен. Если таймер идет - прокси работает корректно.

4. Регистрация Gmail

На главном экране эмулятора открываем браузер Google. Вводим в поиске Gmail.

Переходим на сайт Gmail через выдачу Google. Приступаем к стандартной регистрации аккаунта.

Дополнительная информация по регистрации

1. Все динамические данные вводились вручную, без копирования

• имена,
• номера,
• коды

2. Использовались:

• как физические номера,
• так и арендные номера

3. Гео прокси и гео номера имели полную корреляцию

Итог

Это один из рабочих вариантов регистрации Gmail без QR-кода.

Этот вариант может пригодиться в использовании как для соло баеров, так и для небольших команд у которых нет крайне большой потребности в массовой регистрации Gmail аккаунтов.

Стоит уточнить, что данный процесс поддается автоматизации без каких-либо ограничений BlueStacks

📑 Наша команда уделяет значительное внимание проблемам, которые возникают как у наших клиентов, так и общим проблемам, которые Google Ads «дарит» всем нам. Однако сегодня мы хотели бы поговорить не о конкретных проблемах, с которыми сталкивается каждый баер, а о подходе к их решению.

Ниже мы кратко опишем наш подход к тестированию любой проблемы, которая становится массовой.

🛠 Исключение технической части

Первостепенно мы всегда начинаем с исключения технической части залива.

Для этого берем 10 аккаунтов, чтобы получить нормальную выборку, и первоначально запускаем кампании на любой белый домен из выдачи в нужном вам гео.

Далее остается перебрать технический сетап, чтобы локально определить источник проблемы.

В случае использования сторонних трекеров или аналитик, которые вы интегрируете в офферы, рекомендуем на период теста отказаться от их подключения.

🗒 Тестирование вайтпейджей

Далее начинаем тестирование вайтов в вашем стандартном сетапе.

Покупаем или делаем вайты самостоятельно, обязательно реализуя их максимально уникальными:

• генерация или ручные вайтпейджи
• HTML или WordPress как ядро и т.д.

🗃 Тестирование доменов и хостингов

После этого переходим к тестам доменов и хостингов. Мы тестируем две переменные одновременно, чтобы ускорить процесс и быстрее получить результат.

Если выяснилось, что проблема не в вайтах, покупаем домены и хостинги у разных провайдеров и миксуем их между собой.

Для решения этой проблемы есть три варианта:

1. Если вы сразу добавляете стандартные NS Cloudflare у регистратора, а затем добавляете домен в Cloudflare, сервис выдаст другие NS. Их необходимо повторно обновить у регистратора.
2. Перейти во вкладку Configurations в Cloudflare -> DNS Settings и включить Cloudflare standard nameservers (randomized). По умолчанию эта опция недоступна, для ее активации необходимо обратиться в техническую поддержку.
3. Использовать мультиаккаунтинг в Cloudflare (мы этот вариант не используем из-за неудобства управления большим количеством доменов).

Keitaro как возможный триггер

Отдельной проблемой может быть Keitaro, если вы хостите вайты внутри него.

По нашим тестам массовое использование Keitaro 11 вызывает Compromised Site либо обходы. Рекомендуем использовать версии ниже 11 либо не применять Keitaro в качестве хостинга для вайтпейджей.

Тестируем различные связки от разных провайдеров доменов и хостингов. В обязательном порядке часть доменов пропускаем через Cloudflare, а часть направляем напрямую, после чего анализируем результаты.

Касательно доменов: мы всегда используем исключительно доменную зону .com для сайтов, которые указываем в Google Ads. В нашем сетапе дешевые доменные зоны (.top, .biz, .info и т.д.) становились триггером для Compromised Site.
В ваших сетапах ситуация может отличаться, поэтому рекомендуем проверить это самостоятельно.

💾 Полное тестирование сетапа

Если блокировки продолжаются, мы переходим к полному тестированию сетапа, который включает:

1. Настройку профилей в антидетекте + прокси
2. Почты
3. Документы
4. Платежные решения + типы аккаунтов
5. Креативы

💻 Антидетект и прокси

Давайте начнем по порядку, профили мы всегда штатно настраиваем под машину, с которой работаем, и настоятельно рекомендуем избегать шумов - в наших тестах они плохо себя показывают.

Прокси также берем от разных поставщиков и, что немаловажно, различные типы прокси.

Мы распределили типы прокси по задачам следующим образом:

• IPv6 - крайне дешевые, но подходят для фарма
• Data center - оптимальный баланс цены и качества, подходят для фарма и запусков
• Mobile - подходят для всех задач (регистрация почты, фарм, запуск)
• Residential - хорошо показывают себя на запусках

Для проверки качества профиля в антидетекте мы используем следующие сервисы:

1. fv.pro
2. pixelscan.net
3. amiunique.org
4. leaksradar.com
5. whoer.net
6. coveryourtracks.eff.org
7. abrahamjuliot.github.io

📬 Почты

В работе мы используем два типа почт:

• почты с отлежкой более года
• профармленные новореги

Как показала практика, плохое качество почт может триггерить мультиаккаунт-бан, аналогично повторно используемым документам.

Преимущества почт с отлежкой:

• не требуют ручного фарма. (при покупке реальных почт, зарегистрированных с уникальных, реальных устройств пользователей (не софтом)
• на один номер можно привязать 20-30 почт, что значительно снижает расходы

Преимущества новорег почт:

• По сути, только одно - не нужно искать поставщиков. Однако они дороже в работе, дольше фармятся и чаще отлетают.

Самый рабочий сетап для новорегов:

• iPhone, выключенная геолокация, режим полета и модем, в котором на каждую регистрацию меняется прокси.

📇 Документы

Существует два типа документов:

• сгенерированные
• реальные документы

Генерация документов имеет ряд преимуществ:

• вероятность повторного использования документа практически нулевая
• с помощью нейросетей можно выстроить собственную систему генерации (связка ИИ + шаблон документа) при минимальных затратах

Основной минус - требуется время на настройку и поиск рабочих решений под ваш сетап.

💳 Платежные решения

Платежные решения редко становятся причиной блокировок, чаще они приводят к ограничениям аккаунта, такой как лимит $10 и т.д.

Для Postpay аккаунтов рабочим решением является использование разных платежных профилей и гео платежки (BIN карты). Это помогает избежать лимитов $2, $10

Эффективное решение - Prepay аккаунты.

В 95% случаев мы не ловим лимиты даже при заливе серого или черного трафика. Основной минус - депозит вносится заранее, и при блокировке вывод средств занимает ориентировочно 14 дней.

*Для первобиллов - вариант не подходит)))

🗂 Креативы

Последний, но не менее важный этап - креативы.

Тестировать их проще всего: берем максимально легкие креативы из библиотеки, проходим модерацию, после небольшого открута - меняйте на свои.

❗ Заключение

Еще раз подчеркнем: это не универсальный гайд по решению всех проблем в Google Ads и точно данная статья не является истиной.

Мы поделились собственным опытом и подходом к тестированию.

В рамках ваших сетапов Google Ads может вести себя иначе, и вы будете приходить к альтернативным выводам работы.

Сегодня обсудим и предоставим решение по насущной проблеме - «Обход Системы».

🧠 Причины бана

Этот вид бана раньше также не имел одной конкретной причины. А после обновления Google этот бан может появиться практически за что угодно:

• Недоверие к вайту;
• Пробило клоаку;
• Непонимание того, как ваш бизнес зарабатывает;
• Плохое качество аккаунтов;
• Качество оффера;
• Ключи;
• и другие...

Подпишитесь, чтобы не пропустить информацию о других гайдах и актуальных проблемах!

👀 Решение

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

Далее мы смотрим на вид бана. Если же мы получили:

«Обход Системы - Клоакинг» - нет смысла делать больше чем одну апелляцию, лучше потратить это время на запуск нового аккаунта. Поскольку по нашим тестам они не выходят адекватно из конкретно этого подтипа.

Любой другой «Обход Системы» - нужно подавать апелляцию 2-3 раза.

То есть получили обход -> переключили клоаку на вайт -> и начинаем писать апелляцию.

После того как мы написали первую апелляцию, у нас выбивает на тот же обход системы еще 1-2 раза, и в 80-85% случаев аккаунт разбанивается.

После того как мы подали первую апелляцию на обход, после нее можем получить снова тот же Обход - подаем опять апелляцию.

Либо может прилететь бан за «Бизнес-модели», в таком случае тоже подаем 2-3 апелляции по очереди.

В оставшихся 15-20% случаев, если прилетает «Обход - Клоакинг», как и описано выше, то мы выкидываем аккаунт после первой апелляции.

🎓 ВАЖНО

Три важнейших детали при работе с банами и апелляциями:

• С момента бана кло должна направлять только на вайтпейдж.
• Подавать апелляцию лучше как можно быстрее после получения бана. Скорее всего, антифрод Google работает по принципу, похожему на другие сервисы, где то, насколько человек быстро выполняет нужные условия и реагирует на проблемы, напрямую влияет на его фрод-скор.
• После выхода аккаунта из бана, кло не нужно сразу переключать на блек, нужно дождаться первых кликов.

🎈 Итог

Баны почти всегда сопровождаются определенными причинами, но в случае с «Обходом системы за Клоакинг» нет единого решения. Однако с обычным обходом около 80-85% можно вывести из бана путем постоянных апелляций.

Главное - делать их в течение часа, в идеале. А также не забывать переключать кло, так как во время разбирательств внимание к вашему аккаунту - максимальное. Если же вы очень часто получаете баны (связанные с бизнесом) - лучше пересмотреть вайты и техническую составляющеюе!

🚩 Внимание!

📞 Контакты

• Менеджер: koya.ads | manager
• Поддержка: koya.ads | support
• Телеграмм канал: koya.ads | channel

Если вы читаете этот гайд, значит, вы тоже столкнулись с распространенной проблемой - лимитами в $2 и $10.

В этом руководстве мы разберем два рабочих способа обхода данных ограничений.

Способ 1: Разное гео платежного профиля и карты

Суть метода заключается в использовании разных стран для платежного профиля и виртуальной карты.

Способ работает на любом гео.

Шаг #1:

Например: Если у нас есть аккаунт с гео Греции, с прокси Греции, верифицированный на документы из Греции, то при создании платежного профиля мы также указываем имя с документа и адрес в Греции.

Шаг #2:

Затем мы переходим на сервис проверки карт и проверяем гео наших карт по BIN (первые 6-8 цифр номера карты).

Обычно мы используем binlist.net.

Заходим на сайт, вводим BIN нашей карты и видим гео UK. Получается, что гео нашего аккаунта - Греция, гео платежного профиля - Греция, но гео VCC- UK.

Способ 2: Pre-pay метод оплаты (более эффективный)

Если в первом способе мы делаем разное гео платежного профиля и самой платежки для Post-pay (другое гео VCC), то во втором способе мы используем метод оплаты Pre-pay. Для этого необходимо зарегистрировать аккаунт в гео, где доступен метод оплаты Pre-pay, например, Украина.

Как найти подходящие страны:

Чтобы найти другие гео, где поддерживается оплата по модели Pre-pay, переходим на сайт: billing.google.com

Далее:

• В разделе «Product» выберите «Google Ads»
• В «Billing Country» и «Currency» подбирайте страны и валюту
• И в поле, которое появилось: «Available payment methods» ищите «Money transfer» - это Pre-pay

Важно:

Процесс регистрации:

• Нашли подходящее гео. Например, Украина
• Регистрируем аккаунт стандартно, но рекомендуем придерживаться первого способа и делать разное гео платежки и платежного профиля.
• При выборе модели оплаты, обязательно выбираем Prepay и делаем минимальный депозит в аккаунт.

Эффективность

🚩 Внимание!

Больше руководств и полезной информации в нашем Telegram-канале koya.ads- подписывайтесь, чтобы не пропустить актуальную полезную информацию и решения насущных проблем!

- подписывайтесь, чтобы не пропустить актуальную полезную информацию и решения насущных проблем!

❗ Не забывайте, что в koya.ads вы также можете найти готовое решение проблемы - приобрести аккаунты, которые помогут запустить рекламу без ограничений по расходу!