Отчёт Директа показал пять конверсий, потом ноль, потом три. Все три запроса вернули 200 OK. Разбор трёх мест, где успешный ответ API не означает, что вы получили нужные данные, что операция выполнилась и что настройка совпала с замыслом.
Строка из документации n8n про возобновление с места остановки читается как гарантия перезапуска с точки сбоя. Проверка привела в ветку форума 2021 года, где смысл настройки объясняют иначе, - и дальше ещё в пять вопросов к движку автоматизации перед необратимым шагом. Все ссылки и даты сверки (27 августа 2026 года) - в тексте.
Можно ли с помощью AI самостоятельно создать полноценную рекламную кампанию в Яндекс Директе — от анализа продукта и семантики до объявлений и готовой кампании в кабинете — без постоянной помощи таргетолога?
Я сделал для этого плагин для Codex и Claude Code и на практике столкнулся с другой стороной задачи: как дать агенту достаточно свободы для такой работы, но сохранить контроль над аккаунтами, изменениями и рекламным бюджетом. В статье — о том, как устроен этот подход и какие ограничения пришлось заложить в систему.
У маркетолога застройщика есть скучный, но регулярный вопрос атрибуции: обращений за неделю стало меньше — это рынок просел или собственные кампании сломались. Ответ во многом лежит в поисковом спросе. Если люди в городе стали реже искать квартиры, дело в рынке; если ищут столько же, а заявок меньше — причина внутри воронки. Беда в том, что Wordstat отвечает на этот вопрос медленно: нужно руками перебрать десятки фраз, сложить их по региону, вычесть аренду и переходы на классифайды — и к обеду вместо ответа получить таблицу, которую ещё надо интерпретировать.
Мы ведём контекстную рекламу для застройщиков, упирались в этот вопрос постоянно и в итоге автоматизировали сбор, а результат выложили открытой страницей без регистрации: ежедневный индекс поискового спроса на новостройки по 15 городам-миллионникам и по России, по данным Wordstat, с рядами от 2018 года. Ниже — инженерная часть, а не витрина: как устроен фиксированный набор запросов и «чистый контур», почему дельты считаются только по закрытым периодам, что делать с ретро-правками источника и выбросами, и в каких именно местах эти цифры врут, если читать их в лоб.
Товарная кампания и смарт-баннеры Яндекс Директа не дают редактировать текст объявления в интерфейсе. Заголовок Директ берёт из тега <name> товарного фида, описание — из <description>, и оба тега писал сайт: под карточку товара, а не под рекламную ленту. В галерее видно около 35 знаков заголовка, жёсткий предел — 56, дальше Директ обрезает по символам. «Печеные яблоки, фаршированные медом и грецкими орехами» в объявлении выглядят как «Печеные яблоки, фаршированные медо».
Сайт при этом трогать нельзя: та же карточка ранжируется в поиске и стоит в чеке, у неё своя работа. Ниже — как мы вклинились между сайтом и Директом одним процессом на Node без базы данных, который хирургически подменяет ровно два тега в YML, зачем над генератором заголовков стоит валидатор с правилами модерации и человек на аппруве, и что из этого вышло за первые дни на реальном проекте: пекарня с доставкой по Москве, около пятисот позиций в фиде.
Текст пригодится, если у вас уже крутятся товарная кампания или смарт-баннеры на YML-фиде и заголовки в них выглядят как строки из накладной. Если товарных форматов ещё нет — эта статья про инженерную часть, не про запуск с нуля.
Центр межотраслевой экспертизы «Третий Рим» представил доклад о построении новой модели российской экономики, обеспечивающей рост ВВП на 3% в год и подъем благосостояния в стране. Доклад был весьма положительно оценен многими экспертами, однако искусственный интеллект в лице нейросети Алиса AI считает, что «какой-то рост благосостояния возможен, но устойчивого и сбалансированного улучшения качества жизни … вряд ли получится». Алиса права.
По мнению авторов доклада, представленного к заседанию Совета при президенте по стратегическому развитию и национальным проектам 19 августа, потенциал значительной части действовавших ранее факторов роста экономики России в настоящее время почти исчерпан. Они предложили новую модель экономики, которая позволит выйти на рост ВВП в размере 3% в год, и должна быть построена на семи столпах.
Чисто экономическая модель экономики неадекватна реальности
Это опережающее развитие регионов и внутреннего туризма; автоматизация, ИИ и рост производительности; платформизация – снижение транзакционных издержек; создание инфраструктуры новой экономики; перестройка системы подготовки кадров; обеление экономики; опора на частные инвестиции и потребление.
Авторы модели полагают, что основанная на этих столпах российская экономика должна сделать не столько шаг вперед, сколько шаг вверх: перейти на новую траекторию развития, где экономический рост напрямую трансформируется в повышение благосостояния и качества жизни населения.
Предложения выглядят очень привлекательно, особенно рассуждения о переходе на новое качество жизни. Но есть вопрос: откуда взялись эти семь столпов? Где список всех столпов, на которых стоит экономика, и какое место указанная выше великолепная семерка занимает в списке? Если, допустим, взять ВВП, то имеются таблички, в которых подсчитано, какой вклад в них внесла промышленность, какой сельское хозяйство, и т. д. по убывающей. Хотелось бы оценить подобным образом и семерку (в той степени, в которой это возможно, разумеется).
Представьте обычный feed на LazyColumn: новости, карточки, между ними рекламный баннер. Баннер загрузился, пользователь пролистал его вниз, затем вернулся обратно, и мерцание реклама грузится заново.
Ещё раз вниз. Ещё раз вверх. Ещё одно мерцание и загрузка.
На первый взгляд причина кажется очевидной: item покидает экран, rememberBannerAdState теряет состояние, Compose создаёт всё заново. Значит, достаточно сохранить BannerAdState за пределами item и проблема исчезнет.
Я тоже так подумал.
Не исчезла.
Мерцания остались.
С этого момента простой баг (?) интеграции Yandex Ads превратился для меня в небольшое расследование: пришлось разобраться, что на самом деле происходит с item внутри LazyColumn, как SubcomposeLayout переиспользует composition, почему это ещё не означает переиспользование AndroidView и какой lifecycle поверх всего этого построил Compose API Yandex Ads.
В итоге вопрос «почему баннер моргает?» оказался гораздо интереснее самого workaround.
Честно скажу, идея подключить вордстат к ИИ ко мне пришла достаточно спонтанно и скорее была вынужденной на тот момент необходимостью – у меня в команде сократили SEO специалиста и этот блок полностью лёг на мои плечи. Помимо всех оптимизаций и задач связанных непосредственно с самим seo тут же был и еще один масштабный пласт, дававший бизнесу много денег – seo блог и глоссарий.
Блог был полностью ориентирован на seo и на получение небрендового трафика и перформил очень хорошо. Для меня это означало то, что теперь мне придется его развивать и поддерживать самостоятельно.
Кто собирал ключи в вордстате знает, что помимо базовых функций есть всевозможные расширения в хроме, с помощью которого ключи можно собирать вместе и потом выгружать, но это все равно требует большого количества времени. Плюс к этому для начала все равно нужно ответить на вопрос "а на какую тему мне вообще собирать ключи?".
Такая вот преамбула. Как вы понимаете, дальше я пошел искать пути для аутсорса этой задачи в клод.
Документация Яндекс 360 API на 20 августа 2026 года перечисляет 17 сервисов, и раздела о вебхуках или подписке на события среди них нет; аудит-лог организации документирует 26 типов событий — двенадцать почтовых и четырнадцать дисковых. Кадровых и оргструктурных событий не документировано ни одного. Разбираю, что из этого следует тем, кто строит провижининг: чем располагает UserService_List для поллинга, почему isDismissed нельзя записать и что документация обещает при создании пользователя с занятым логином.
Вопрос, который я задал себе и своей команде: что произойдёт, если по одному сотруднику из кадровой системы прилетят два запроса на входящий вебхук? Ответ у меня есть с 20 августа 2026 года, и он укладывается в строку: два независимых запуска, движок их между собой не связывает, ключа дедупликации нет. Ниже — что из этого следует тому, кто прямо сейчас рисует схему обмена 1С с облачным офисом.
Компанию +Альянс основал я. Руковожу ею тоже я, а по существу занимаюсь одним: тем, чтобы кадровое решение доезжало до облачного офиса без человека посередине. Инструменты в тексте остаются безымянными, и наши, и сторонние: речь про требования к приёмнику входящих запросов. Яндекс 360 упомянут как платформа, на которой живут учётные записи, и как источник, который читатель откроет сам.
Сразу про слабое место текста. Всё, что сказано ниже про поведение движка автоматизации, — моя собственная фиксация ответов, а не публичный документ, на который можно дать ссылку. Проверить это можно только на стенде, поэтому такие утверждения я даю вместе с процедурой проверки. Зато про саму платформу есть открытая документация, и на неё я опираюсь дословно. Даты такие. Каталог триггеров и действий зафиксирован 30 июля 2026, история запусков 3 августа, контракт вебхука 20 августа, страницы документации Яндекс 360 API сверены тоже 20 августа 2026.
Большие языковые модели становятся неотъемлемой частью современных информационных систем. Корпоративные помощники, RAG-приложения, AI-агенты, генерация программного кода, автоматизация документооборота – всё чаще именно LLM становятся основным интерфейсом взаимодействия пользователя с данными и сервисами компании.
Вместе с ростом популярности меняется и профиль угроз. Если ещё несколько лет назад основной задачей злоумышленника был поиск уязвимости в веб-приложении или API, то сегодня достаточно правильно сформулировать запрос к языковой модели. Причём целью может быть не получение конфиденциальной информации и даже не обход механизмов безопасности. Иногда гораздо выгоднее заставить модель выполнять заведомо ресурсоёмкую задачу, расходуя процессорное время, память и тысячи токенов.
Именно этой проблеме посвящена категория LLM10: Unbounded Consumption в рейтинге OWASP Top 10 for LLM Applications. В отличие от классических атак типа Prompt Injection или Data Leakage, здесь злоумышленник воздействует не на логику приложения, а на его вычислительные ресурсы. По сути, речь идёт об адаптации идеи Denial of Service (DoS) к эпохе генеративного искусственного интеллекта.
На первый взгляд может показаться, что защититься от подобных атак достаточно просто – например, ограничить длину пользовательского запроса или максимальный размер ответа. Однако на практике современные атаки становятся значительно изощрённее. Они используют особенности работы больших языковых моделей: рекурсивные инструкции, экспоненциальный рост контекста, моделирование множества независимых агентов, комбинаторные задачи и другие приёмы, заставляющие модель выполнять непропорционально большой объём вычислений при внешне вполне безобидном запросе.
Данные о том, как поиск видит ваш сайт, живут в интерфейсе Яндекс Вебмастера и в его API: чтобы узнать, по каким запросам показов много, а кликов нет, что выпало из индекса за месяц и что Яндекс считает проблемой сайта, человек ходит по вкладкам и сводит цифры руками, а программа собирает запросы к API v4. LLM-агент по умолчанию не умеет ни того, ни другого.
Разбираю, как устроен MCP-сервер для Яндекс Вебмастера: как уложить пару десятков эндпоинтов в восемь инструментов, какие грабли у API v4 и как сделать вход в Яндекс, который агент выполняет сам — без терминала и без клиентского секрета.
Недавно на сайте одного из клиентов мы с командой по всем правилам поставили speakable — разметку, которая подсказывает голосовому ассистенту, какие куски страницы читать вслух: короткий ответ в начале, три ответа из FAQ, всё в валидном коде, а селекторы точно на нужных блоках. Алиса зачитывала ответ ноль раз. Причина оказалась глубже разметки: страница висела на 14-м месте обычной выдачи Яндекса. Ниже разбираю, как размечать под голос правильно, на что это реально влияет и на каких граблях я терял время.
Месяц назад закончилась тренировка DATA DOJO от Яндекса. Здесь я бы хотел рассказать про ключевые аспекты соревнования, моё решение на топ-6%, авторские идеи и, конечно, про реальный путь к победе.
Мастер отчётов в Директе отдаёт один срез за запрос. Хочешь сравнить расход по площадкам — строишь один отчёт; нужна понедельная динамика стоимости лида — строишь второй; смотришь, какая кампания просела — третий. Между несколькими клиентскими логинами добавьте ещё перелогины. Картина всего аккаунта в этой схеме существует только в голове аналитика, и каждое утро её приходится пересобирать заново.
Мне это мешало достаточно, чтобы потратить вечер и вытащить данные напрямую из Reports API в Google-таблицу: один лист — весь аккаунт по неделям, рядом разрезы по площадкам и по каждой кампании, плюс подневное скользящее окно. Обновляется само через Apps Script. Ниже разберу, как это устроено под капотом, где у конструкции стенки (их хватает) и почему свои боевые дашборды я в итоге всё равно унёс в DataLens. Таблица — пустой шаблон, отдаю по ссылке в конце, можно скопировать и распотрошить.
Адресат — те, кто сам копается в Директе и аналитике. Написали такой инструмент — будет с чем сверить решения; только думаете — сэкономите вечер на граблях.
Кампания с недельным бюджетом 10 000 ₽ в нише, где заявка стоит около 5 000, не обучится никогда — и автостратегия тут ни при чём. Ей просто не на чем учиться: за неделю она не наберёт даже двух заявок, а без набранных заявок look-alike нечем строить закономерность. Это школьная арифметика, и желание заказчика на неё не влияет.
Я веду Яндекс Директ в недвижимости, и почти любой спор «автостратегии всё сливают» против «ручное управление умерло» у меня на глазах сводится к одному инженерному вопросу: наберёт ли алгоритм достаточно размеченных данных, чтобы обучиться в этих конкретных условиях. Стоит посмотреть на автостратегию как на классификатор, которому нужна минимальная обучающая выборка положительных примеров за единицу времени, — и половина мифов вокруг неё отваливается сама.
Дальше — как этот классификатор устроен под капотом (упрощённо, детали Яндекс не раскрывает), почему ему нужен объём, где вместо него честнее ручные ставки и как «удобная» цель тихо ломает всю оптимизацию. В конце — таблица по шести типовым сценариям недвижки. Если у вас поток в сотни конверсий в неделю, большая часть проблем ниже вас не касается: там автостратегии просто работают, и это нормально.
«Реклама не работает» — фраза, которую я слышу от застройщиков чаще любой другой. За ней почти всегда стоит одно: бюджет откручивается, заявки капают, а сделок мало. И первая реакция предсказуемая — добавить денег или сменить подрядчика.
Я решил разобрать эту жалобу на данных: взял 24 месяца помесячной статистики Яндекс Вордстата по Башкортостану и Уфе плюс срез по 109 активным жилым комплексам Уфы. Ниже — что реально видно в этих цифрах, три механизма, из-за которых кампания «буксует», и отдельно то, ради чего эту статью стоит дочитать аналитику: где данные Wordstat нельзя читать в лоб и как я на этом сам мог бы ошибиться.
Адресат — те, кто сам собирает семантику и настраивает кампании в нише недвижимости. Бизнес-рамку («как это влияет на ваши продажи») я убрал — она на сайте. Здесь разговор про методологию: как режется спрос, какие доли из этого можно считать, а какие нельзя.
Есть данные, которые вроде бы доступны, но программно их не взять. Они отображаются в браузере, их видно на графиках, по ним можно кликать мышкой. Но API для них либо не существует, либо он закрыт.
Раньше это означало ручной анализ: открываешь плеер, смотришь, как пользователь скроллил страницу, на чем задерживался и где кликал. Триста посещений — триста раз открыть плеер. А если нужно проанализировать поведение за месяц с тысячами визитов, задача превращается в нерешаемую. Теперь эту работу можно делегировать агенту.
Классический пример — Вебвизор Яндекс.Метрики. Посещения, скроллы, клики — все это можно смотреть в плеере, но выгрузить поведение пользователей штатными средствами нельзя.
Приветствую, Хабр!
В этой статье хочу описать практический кейс, который выглядит не как единичная ошибка на карте, а как системная проблема в работе навигационного сервиса от Яндекса. Речь идет о маршрутах в городе Дербент, где одна из дорог была перекрыта еще в марте 2026 года в связи с ремонтными работами (строительство сегмента центральной набережной города). Сейчас уже 23 июня 2026 года, прошло почти 4 месяца, но навигатор продолжает строить маршруты так, как будто проблемы не существует.
На первый взгляд это может показаться локальной городской неудобностью: где-то перекрыли дорогу, где-то маршрут стал длиннее, кто-то потратил лишние несколько минут. Но в реальности проблема серьезнее. Если навигатор отправляет водителей по маршруту, которого физически не существует, или ведет по дороге в таком состоянии, что там можно оставить колеса и всячески игнорирует попытки пользователей внести в маршрут корректировки - это уже не просто неточность данных. Это вопрос безопасности, качества сервиса и способности платформы реагировать на обратную связь.
Веб-аналитика живёт за дашбордами и HTTP-API: чтобы узнать, откуда пришёл трафик за неделю, человек лезет в интерфейс Метрики, а программа — собирает запрос к Reporting API и держит в голове namespace полей, лимиты и форматы ответа. LLM-агент (Claude, модель в Cursor, любой другой) по умолчанию не умеет ни того, ни другого.
Мостом между агентом и внешней системой служит MCP — Model Context Protocol. Разбираю, как устроен MCP-сервер для Яндекс.Метрики: как уложить отчёты в небольшой набор инструментов, как авторизоваться в Yandex ID без клиентского секрета (это оказалось самым неочевидным) и на какие грабли Reporting API я наступил по дороге.
