Google QR: регистрация усложнилась - вход стал дороже
Последние месяцы - заметный сдвиг в регистрации Google-аккаунтов. Вместо привычного SMS-кода все чаще появляется экран с QR-верификацией: сканируешь QR телефоном - система проверяет устройство/номер. Это уже не единичный баг, а повсеместное изменение в логике проверки.
Ключевые наблюдения:
- QR появляется значительно чаще - там, где раньше он был редкостью, теперь это стандарт.
- Чистые IP и антидетекты все реже "спасают". Механика проверки стала более завязанной на наличие реального устройства/номера.
- Сообщества и форумы фиксируют: универсального и стабильного обхода пока нет, трюки работают эпизодически и быстро перестают работать после изменения политики со стороны Google.
- Появилась тенденция к тому, что простая массовая штамповка аккаунтов уходит в прошлое - требования к подтверждению реального телефона/устройства повышают порог входа.
Что это меняет в экономике:
- Стоимость входа выросла - не только в рублях за SIM/устройства, но и во временных затратах на создание и прогрев учеток.
- Усложнился сценарий "быстрой генерации" сотен аккаунтов за короткий срок - теперь такой сценарий требует других ресурсов.
- Вероятность повторной верификации и последующих блокировок остается высокой: аккаунт, созданный без проверки, может запросить подтверждение позже.
Итого - это не временная "волна", а часть более широкой стратегии: Google сокращает возможности массовой автоматизации регистраций, повышая порог для ферм и ботов. Для рынка это означает одно - входной барьер увеличился. Вопросы о том, сколько это продлится и какие формы верификации станут следующими, остаются открытыми.
Факт остается фактом: регистрация аккаунтов в Google в 2025 году - уже не та, что была пару лет назад.
Последние месяцы - заметный сдвиг в регистрации Google-аккаунтов. Вместо привычного SMS-кода все чаще появляется экран с QR-верификацией: сканируешь QR телефоном - система проверяет устройство/номер. Это уже не единичный баг, а повсеместное изменение в логике проверки.
Ключевые наблюдения:
- QR появляется значительно чаще - там, где раньше он был редкостью, теперь это стандарт.
- Чистые IP и антидетекты все реже "спасают". Механика проверки стала более завязанной на наличие реального устройства/номера.
- Сообщества и форумы фиксируют: универсального и стабильного обхода пока нет, трюки работают эпизодически и быстро перестают работать после изменения политики со стороны Google.
- Появилась тенденция к тому, что простая массовая штамповка аккаунтов уходит в прошлое - требования к подтверждению реального телефона/устройства повышают порог входа.
Что это меняет в экономике:
- Стоимость входа выросла - не только в рублях за SIM/устройства, но и во временных затратах на создание и прогрев учеток.
- Усложнился сценарий "быстрой генерации" сотен аккаунтов за короткий срок - теперь такой сценарий требует других ресурсов.
- Вероятность повторной верификации и последующих блокировок остается высокой: аккаунт, созданный без проверки, может запросить подтверждение позже.
Итого - это не временная "волна", а часть более широкой стратегии: Google сокращает возможности массовой автоматизации регистраций, повышая порог для ферм и ботов. Для рынка это означает одно - входной барьер увеличился. Вопросы о том, сколько это продлится и какие формы верификации станут следующими, остаются открытыми.
Факт остается фактом: регистрация аккаунтов в Google в 2025 году - уже не та, что была пару лет назад.
AdsFinder v1.0 beta
Бесплатно, может кому пригодится.
Windows - SourceForge
macOS - SourceForge
Зеркала:
Windows - Archive.org
macOS - Archive.org
Инструкция - Telegra.ph
Бесплатно, может кому пригодится.
Windows - SourceForge
macOS - SourceForge
Зеркала:
Windows - Archive.org
macOS - Archive.org
Инструкция - Telegra.ph
🔥1
Cookies - иногда не вред, а необходимость
Последние пару недель адаптирую свой трекер под работу с прилками.
Изначально хотел обойтись без тяжелой "куковой" системы - сделал легкий временный вариант: фиксацию по IP + user-agent.
Для моих задач это тогда работало: быстро, без костылей и без лишнего шума для рекламных систем.
Если коротко: JS-cookies - это почти сразу крест на кампаниях в Google Ads. Любая попытка внедрить JS-трекинг воспринимается там как что-то "левое".
Это как идти по дороге и крошить печеньку перед носом волку - думаешь, просто метишь путь до своей конверсии, а по факту по этим крошкам тебя и находят, и потом съедают.
Почему без cookies сложно жить, если у тебя ротации и несколько офферов
Когда у тебя один нейминг и внутри кампании несколько офферов в сплите, куки становятся необходимостью.
Сценарии без кук:*
1. Пользователь пришел на оффер 1, зарегистрировался, внес депозит, поиграл. На следующий день заходит снова - а ему отдается оффер 2. Он не понимает, куда попал, и уходит. KPI по удержанию и качеству трафика - в ноль.
2. Пользователь днем посмотрел прилку, решил вечером вернуться и зарегистрироваться. Вечером открывает - уже другое казино, другое промо. Все, минус доверие, минус регистрация.
Без кук таких кейсов полно. Теряется не просто конверт - ломается сама логика кампании.
* на всякий случай уточню, что не изучал тех. часть прилок, и это скорее предположение
Можно упростить:
1 кампания = 1 прила = 1 оффер. Но тогда тесты перестают быть объективными.
Я это вижу на практике: креатив, прила, кампания - все сильно влияет на конверт. Если не сплитить, а просто лить с разных кампаний или прилок - сплит-тест получится нечистым, потому что внешние условия разные.
А куки как раз и удерживают связку: человек возвращается - получает тот же оффер, тот же контекст. И тест становится реально сравнимым, а не "рандомным".
Почему схема с IP + user-agent - временное решение
Когда я собирал трекер, осознанно выбрал облегченный вариант: привязку юзера по IP + user-agent. Это спасало и давало базовый контроль, особенно на старте. Но я понимал - это временно.
Например, в ряде гео мобильные операторы используют ограниченные пулы IP-адресов:
по одному IP может сидеть полрайона. User-agent меняется при каждом апдейте приложения, а мобильные сессии живут недолго. Так что стабильности такой подход не дает вообще.
Для веба (особенно в EU) это еще куда ни шло, но на мобильном трафике, особенно при работе с UAC, - этого катастрофически мало.
Почему JS-cookies - грязь
JS-куки Google и другие системы видят моментально. Ты вставил скрипт - и все: антифрод-алгоритмы уже шепчут "манипуляция".
К тому же WebView может просто не сохранить JS-куку или вычистить ее после перезапуска. Ты их ставишь, но по факту трекинга не получаешь. Добавляешь только рисков и головной боли.
Какие cookies ок и почему я оставил именно их
Окей-куки - это server-side (HTTP-level). Именно они должны быть привязаны не к домену трекера, а к рекламному URL - так сессия сохраняется в контексте рекламного источника, а не внутренней трекерной структуры.
Эти куки:
- не видны JS-фильтрам и антифрод-движкам,
- стабильно живут в WebView,
- не ломаются при смене домена трекера,
- корректно возвращают пользователя в тот же оффер при повторных заходах.
Для прил это оптимальный вариант: ничего не ломает в рекламных сетях, но дает полную связку между юзером, кампанией и оффером.
Но в целом остаюсь при своем мнении - если без куки можно обойтись, лучше обойтись. В этой игре выживает тот, кто оставляет меньше следов.
Последние пару недель адаптирую свой трекер под работу с прилками.
Изначально хотел обойтись без тяжелой "куковой" системы - сделал легкий временный вариант: фиксацию по IP + user-agent.
Для моих задач это тогда работало: быстро, без костылей и без лишнего шума для рекламных систем.
Если коротко: JS-cookies - это почти сразу крест на кампаниях в Google Ads. Любая попытка внедрить JS-трекинг воспринимается там как что-то "левое".
Это как идти по дороге и крошить печеньку перед носом волку - думаешь, просто метишь путь до своей конверсии, а по факту по этим крошкам тебя и находят, и потом съедают.
Почему без cookies сложно жить, если у тебя ротации и несколько офферов
Когда у тебя один нейминг и внутри кампании несколько офферов в сплите, куки становятся необходимостью.
Сценарии без кук:*
1. Пользователь пришел на оффер 1, зарегистрировался, внес депозит, поиграл. На следующий день заходит снова - а ему отдается оффер 2. Он не понимает, куда попал, и уходит. KPI по удержанию и качеству трафика - в ноль.
2. Пользователь днем посмотрел прилку, решил вечером вернуться и зарегистрироваться. Вечером открывает - уже другое казино, другое промо. Все, минус доверие, минус регистрация.
Без кук таких кейсов полно. Теряется не просто конверт - ломается сама логика кампании.
* на всякий случай уточню, что не изучал тех. часть прилок, и это скорее предположение
Можно упростить:
1 кампания = 1 прила = 1 оффер. Но тогда тесты перестают быть объективными.
Я это вижу на практике: креатив, прила, кампания - все сильно влияет на конверт. Если не сплитить, а просто лить с разных кампаний или прилок - сплит-тест получится нечистым, потому что внешние условия разные.
А куки как раз и удерживают связку: человек возвращается - получает тот же оффер, тот же контекст. И тест становится реально сравнимым, а не "рандомным".
Почему схема с IP + user-agent - временное решение
Когда я собирал трекер, осознанно выбрал облегченный вариант: привязку юзера по IP + user-agent. Это спасало и давало базовый контроль, особенно на старте. Но я понимал - это временно.
Например, в ряде гео мобильные операторы используют ограниченные пулы IP-адресов:
по одному IP может сидеть полрайона. User-agent меняется при каждом апдейте приложения, а мобильные сессии живут недолго. Так что стабильности такой подход не дает вообще.
Для веба (особенно в EU) это еще куда ни шло, но на мобильном трафике, особенно при работе с UAC, - этого катастрофически мало.
Почему JS-cookies - грязь
JS-куки Google и другие системы видят моментально. Ты вставил скрипт - и все: антифрод-алгоритмы уже шепчут "манипуляция".
К тому же WebView может просто не сохранить JS-куку или вычистить ее после перезапуска. Ты их ставишь, но по факту трекинга не получаешь. Добавляешь только рисков и головной боли.
Какие cookies ок и почему я оставил именно их
Окей-куки - это server-side (HTTP-level). Именно они должны быть привязаны не к домену трекера, а к рекламному URL - так сессия сохраняется в контексте рекламного источника, а не внутренней трекерной структуры.
Эти куки:
- не видны JS-фильтрам и антифрод-движкам,
- стабильно живут в WebView,
- не ломаются при смене домена трекера,
- корректно возвращают пользователя в тот же оффер при повторных заходах.
Для прил это оптимальный вариант: ничего не ломает в рекламных сетях, но дает полную связку между юзером, кампанией и оффером.
Но в целом остаюсь при своем мнении - если без куки можно обойтись, лучше обойтись. В этой игре выживает тот, кто оставляет меньше следов.
Пересобрал старое расширение для браузера которое дополняет возможности AdsFinder v1.0 beta.
Если коротко, оно умеет:
- показывать, сколько дней живет объявление,
- сколько лайков у фанпейджа,
- URL сайта из объявления,
- CTA-кнопку,
- копировать ссылки и скачивать видео/крео в HD.
Работает без логина в Facebook.
Кому нужно - пользуйтесь, пока FB опять что-то не сломал.
🔗 Подробнее и инструкция тут
Если коротко, оно умеет:
- показывать, сколько дней живет объявление,
- сколько лайков у фанпейджа,
- URL сайта из объявления,
- CTA-кнопку,
- копировать ссылки и скачивать видео/крео в HD.
Работает без логина в Facebook.
Кому нужно - пользуйтесь, пока FB опять что-то не сломал.
🔗 Подробнее и инструкция тут
Когда готовых решений не хватает: свой клиент под прокси
С антиками работаю не первый год - решения сложные, капризные, живут своей жизнью. Поэтому проще не бороться с ними, а подстроиться: выстраивать автоматизацию вокруг готовых инструментов, которые уже идут в ногу со временем.
В рамках собственного решения по автоматизации - следующим шагом дошел до прокси. И вот здесь все оказалось не так просто.
Сначала хотел работать через API антидетект-браузеров: добавлять и менять прокси напрямую. Но на практике это оказалось неудобным. Если прокси стабильные, без лимитов или смены IP и сессий - проблем нет. Но в реальной работе нужны гибкость и контроль.
Например, сервисы Pia или 922. Прокси выдаются на сутки и привязаны к сессии - могут отвалиться и ожить в любой момент. При этом в рамках одной сессии IP сохраняется, поэтому приоритет - использовать для аккаунта именно тот же IP, а не чередовать каждый раз новый.
Так связка остается стабильной, а переиспользование прокси помогает экономить баланс, пока срок действия не истек.
Другой пример - SOAX. Прокси там стабильные и быстрые, но работают с лимитом по трафику: каждый гигабайт стоит денег.
Для фарма, особенно с видео-контентом, это может стать дорогим удовольствием. Если использовать такие прокси, важно жестко ограничивать расход в рамках профиля или сессии, чтобы трафик не утекал впустую.
Теоретически можно подключать API провайдеров, если оно вообще есть. Но у всех свой формат и свои ограничения. Разбираться в десятках разных реализаций - смерти подобно: сегодня один формат, завтра другой, послезавтра обновят документацию - и все ломается.
Такая схема хрупкая и плохо масштабируется.
Поэтому решил написать свой клиент под прокси. Пока не как замену, а как инструмент для тех случаев, когда стандартные клиенты не справляются. Он будет учитывать реальные параметры - срок жизни сессии, скорость, лимит трафика, стабильность и возможность перезапуска.
Такое решение даст больше гибкости там, где ее не хватает, и позволит автоматизировать то, что пока приходится делать вручную.
С тем же Pia, например, прокси приходится менять по несколько раз в день. А в некоторых антиках это целое мучение.
Хочется, чтобы система сама понимала, когда прокси умирает, и подхватывала новый без участия человека или хотя бы с минимальным.
С антиками работаю не первый год - решения сложные, капризные, живут своей жизнью. Поэтому проще не бороться с ними, а подстроиться: выстраивать автоматизацию вокруг готовых инструментов, которые уже идут в ногу со временем.
В рамках собственного решения по автоматизации - следующим шагом дошел до прокси. И вот здесь все оказалось не так просто.
Сначала хотел работать через API антидетект-браузеров: добавлять и менять прокси напрямую. Но на практике это оказалось неудобным. Если прокси стабильные, без лимитов или смены IP и сессий - проблем нет. Но в реальной работе нужны гибкость и контроль.
Например, сервисы Pia или 922. Прокси выдаются на сутки и привязаны к сессии - могут отвалиться и ожить в любой момент. При этом в рамках одной сессии IP сохраняется, поэтому приоритет - использовать для аккаунта именно тот же IP, а не чередовать каждый раз новый.
Так связка остается стабильной, а переиспользование прокси помогает экономить баланс, пока срок действия не истек.
Другой пример - SOAX. Прокси там стабильные и быстрые, но работают с лимитом по трафику: каждый гигабайт стоит денег.
Для фарма, особенно с видео-контентом, это может стать дорогим удовольствием. Если использовать такие прокси, важно жестко ограничивать расход в рамках профиля или сессии, чтобы трафик не утекал впустую.
Теоретически можно подключать API провайдеров, если оно вообще есть. Но у всех свой формат и свои ограничения. Разбираться в десятках разных реализаций - смерти подобно: сегодня один формат, завтра другой, послезавтра обновят документацию - и все ломается.
Такая схема хрупкая и плохо масштабируется.
Поэтому решил написать свой клиент под прокси. Пока не как замену, а как инструмент для тех случаев, когда стандартные клиенты не справляются. Он будет учитывать реальные параметры - срок жизни сессии, скорость, лимит трафика, стабильность и возможность перезапуска.
Такое решение даст больше гибкости там, где ее не хватает, и позволит автоматизировать то, что пока приходится делать вручную.
С тем же Pia, например, прокси приходится менять по несколько раз в день. А в некоторых антиках это целое мучение.
Хочется, чтобы система сама понимала, когда прокси умирает, и подхватывала новый без участия человека или хотя бы с минимальным.
О "хороших" прокси, антидетектах и том самом UDP
Возвращаясь к теме "лучших прокси" и "самых надежных антидетект браузеров", хочется отдельно остановиться на UDP - сейчас про него говорят все чаще.
Можно спорить бесконечно: резидентские против мобильных, антидетекты против антидетектнее антидетектов. Но факт остается фактом - все, что есть на рынке, прекрасно светится, особенно если речь идет не о паре аккаунтов, а о десятках или сотнях.
Если совсем коротко - ни одна связка известный прокси провайдер + популярный антидетект браузер не проходит базовую проверку здесь: [networktest.twilio.com]
Выбор один из двух:
- либо "открывать" свой реальный публичный IP,
- либо получить три красных чек-бокса в первых пунктах.
Ирония в том, что обычный "реальный" ПК без прокси и антидетектов проходит этот тест спокойно.
И вот тут начинается понимание. Не вдаваясь в теорию UDP-пакетов (кому интересно - разберется сам), скажу как вижу: все эти разговоры про "суперзащищенные" прокси и "невидимые" антидетекты звучат красиво, но по факту все это один и тот же дым, просто в разных бутылках..
И в этом, как ни странно, есть определенное спокойствие. Понимаешь, что массовые разлоги, отваливающаяся почта, внезапные верификации - не мистика и не "карма аккаунта". Это просто логика системы. Где-то не совпал конфиг антика, где-то UDP отработал как не надо, где-то другой триггер.
Да, возможно, самые "корявые" антидетекты или "грязные" прокси хуже - ловят капчу, разлог и т.д. Но если говорить честно - даже публичные решения, пусть не под тысячи, но под пару десятков или сотен аккаунтов, вполне себе живут.
Почему разработчики антидетектов до сих пор не внедряют нормальную поддержку UDP? Не знаю. Возможно, вопрос в сложности, возможно - в том, что не хотят тратить ресурсы на то, что не все оценят.
Это не истина в последней инстанции, а просто мое наблюдение из практики. Возможно, кто-то видит иначе - без проблем.
Но факт остается: любая защита держится ровно до первого реального теста. Остальное - маркетинг и красивая обертка.
Возвращаясь к теме "лучших прокси" и "самых надежных антидетект браузеров", хочется отдельно остановиться на UDP - сейчас про него говорят все чаще.
Можно спорить бесконечно: резидентские против мобильных, антидетекты против антидетектнее антидетектов. Но факт остается фактом - все, что есть на рынке, прекрасно светится, особенно если речь идет не о паре аккаунтов, а о десятках или сотнях.
Если совсем коротко - ни одна связка известный прокси провайдер + популярный антидетект браузер не проходит базовую проверку здесь: [networktest.twilio.com]
Выбор один из двух:
- либо "открывать" свой реальный публичный IP,
- либо получить три красных чек-бокса в первых пунктах.
Ирония в том, что обычный "реальный" ПК без прокси и антидетектов проходит этот тест спокойно.
И вот тут начинается понимание. Не вдаваясь в теорию UDP-пакетов (кому интересно - разберется сам), скажу как вижу: все эти разговоры про "суперзащищенные" прокси и "невидимые" антидетекты звучат красиво, но по факту все это один и тот же дым, просто в разных бутылках..
И в этом, как ни странно, есть определенное спокойствие. Понимаешь, что массовые разлоги, отваливающаяся почта, внезапные верификации - не мистика и не "карма аккаунта". Это просто логика системы. Где-то не совпал конфиг антика, где-то UDP отработал как не надо, где-то другой триггер.
Да, возможно, самые "корявые" антидетекты или "грязные" прокси хуже - ловят капчу, разлог и т.д. Но если говорить честно - даже публичные решения, пусть не под тысячи, но под пару десятков или сотен аккаунтов, вполне себе живут.
Почему разработчики антидетектов до сих пор не внедряют нормальную поддержку UDP? Не знаю. Возможно, вопрос в сложности, возможно - в том, что не хотят тратить ресурсы на то, что не все оценят.
Это не истина в последней инстанции, а просто мое наблюдение из практики. Возможно, кто-то видит иначе - без проблем.
Но факт остается: любая защита держится ровно до первого реального теста. Остальное - маркетинг и красивая обертка.
2FA Account Manager - локальное приложение, чтобы таблицы отдыхали
В какой-то момент понял, что в Google Таблицах у меня уже не таблицы, а целая жизнь: аккаунты, пароли, карты, заметки, задачи.
Однажды открыл Gmail почту - и задумался: все это ведь уже давно анализирует какой-нибудь Gemini, делает выводы, строит графики продуктивности. И, наверное, уже понял, что арбитражник из меня так себе, и фармы - на троечку.
Собрал локальное решение - 2FA Account Manager. Просто приложение, где можно хранить аккаунты, логины, пароли, заметки и одноразовые задачи.
Это не менеджер рекламных кабинетов, а скорее расширенная альтернатива таблицам:
где удобно отмечать статусы, какие карты к кому привязаны, что нужно сделать, и что на очереди.
Работает оффлайн, все хранится локально в зашифрованной базе.
Основное:
хранение данных аккаунтов, телефонов, карт и заметок;
генерация 2FA-кодов;
простые задачи со статусами;
локальные резервные копии;
быстрый поиск по важным полям;
светлая и темная темы.
Интерфейс минимальный - открыл, нашел, закрыл. Никаких синхронизаций, авторизаций и прочих "для удобства".
Ссылки:
В связи с низким интересом публичная версия приложения снята с распространения.
В какой-то момент понял, что в Google Таблицах у меня уже не таблицы, а целая жизнь: аккаунты, пароли, карты, заметки, задачи.
Однажды открыл Gmail почту - и задумался: все это ведь уже давно анализирует какой-нибудь Gemini, делает выводы, строит графики продуктивности. И, наверное, уже понял, что арбитражник из меня так себе, и фармы - на троечку.
Собрал локальное решение - 2FA Account Manager. Просто приложение, где можно хранить аккаунты, логины, пароли, заметки и одноразовые задачи.
Это не менеджер рекламных кабинетов, а скорее расширенная альтернатива таблицам:
где удобно отмечать статусы, какие карты к кому привязаны, что нужно сделать, и что на очереди.
Работает оффлайн, все хранится локально в зашифрованной базе.
Основное:
хранение данных аккаунтов, телефонов, карт и заметок;
генерация 2FA-кодов;
простые задачи со статусами;
локальные резервные копии;
быстрый поиск по важным полям;
светлая и темная темы.
Интерфейс минимальный - открыл, нашел, закрыл. Никаких синхронизаций, авторизаций и прочих "для удобства".
Ссылки:
В связи с низким интересом публичная версия приложения снята с распространения.
Непопулярное мнение: товарищи, объединяйтесь
Арбитраж - тема выгодная. Если есть голова, немного везенияи можешь идти по головам - все получится.
Но это же и самое нестабильное направление. Сегодня льешь и пьешь вино, а завтра вино пьет кто-то другой.
Арбитраж - это место, где благодарности не жди. Поможешь - хорошо, но в ответ тишина. А если тебе что-то подсказали - сто раз проверь, не соврали ли.
Мы сейчас в моменте, который очень напоминает первые годы интернета. Помнишь тот мерзкий модемный звук, когда соединение шипело, страницы грузились по минуте, а за 5 баксов ты покупал карточку пополнения, чтобы поговорить три секунды и сбросить?
Так вот - потом все это рвануло. Появились сайты, сервисы, онлайн-покупки. И те, кто тогда проспал переход, потом догоняли уже сзади.
Сейчас то же самое.
ИИ, автоматизация, новые алгоритмы - пока все это выглядит "игрушкой".
Но когда стрельнет (а стрельнет обязательно) - старые методы, старые связки, старые подходы не спасут.
Тот, кто живет "по старому" и один в поле воин - просто не выдержит темпа.
Потому и говорю непопулярную вещь: нужно объединяться. Не в "команды по фоткам", а в нормальные рабочие связки, где кто-то закрывает технику, кто-то автоматизацию, кто-то залив.
Потому что найти сейчас баера, который сам наклепает качественные аккаунты, развернет хостинг, поднимет трекер и еще креатив напишет - таких почти не осталось. Эпоха "у меня есть связка" ушла.
Сейчас выигрывает не одиночка, а структура.
Все стало меняться слишком быстро.
И если не адаптироваться - можно в какой-то момент очнуться, когда весь рынок уже ушел вперед.
И останешься не как тот дед у корыта - а как человек с идеальной старой связкой, которая больше никому не нужна.
Арбитраж - тема выгодная. Если есть голова, немного везения
Но это же и самое нестабильное направление. Сегодня льешь и пьешь вино, а завтра вино пьет кто-то другой.
Арбитраж - это место, где благодарности не жди. Поможешь - хорошо, но в ответ тишина. А если тебе что-то подсказали - сто раз проверь, не соврали ли.
Мы сейчас в моменте, который очень напоминает первые годы интернета. Помнишь тот мерзкий модемный звук, когда соединение шипело, страницы грузились по минуте, а за 5 баксов ты покупал карточку пополнения, чтобы поговорить три секунды и сбросить?
Так вот - потом все это рвануло. Появились сайты, сервисы, онлайн-покупки. И те, кто тогда проспал переход, потом догоняли уже сзади.
Сейчас то же самое.
ИИ, автоматизация, новые алгоритмы - пока все это выглядит "игрушкой".
Но когда стрельнет (а стрельнет обязательно) - старые методы, старые связки, старые подходы не спасут.
Тот, кто живет "по старому" и один в поле воин - просто не выдержит темпа.
Потому и говорю непопулярную вещь: нужно объединяться. Не в "команды по фоткам", а в нормальные рабочие связки, где кто-то закрывает технику, кто-то автоматизацию, кто-то залив.
Потому что найти сейчас баера, который сам наклепает качественные аккаунты, развернет хостинг, поднимет трекер и еще креатив напишет - таких почти не осталось. Эпоха "у меня есть связка" ушла.
Сейчас выигрывает не одиночка, а структура.
Все стало меняться слишком быстро.
И если не адаптироваться - можно в какой-то момент очнуться, когда весь рынок уже ушел вперед.
И останешься не как тот дед у корыта - а как человек с идеальной старой связкой, которая больше никому не нужна.
This media is not supported in your browser
VIEW IN TELEGRAM
Собираю софт для мониторинга Google Ads, который работает внутри антидетект браузеров (собирает статистику через расширение).
Пока без управления - только наблюдение: балансы, спенд, простые алерты.
Из-за разных языков и вариантов интерфейса DOM в Google Ads не самый простой, поэтому проект пока в стадии эксперимента.
Короткое превью - в видео.
Пока без управления - только наблюдение: балансы, спенд, простые алерты.
Из-за разных языков и вариантов интерфейса DOM в Google Ads не самый простой, поэтому проект пока в стадии эксперимента.
Короткое превью - в видео.
Про потенциал CPC казино в Google Ads
Есть ощущение, что у CPC казино в Google Ads очень высокий потенциал, особенно если сравнивать с UAC.
Формат сложный, заход медленный, но именно поэтому конкуренции там заметно меньше.
Основная масса игроков либо сидит в UAC, либо работает через поиск - часто с сертификатами и различными костылями.
CPC формат при этом остается в стороне не потому, что он не работает, а потому что с ним мало кто умеет работать.
Почему так.
1. Сложная модель
CPC казино - это не история про креатив + ссылка.
Здесь важно, чтобы то, что видит Google в крео, и то, что видит пользователь, логически совпадало как с вайтом, так и с манипейдж.
Не формально, а по смыслу.
Именно на этом этапе большинство и отваливается.
2. Жесткая модерация
Любая прямолинейность быстро заканчивается обходом.
Сомнительные формулировки, обещания, даже аккуратные намеки на онлайн гемблинг со временем ловят флаги. Часто не сразу, а уже на объеме.
3. Высокий порог входа
Формат не про быстрые тесты.
Он требует понимания логики алгоритмов и того, как выглядит путь пользователя со стороны Google.
Именно поэтому CPC гембла в Google Ads и выглядит перспективно.
Не потому что там легко. А потому что туда почти никто не лезет - формат сложный и требует головы.
А там, куда большинство не готово идти, обычно и остается пространство для заработка.
Есть ощущение, что у CPC казино в Google Ads очень высокий потенциал, особенно если сравнивать с UAC.
Формат сложный, заход медленный, но именно поэтому конкуренции там заметно меньше.
Основная масса игроков либо сидит в UAC, либо работает через поиск - часто с сертификатами и различными костылями.
CPC формат при этом остается в стороне не потому, что он не работает, а потому что с ним мало кто умеет работать.
Почему так.
1. Сложная модель
CPC казино - это не история про креатив + ссылка.
Здесь важно, чтобы то, что видит Google в крео, и то, что видит пользователь, логически совпадало как с вайтом, так и с манипейдж.
Не формально, а по смыслу.
Именно на этом этапе большинство и отваливается.
2. Жесткая модерация
Любая прямолинейность быстро заканчивается обходом.
Сомнительные формулировки, обещания, даже аккуратные намеки на онлайн гемблинг со временем ловят флаги. Часто не сразу, а уже на объеме.
3. Высокий порог входа
Формат не про быстрые тесты.
Он требует понимания логики алгоритмов и того, как выглядит путь пользователя со стороны Google.
Именно поэтому CPC гембла в Google Ads и выглядит перспективно.
Не потому что там легко. А потому что туда почти никто не лезет - формат сложный и требует головы.
А там, куда большинство не готово идти, обычно и остается пространство для заработка.
Бесплатный UAC - хороший старт для теста гемблы или рассадник для кардеров?
Недавно наткнулся на странные отзывы в одной из прилок. Сначала не придал значения, но когда почитал внимательнее - стало понятно, что все они, по сути, об одном и том же.
В креативах - классическая история: "баеры" обещают сказочные бонусы и легкий старт. На практике после депозита карта оказывается пустой. Не берусь утверждать детали, но судя по отзывам, после пополнения через какой-то мифический PayPal пользователь в итоге теряет больше, чем рассчитывал.
Сам UAC сейчас уже не тот, что раньше. Раньше методом перебора офферов и гео можно было зацепить рабочие связки. Сейчас это все чаще выглядит как банальный слив бюджета.
При этом важно понимать контекст: основные конкуренты - это крупные команды и баеры от самих казино. Для них CPA в условные $20 - смешные цифры. Они легко могут позволить себе x2–x3 дороже той цены, на которой ты еще должен зарабатывать.
Если к этому добавить "грязный трафик" кардеров, для которых цена лида тоже выше твоей награды, - картина становится еще менее привлекательной. Плюс аккаунты сейчас живут недолго, особенно если начинаешь наглеть с крео.
И еще момент, чисто как наблюдение. Совпадение или нет, но одна из команд в последнее время перестала выкладывать свои прилы в паблик. Возможно, какие-то события или кейсы запустили определенные процессы - не берусь утверждать, кто, как и почему, но сам факт выглядит показательно.
В итоге направление сложное. Заходить туда, возможно, и можно, но явно не с нуля и не вслепую - нужно какое-то реальное преимущество.
Недавно наткнулся на странные отзывы в одной из прилок. Сначала не придал значения, но когда почитал внимательнее - стало понятно, что все они, по сути, об одном и том же.
В креативах - классическая история: "баеры" обещают сказочные бонусы и легкий старт. На практике после депозита карта оказывается пустой. Не берусь утверждать детали, но судя по отзывам, после пополнения через какой-то мифический PayPal пользователь в итоге теряет больше, чем рассчитывал.
Сам UAC сейчас уже не тот, что раньше. Раньше методом перебора офферов и гео можно было зацепить рабочие связки. Сейчас это все чаще выглядит как банальный слив бюджета.
При этом важно понимать контекст: основные конкуренты - это крупные команды и баеры от самих казино. Для них CPA в условные $20 - смешные цифры. Они легко могут позволить себе x2–x3 дороже той цены, на которой ты еще должен зарабатывать.
Если к этому добавить "грязный трафик" кардеров, для которых цена лида тоже выше твоей награды, - картина становится еще менее привлекательной. Плюс аккаунты сейчас живут недолго, особенно если начинаешь наглеть с крео.
И еще момент, чисто как наблюдение. Совпадение или нет, но одна из команд в последнее время перестала выкладывать свои прилы в паблик. Возможно, какие-то события или кейсы запустили определенные процессы - не берусь утверждать, кто, как и почему, но сам факт выглядит показательно.
В итоге направление сложное. Заходить туда, возможно, и можно, но явно не с нуля и не вслепую - нужно какое-то реальное преимущество.
Google вычищает устройства от IPIDEA - или почему "дешевые" прокси внезапно умерли
В конце января начали массово отваливаться "дешевые" резидентские прокси. Не по одному и не локально, а сразу целым пластом.
Перестали стабильно работать:
360proxy.com
922proxy.com
abcproxy.com
cherryproxy.com
doorvpn.com
galleonvpn.com
ip2world.com
ipidea.io
lunaproxy.com
piaproxy.com
pyproxy.com
radishvpn.com
tabproxy.com
Совпадение? Нет.
Причина в том, что Google нанес системный удар по инфраструктуре IPIDEA.
Google сделал сразу несколько шагов. Он получил судебный ордер и добился удаления доменов, которые управляли сетью IPIDEA. Передал другим компаниям и платформам информацию о вредоносных SDK - модулях, которые встраивались в приложения и добавляли прокси-функциональность. Также была обновлена защита Android Play Protect, которая начала блокировать и удалять приложения, связанные с этой сетью.
В результате с разной скоростью начали умирать резидентские прокси у перечисленных сервисов.
При этом все эти сервисы годами позиционировали себя как "честные" прокси-провайдеры. На деле же IPIDEA - это инфраструктура, которая незаметно превращала обычные пользовательские устройства, такие как компьютеры, смартфоны и ТВ-приставки, в прокси-узлы. Через них проходил самый разный трафик, в том числе трафик арбитражников. Владельцы устройств чаще всего даже не подозревали, что участвуют в прокси-сети.
Значит ли это, что таких сервисов больше не будет? Конечно же нет. Они были и будут, просто под другими именами, с другой архитектурой и более аккуратной маскировкой.
Но важно другое. Это уже не временные сбои и не очередной "бан прокси". Контроль со стороны Google выходит на инфраструктурный уровень.
Да, Google Ads становится дороже. И нет никаких сомнений, что через год-два работа с некоторыми вертикалями станет либо крайне сложной, либо практически невозможной при старых подходах.
Это смена правил игры. И думать о том, как работать дальше, нужно уже сейчас, а не в момент, когда в очередной раз внезапно "все отвалится".
В конце января начали массово отваливаться "дешевые" резидентские прокси. Не по одному и не локально, а сразу целым пластом.
Перестали стабильно работать:
360proxy.com
922proxy.com
abcproxy.com
cherryproxy.com
doorvpn.com
galleonvpn.com
ip2world.com
ipidea.io
lunaproxy.com
piaproxy.com
pyproxy.com
radishvpn.com
tabproxy.com
Совпадение? Нет.
Причина в том, что Google нанес системный удар по инфраструктуре IPIDEA.
Google сделал сразу несколько шагов. Он получил судебный ордер и добился удаления доменов, которые управляли сетью IPIDEA. Передал другим компаниям и платформам информацию о вредоносных SDK - модулях, которые встраивались в приложения и добавляли прокси-функциональность. Также была обновлена защита Android Play Protect, которая начала блокировать и удалять приложения, связанные с этой сетью.
В результате с разной скоростью начали умирать резидентские прокси у перечисленных сервисов.
При этом все эти сервисы годами позиционировали себя как "честные" прокси-провайдеры. На деле же IPIDEA - это инфраструктура, которая незаметно превращала обычные пользовательские устройства, такие как компьютеры, смартфоны и ТВ-приставки, в прокси-узлы. Через них проходил самый разный трафик, в том числе трафик арбитражников. Владельцы устройств чаще всего даже не подозревали, что участвуют в прокси-сети.
Значит ли это, что таких сервисов больше не будет? Конечно же нет. Они были и будут, просто под другими именами, с другой архитектурой и более аккуратной маскировкой.
Но важно другое. Это уже не временные сбои и не очередной "бан прокси". Контроль со стороны Google выходит на инфраструктурный уровень.
Да, Google Ads становится дороже. И нет никаких сомнений, что через год-два работа с некоторыми вертикалями станет либо крайне сложной, либо практически невозможной при старых подходах.
Это смена правил игры. И думать о том, как работать дальше, нужно уже сейчас, а не в момент, когда в очередной раз внезапно "все отвалится".
QR-коды при регистрации Google: как все устроено сейчас
С конца 2025 года при регистрации Google-аккаунта все чаще появляется QR-код. Заполняешь данные - и вместо привычного шага подтверждения просят взять телефон и отсканировать код.
Иногда QR не появляется. Бывает, что проходит через обычный браузер, через "прогретый" профиль антика, через другие сервисы Google. Но гарантии нет. Сегодня пустило, завтра на тех же условиях покажет QR-код.
Что на самом деле происходит после сканирования
Когда вы сканируете QR, телефон подключается к той же сессии регистрации. По сути, Google получает второй сигнал - уже с мобильного устройства.
Минимум, что точно видно системе:
- IP телефона,
- тип устройства и ОС,
- браузер и базовые параметры окружения.
Иногда любят рассказывать про "жесткую аппаратную аттестацию", проверку ID железа и прочее. Да, у Google есть инструменты проверки целостности устройств. Но утверждать, что при каждом QR включается тотальная проверка железа - это перебор. Скорее включается оценка риска, и уже в зависимости от нее система решает, насколько глубоко проверять устройство.
Это дополнительный мобильный фактор. Не больше, не меньше.
История с SMS
После сканирования обычно появляется шаг с отправкой SMS. Телефон открывает готовое сообщение - номер и текст уже заполнены, остается нажать "Отправить". И вот здесь начинается самое интересное.
Обычные и короткие номера
Номера бывают двух типов:
- обычные международные (+7…, +380..., +44… и т.д.),
- короткие сервисные.
Часто пишут, что публичные сервисы номеров "вообще не позволяют отправлять SMS". Это не совсем так. Многие действительно работают только на прием, но есть и такие, которые дают возможность отправки.
Проблема в другом - короткие номера. С ними сложнее из-за ограничений операторов и правил самих сервисов. Не каждый даст отправить сообщение на короткий номер.
Если Google будет чаще использовать именно короткие номера, рынок просто станет дороже:
- появятся более дорогие сервисы с полноценной отправкой,
- вырастет спрос на реальные SIM в нужных странах,
- подключатся люди, которые физически покупают SIM под задачу.
Это не блокировка процесса, а увеличение затрат.
Обязателен ли реальный телефон?
Если смотреть формально - по логике Google да, устройство должно быть реальным. Если смотреть по практике - нет, это обходится. И обходится даже без сверхсложных схем.
Тесты показывают:
- регистрация с эмуляторов проходит,
- антидетект-браузеры в ряде случаев спокойно справляются,
- QR не означает автоматическую блокировку "нереального" устройства.
Да, нестабильно. Да, не в 100% случаев. Но утверждение "без физического смартфона ничего не создать" - не соответствует реальности.
Кому тяжелее всего
Больше всего изменения бьют по сервисам, которые массово продают аккаунты.
Их модель строилась на:
- дешевой массовой регистрации,
- минимальном мобильном факторе,
- отлежке аккаунтов по несколько лет.
Теперь:
- растет стоимость создания,
- выше процент неудач,
- больше ручной работы,
- сильнее зависимость от мобильных устройств.
С высокой вероятностью в будущем:
- аккаунты станут дороже,
- "старые с большой отлежкой" будут редкостью,
- рынок станет менее массовым и более затратным.
Как выглядит схема целиком
Если собрать все в одну картину:
ПК инициирует регистрацию → при подозрении подключается мобильный → система видит два устройства → проверяется наличие SIM → анализируются IP и поведение → аккаунт либо создается, либо нет.
Система постепенно усложняется. Полного запрета нет, но стоимость ошибки и цена массовости уже заметно выросли.
С конца 2025 года при регистрации Google-аккаунта все чаще появляется QR-код. Заполняешь данные - и вместо привычного шага подтверждения просят взять телефон и отсканировать код.
Иногда QR не появляется. Бывает, что проходит через обычный браузер, через "прогретый" профиль антика, через другие сервисы Google. Но гарантии нет. Сегодня пустило, завтра на тех же условиях покажет QR-код.
Что на самом деле происходит после сканирования
Когда вы сканируете QR, телефон подключается к той же сессии регистрации. По сути, Google получает второй сигнал - уже с мобильного устройства.
Минимум, что точно видно системе:
- IP телефона,
- тип устройства и ОС,
- браузер и базовые параметры окружения.
Иногда любят рассказывать про "жесткую аппаратную аттестацию", проверку ID железа и прочее. Да, у Google есть инструменты проверки целостности устройств. Но утверждать, что при каждом QR включается тотальная проверка железа - это перебор. Скорее включается оценка риска, и уже в зависимости от нее система решает, насколько глубоко проверять устройство.
Это дополнительный мобильный фактор. Не больше, не меньше.
История с SMS
После сканирования обычно появляется шаг с отправкой SMS. Телефон открывает готовое сообщение - номер и текст уже заполнены, остается нажать "Отправить". И вот здесь начинается самое интересное.
Обычные и короткие номера
Номера бывают двух типов:
- обычные международные (+7…, +380..., +44… и т.д.),
- короткие сервисные.
Часто пишут, что публичные сервисы номеров "вообще не позволяют отправлять SMS". Это не совсем так. Многие действительно работают только на прием, но есть и такие, которые дают возможность отправки.
Проблема в другом - короткие номера. С ними сложнее из-за ограничений операторов и правил самих сервисов. Не каждый даст отправить сообщение на короткий номер.
Если Google будет чаще использовать именно короткие номера, рынок просто станет дороже:
- появятся более дорогие сервисы с полноценной отправкой,
- вырастет спрос на реальные SIM в нужных странах,
- подключатся люди, которые физически покупают SIM под задачу.
Это не блокировка процесса, а увеличение затрат.
Обязателен ли реальный телефон?
Если смотреть формально - по логике Google да, устройство должно быть реальным. Если смотреть по практике - нет, это обходится. И обходится даже без сверхсложных схем.
Тесты показывают:
- регистрация с эмуляторов проходит,
- антидетект-браузеры в ряде случаев спокойно справляются,
- QR не означает автоматическую блокировку "нереального" устройства.
Да, нестабильно. Да, не в 100% случаев. Но утверждение "без физического смартфона ничего не создать" - не соответствует реальности.
Кому тяжелее всего
Больше всего изменения бьют по сервисам, которые массово продают аккаунты.
Их модель строилась на:
- дешевой массовой регистрации,
- минимальном мобильном факторе,
- отлежке аккаунтов по несколько лет.
Теперь:
- растет стоимость создания,
- выше процент неудач,
- больше ручной работы,
- сильнее зависимость от мобильных устройств.
С высокой вероятностью в будущем:
- аккаунты станут дороже,
- "старые с большой отлежкой" будут редкостью,
- рынок станет менее массовым и более затратным.
Как выглядит схема целиком
Если собрать все в одну картину:
ПК инициирует регистрацию → при подозрении подключается мобильный → система видит два устройства → проверяется наличие SIM → анализируются IP и поведение → аккаунт либо создается, либо нет.
Система постепенно усложняется. Полного запрета нет, но стоимость ошибки и цена массовости уже заметно выросли.
QUIC в антидетектах: "Таблетка" от разлогов или новый повод для бана?
Ранее писал, что большинство антидетект-браузеров не проходят тесты на сетевую консистентность UDP. Если проще: браузер говорит, что он Chrome, но на уровне сетевого стека возникают расхождения с поведением реального Chrome.
Больше месяца назад Vision выкатил возможность проксировать QUIC. Добрался до тестов.
Что можно сказать сейчас: проверки на [networktest.twilio.com] и [browserleaks.com] проходят успешно, UDP-пакеты пробрасываются через прокси. Это значит, что софт научился имитировать работу реального стека протоколов Google.
Насколько качественно это реализовано "под капотом", без глубокого анализа сказать сложно. Поэтому я перевел часть профилей на "Проксировать QUIC" для эксперимента.
На деле же нужны полноценные тесты: от регистрации Gmail-почт до залива в Google Ads.
Что в теории дает поддержка QUIC?
1. Траст среды: Ты не выделяешься из толпы. Обычный Chrome в 2026 году по умолчанию использует QUIC. Если у тебя его нет - это аномалия для антифрода.
2. Стабильность сессий: QUIC лучше держит соединение при смене IP на мобильных прокси (меньше "вылетов" из аккаунта за счет технологии Connection Migration).
Чем опасна кривая реализация?
Это гораздо больший триггер, чем полное отсутствие UDP. Если антик или прокси "лагают", возникают ошибки протокола (например, ERR_QUIC_PROTOCOL_ERROR). Для Google это сигнал: перед нами либо бот, либо кривой софт.
Нужно понимать: QUIC - это родной протокол компании Google, ими же разработанный еще в 2012 году. Наивно полагать, что они не знают его досконально и не видят малейших расхождений в поведении вашего браузера.
Стоит ли сейчас срочно переходить на Vision, включать QUIC и скупать UDP-прокси? Конечно, нет. Это пока история для тестов на паре десятков профилей. Особенно если у вас и так все летит - не ломайте то, что работает.
Даже если первичные тесты выглядят лучше, это все равно не повод для массового перехода: Google не принимает решения по одному сигналу и не "стреляет" мгновенно.
Сетевое поведение, как и другие параметры, накапливается со временем, и именно на совокупности данных принимаются флаги и дальнейшие действия.
То, что сегодня выглядит нейтрально или даже положительно, при масштабировании может внезапно стать общей точкой риска для всей сетки аккаунтов.
Массово переходить опаснее, чем остаться на текущем решении.
Помимо самого антика, огромный вопрос к качеству прокси: большинство стандартных HTTP/Socks5 на рынке просто блокируют UDP-трафик, и включение QUIC в таком случае только навредит.
В любом случае, "рынок антиков" не стоит на месте, и это радует.
Ранее писал, что большинство антидетект-браузеров не проходят тесты на сетевую консистентность UDP. Если проще: браузер говорит, что он Chrome, но на уровне сетевого стека возникают расхождения с поведением реального Chrome.
Больше месяца назад Vision выкатил возможность проксировать QUIC. Добрался до тестов.
Что можно сказать сейчас: проверки на [networktest.twilio.com] и [browserleaks.com] проходят успешно, UDP-пакеты пробрасываются через прокси. Это значит, что софт научился имитировать работу реального стека протоколов Google.
Насколько качественно это реализовано "под капотом", без глубокого анализа сказать сложно. Поэтому я перевел часть профилей на "Проксировать QUIC" для эксперимента.
На деле же нужны полноценные тесты: от регистрации Gmail-почт до залива в Google Ads.
Что в теории дает поддержка QUIC?
1. Траст среды: Ты не выделяешься из толпы. Обычный Chrome в 2026 году по умолчанию использует QUIC. Если у тебя его нет - это аномалия для антифрода.
2. Стабильность сессий: QUIC лучше держит соединение при смене IP на мобильных прокси (меньше "вылетов" из аккаунта за счет технологии Connection Migration).
Чем опасна кривая реализация?
Это гораздо больший триггер, чем полное отсутствие UDP. Если антик или прокси "лагают", возникают ошибки протокола (например, ERR_QUIC_PROTOCOL_ERROR). Для Google это сигнал: перед нами либо бот, либо кривой софт.
Нужно понимать: QUIC - это родной протокол компании Google, ими же разработанный еще в 2012 году. Наивно полагать, что они не знают его досконально и не видят малейших расхождений в поведении вашего браузера.
Стоит ли сейчас срочно переходить на Vision, включать QUIC и скупать UDP-прокси? Конечно, нет. Это пока история для тестов на паре десятков профилей. Особенно если у вас и так все летит - не ломайте то, что работает.
Даже если первичные тесты выглядят лучше, это все равно не повод для массового перехода: Google не принимает решения по одному сигналу и не "стреляет" мгновенно.
Сетевое поведение, как и другие параметры, накапливается со временем, и именно на совокупности данных принимаются флаги и дальнейшие действия.
То, что сегодня выглядит нейтрально или даже положительно, при масштабировании может внезапно стать общей точкой риска для всей сетки аккаунтов.
Массово переходить опаснее, чем остаться на текущем решении.
Помимо самого антика, огромный вопрос к качеству прокси: большинство стандартных HTTP/Socks5 на рынке просто блокируют UDP-трафик, и включение QUIC в таком случае только навредит.
В любом случае, "рынок антиков" не стоит на месте, и это радует.
QR-регистрация: заглядываем под капот SMS-подтверждения
Часто сталкиваетесь с ситуацией, когда нужно зарегистрироваться в сервисе с подтверждением через QR-код, но хочется понять, что именно происходит "за кулисами"? Собрал небольшое расширение для браузера.
Что это такое?
Это инструмент для разбора механики SMS-верификации. Расширение не отправляет сообщения за вас (SMS отправить придется руками), но оно показывает техническую подноготную процесса прямо в браузере/антике (не нужно сканировать реальным мобильным устройством).
Что вы увидите:
📱 Номер отправителя: Какой номер (или короткий номер) используется сервисом.
📝 Формат сообщения: Как именно формируется текст SMS.
Важные замечания:
Никаких гарантий стабильности или долгосрочного анализа аккаунтов не даю, т.к. массовых тестов не проводил.
Кому это надо?
Тем, кто хочет не просто слепо регистрироваться, а понимать какие параметры участвуют в проверке и как именно устроен процесс подтверждения.
Расширение работает в любом Chromium-браузере.
Инструкция: telegra.ph
Скачать: sourceforge.net
Часто сталкиваетесь с ситуацией, когда нужно зарегистрироваться в сервисе с подтверждением через QR-код, но хочется понять, что именно происходит "за кулисами"? Собрал небольшое расширение для браузера.
Что это такое?
Это инструмент для разбора механики SMS-верификации. Расширение не отправляет сообщения за вас (SMS отправить придется руками), но оно показывает техническую подноготную процесса прямо в браузере/антике (не нужно сканировать реальным мобильным устройством).
Что вы увидите:
📱 Номер отправителя: Какой номер (или короткий номер) используется сервисом.
📝 Формат сообщения: Как именно формируется текст SMS.
Важные замечания:
Никаких гарантий стабильности или долгосрочного анализа аккаунтов не даю, т.к. массовых тестов не проводил.
Кому это надо?
Тем, кто хочет не просто слепо регистрироваться, а понимать какие параметры участвуют в проверке и как именно устроен процесс подтверждения.
Расширение работает в любом Chromium-браузере.
Инструкция: telegra.ph
Скачать: sourceforge.net
🔥1
Обновил расширение, которое скачивает видео и картинки из FB Ad Library в самом высоком качестве. Сама методика выгрузки осталась прежней, так что обновление не обязательное - оно скорее немного расширяет возможности.
Изменения:
1. "Память" для сохранения
Теперь расширение запоминает, куда вы сохранили видео или картинку в прошлый раз, и при следующем сохранении предлагает эту папку по умолчанию.
2. Закладки на фанпейджи
Добавлена "звездочка" в интерфейсе креатива. Нажав на нее, можно добавить фанпейдж выбранного креатива в выбранную или созданную папку.
После добавления можно вернуться на сохраненную страницу и посмотреть все креативы (через кнопку вызова расширения).
Сохраненная страница не дублируется: если нажать на звездочку на нескольких креативах одной страницы - она добавится только один раз.
Важно: сохраняется именно страница, а не конкретный креатив.
3. Добавлены "Ссылки"
Появился соседний раздел "Ссылки", куда можно сохранять нужные ссылки. Ссылки, добавленные по умолчанию, можно удалить.
Закладки и ссылки можно экспортировать и импортировать. Импорт не затирает ранее добавленную информацию - то есть можно переносить JSON-файл с устройства на устройство.
При обновлении расширения можно сначала экспортировать Закладки и Ссылки, а затем импортировать их уже в новую версию.
Не уверен, насколько раздел "Ссылки" будет востребован именно внутри этого расширения - скорее это возможность хранить полезную информацию для работы с креативами. Если будет спрос, можно подумать о более отдельном решении.
Например, сделать обновляемую базу актуальных сервисов. Мне показалось, что такой формат удобнее (есть поиск по названию или URL), чем стандартные хромовские закладки.
Расширение бесплатное, работает локально и без обращений на сервер. Кину отдельным постом ниже.
Изменения:
1. "Память" для сохранения
Теперь расширение запоминает, куда вы сохранили видео или картинку в прошлый раз, и при следующем сохранении предлагает эту папку по умолчанию.
2. Закладки на фанпейджи
Добавлена "звездочка" в интерфейсе креатива. Нажав на нее, можно добавить фанпейдж выбранного креатива в выбранную или созданную папку.
После добавления можно вернуться на сохраненную страницу и посмотреть все креативы (через кнопку вызова расширения).
Сохраненная страница не дублируется: если нажать на звездочку на нескольких креативах одной страницы - она добавится только один раз.
Важно: сохраняется именно страница, а не конкретный креатив.
3. Добавлены "Ссылки"
Появился соседний раздел "Ссылки", куда можно сохранять нужные ссылки. Ссылки, добавленные по умолчанию, можно удалить.
Закладки и ссылки можно экспортировать и импортировать. Импорт не затирает ранее добавленную информацию - то есть можно переносить JSON-файл с устройства на устройство.
При обновлении расширения можно сначала экспортировать Закладки и Ссылки, а затем импортировать их уже в новую версию.
Не уверен, насколько раздел "Ссылки" будет востребован именно внутри этого расширения - скорее это возможность хранить полезную информацию для работы с креативами. Если будет спрос, можно подумать о более отдельном решении.
Например, сделать обновляемую базу актуальных сервисов. Мне показалось, что такой формат удобнее (есть поиск по названию или URL), чем стандартные хромовские закладки.
Расширение бесплатное, работает локально и без обращений на сервер. Кину отдельным постом ниже.
adsfinder-v2.0-beta.zip
48.9 KB
Adsfinder v2.0 beta
Как установить: Telegra.ph
Как установить: Telegra.ph
qr_mobile_opener_11032026.zip
60.7 KB
Обновил расширение, теперь умеет декодировать текст.
QR Mobile Opener
Версия: 11.03.2026
Инструкция: telegra.ph
QR Mobile Opener
Версия: 11.03.2026
Инструкция: telegra.ph
UAC в Google Ads и FB: что поменялось в 2026 году
Коротко по ситуации. Если смотреть на Google в этом году, требования стали жестче, а пространство для маневра заметно сократилось. Основная боль сейчас - именно связка "прилка + аккаунт".
Если раньше в большинстве случаев бан касался только приложения в сторе, то сейчас все чаще вместе с прилой вылетают и рекламные аккаунты Google Ads. Причем происходит это быстро. По ощущениям, логика стала более связанной: прила больше не живет отдельно от аккаунтов, которые ее крутят.
Апелляции - отдельная тема. Раньше на трастовых аккаунтах это действительно мог быть рабочий инструмент. Сейчас апелляция все чаще выглядит как дополнительный триггер. Даже если изначально приходит положительный ответ, через несколько часов может прилететь бан аккаунта. Складывается ощущение, что сам факт апелляции усиливает проверку.
Отдельно про стоимость и вход. С марта 2026 года Google ввел новые требования по сертификации.
Формально это направлено на борьбу со злоупотреблениями и массовыми схемами. На практике порог входа стал выше. Трафик ощущается дороже, а запуск новых прил через UAC стал значительно сложнее.
Лично для меня UAC сейчас скорее мертв, чем жив - по крайней мере в текущем формате. Тесты показывают, что запустить связку, пусть и с менее агрессивными креативами, заметно проще на сайт, чем на приложение. Разница в стабильности ощутимая.
FB
С FB не работаю, но по тому, что слышу от тех, кто продолжает лить, ситуация тоже постепенно усложняется. Meta официально говорит об усилении контроля и борьбе со злоупотреблениями. Подробно судить не могу, но общий вектор, судя по рынку, в сторону ужесточения.
Что это значит
Формат работы меняется. UAC в текущем виде стал значительно менее предсказуемым. Запуски через приложение сейчас выглядят более рискованными, чем через веб.
Выживают те, кто:
- автоматизировал процессы,
- работает массово,
- заранее закладывает короткий жизненный цикл аккаунтов,
- понимает, что именно с массовостью Google сейчас и борется.
Это не паника и не громкий прогноз. Просто констатация того, что рынок стал жестче. Возможно, это временный этап. Но на данный момент реальность выглядит именно так.
Коротко по ситуации. Если смотреть на Google в этом году, требования стали жестче, а пространство для маневра заметно сократилось. Основная боль сейчас - именно связка "прилка + аккаунт".
Если раньше в большинстве случаев бан касался только приложения в сторе, то сейчас все чаще вместе с прилой вылетают и рекламные аккаунты Google Ads. Причем происходит это быстро. По ощущениям, логика стала более связанной: прила больше не живет отдельно от аккаунтов, которые ее крутят.
Апелляции - отдельная тема. Раньше на трастовых аккаунтах это действительно мог быть рабочий инструмент. Сейчас апелляция все чаще выглядит как дополнительный триггер. Даже если изначально приходит положительный ответ, через несколько часов может прилететь бан аккаунта. Складывается ощущение, что сам факт апелляции усиливает проверку.
Отдельно про стоимость и вход. С марта 2026 года Google ввел новые требования по сертификации.
Формально это направлено на борьбу со злоупотреблениями и массовыми схемами. На практике порог входа стал выше. Трафик ощущается дороже, а запуск новых прил через UAC стал значительно сложнее.
Лично для меня UAC сейчас скорее мертв, чем жив - по крайней мере в текущем формате. Тесты показывают, что запустить связку, пусть и с менее агрессивными креативами, заметно проще на сайт, чем на приложение. Разница в стабильности ощутимая.
FB
С FB не работаю, но по тому, что слышу от тех, кто продолжает лить, ситуация тоже постепенно усложняется. Meta официально говорит об усилении контроля и борьбе со злоупотреблениями. Подробно судить не могу, но общий вектор, судя по рынку, в сторону ужесточения.
Что это значит
Формат работы меняется. UAC в текущем виде стал значительно менее предсказуемым. Запуски через приложение сейчас выглядят более рискованными, чем через веб.
Выживают те, кто:
- автоматизировал процессы,
- работает массово,
- заранее закладывает короткий жизненный цикл аккаунтов,
- понимает, что именно с массовостью Google сейчас и борется.
Это не паника и не громкий прогноз. Просто констатация того, что рынок стал жестче. Возможно, это временный этап. Но на данный момент реальность выглядит именно так.
Hide Click закрылся за 24 часа
На прошлой неделе, после небольшого шума, всего за сутки прекратил работу один из популярных клоакинг-сервисов - Hide Click.
В арбитражных чатах быстро начали обсуждать возможные причины, а заодно делиться альтернативами, особенно под Google. Версии звучат разные: от банальной нерентабельности до более очевидной - с учетом специфики сервиса, "к ним могли постучать".
Что можно сказать точно - сервис пользовался спросом. И формат "24 часа на то, чтобы перевести трафик в другое место" вряд ли можно назвать нормальным или плановым сценарием. Скорее всего, со временем реальная причина все равно станет известна.
На фоне текущих ужесточений это выглядит как давление извне. Поэтому вопрос, похоже, стоит ставить не "за что", а "кто следующий".
Например, одна из статей от известной за рубежом компании Infoblox говорит о том, что более 20% выявленных компанией Confiant нарушений в сфере рекламной кибербезопасности были связаны с использованием трекера Keitaro.
Это очень высокий показатель, особенно с учетом того, что речь идет о выборке с откровенно "черными" кейсами - трояны, кража криптокошельков, скам.
Если добавить сюда ниши, более близкие к классическому арбитражу - гемблинг (особенно UAC), нутра - этот процент, вероятно, был бы еще выше.
Да, Keitaro - всего лишь инструмент. Как автомобиль, который может доставить куда угодно. Но контекст всем понятен.
Похоже, что со временем арбитраж будет становиться все более закрытой и контролируемой средой.
На прошлой неделе, после небольшого шума, всего за сутки прекратил работу один из популярных клоакинг-сервисов - Hide Click.
В арбитражных чатах быстро начали обсуждать возможные причины, а заодно делиться альтернативами, особенно под Google. Версии звучат разные: от банальной нерентабельности до более очевидной - с учетом специфики сервиса, "к ним могли постучать".
Что можно сказать точно - сервис пользовался спросом. И формат "24 часа на то, чтобы перевести трафик в другое место" вряд ли можно назвать нормальным или плановым сценарием. Скорее всего, со временем реальная причина все равно станет известна.
На фоне текущих ужесточений это выглядит как давление извне. Поэтому вопрос, похоже, стоит ставить не "за что", а "кто следующий".
Например, одна из статей от известной за рубежом компании Infoblox говорит о том, что более 20% выявленных компанией Confiant нарушений в сфере рекламной кибербезопасности были связаны с использованием трекера Keitaro.
Это очень высокий показатель, особенно с учетом того, что речь идет о выборке с откровенно "черными" кейсами - трояны, кража криптокошельков, скам.
Если добавить сюда ниши, более близкие к классическому арбитражу - гемблинг (особенно UAC), нутра - этот процент, вероятно, был бы еще выше.
Да, Keitaro - всего лишь инструмент. Как автомобиль, который может доставить куда угодно. Но контекст всем понятен.
Похоже, что со временем арбитраж будет становиться все более закрытой и контролируемой средой.
😁1