Яндекс API *

Честно скажу, идея подключить вордстат к ИИ ко мне пришла достаточно спонтанно и скорее была вынужденной на тот момент необходимостью – у меня в команде сократили 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 я наступил по дороге.

Наш любимый доходяга Яндекс частенько показывает вверху выдачи готовый ответ и ссылается в нём на три‑четыре сайта. При этом по такому же запросу в обычной выдаче сотни, а то и тысячи страниц. Позвольте спросить, по какому такому принципу нейроответ отбирает из этих сотен именно те самые избранные, которые собирают весь куш? Я решил проверить свои (бестолковые) гипотезы на реальных данных.

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

Сразу про масштаб. Это одна ниша и всего 60 обращений, так что на вселенскую истину я не претендую, хотя очень хотелось бы. Но даже на таком объёме картинка получилась на удивление устойчивой, пусть и не такой, как мнение Греты Тунберг обо всём на свете.

Управление контекстной рекламой — это много механической работы. Открыть статистику, выгрузить срез, свести два периода в таблице, заметить просевшую кампанию, пойти в другой отчёт, поднять минус‑слова, вернуться, поправить ставку. Каждый шаг по отдельности занимает приличное количество времени, с учетом того, что в больших РК этот процесс еще и подвисает (буквально подвисает, на больших отчетах статистика может грузиться минуты). Все вместе половина рабочего дня уходит на то, чтобы просто понять, что происходит в аккаунте. И таких аккаунтов у специалистов/фрилансеров обычно больше одного, у меня сейчас, например — 7.

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

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

Последние полгода я достаточно активно работал с различными ИИ и решил, что созрел на то что бы сделать свой сервис, который снимет эти проблемы. Логика, как я её видел, должна была быть простой — даёшь ИИ доступ к АПИ Директа, а дальше он сам делает всю магию, и я просто запросами в чате получаю все необходимые данные и управляю кампаниями.
Что может быть проще?)

Я работаю в контекстной рекламе и аналитике пять лет. Когда популярное расширение xml-river перестало работать, у тысяч специалистов сломался привычный сбор семантики через KeyCollector. Я решила проблему локально: написала десктопную программу на PySide6, которая напрямую работала с новым официальным API Wordstat. Программа продавалась с пожизненной лицензией, а пользователи ходили в API под моим личным токеном. Всё работало отлично, пока клиентов не стало слишком много: общий лимит в 5000 запросов в сутки превратился в массовые ошибки 429 Too Many Requests. Стало ясно: модель с общим токеном доживает дни. В этом посте — технический разбор того, как я за одну неделю полностью переписала архитектуру, перевела парсер на SaaS-модель (FastAPI + SQLite) с независимыми квотами для каждого пользователя. С кодом, схемами и честной юнит-экономикой

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

Я купил Яндекс Алису Макс и Алису Про. Для русского языка альтернатив толком нет: Amazon Echo, Apple HomePod, Google Nest, всё это про русский знает в лучшем случае на троечку. Яндекс другое дело: русская речь, русская музыка, русские команды, всё работает из коробки.

Но если зайти в Яндекс Диалоги и посмотреть, что там за навыки, становится грустно. Математические задачки, ролевые игры, сказки. Мёртвый продукт из эпохи до ChatGPT. Я смотрел на это и думал: ну ребята, можно же сделать что‑то живое.

Так появилась идея навыка генерации музыки. Говоришь «создай песню про море», ждёшь минуту, и Алиса её играет.

На всё ушло два вечера. У меня уже был готовый шаблон инфраструктуры и пара похожих pet‑проектов, так что я не начинал с нуля.

Всем добра! Речь пойдет о ресивере Yamaha RX-V575 и телевизоре Samsung UE50F6800AB. Оба устройства не первой свежести, более того, телевизор имеет устаревший и не развиваемый более интерфейс. Однако, полученные результаты могут оказаться полезными для владельцев множества других устройств Yamaha и Samsung. Не все ведь меняют технику ежегодно :)

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

Сразу оговорюсь, что не стоит дальше читать, если вы:

Понадобилась мне семантика - не в смысле «один раз глянуть Wordstat в браузере», а программно, чтобы прогонять по 50-100 фраз в день и складывать результаты в свою базу. Контекст: веду контент-маркетинг для агентства разработки чат-ботов BotKraft, статьи под Яндекс Нейро. Веб-Wordstat для такого объёма не вариант - копировать вручную из таблички полдня. Direct API - слишком дорогой вход: нужен рекламный аккаунт, отдельный OAuth, у меня этого не было и заводить ради одного метода не хотелось.

Случайно полез в новые сервисы Yandex Cloud AI Studio (там сейчас живёт YandexGPT) и обнаружил, что Wordstat теперь есть в Search API v2 - отдельным сервисом без зависимости от Direct. Доступ - обычный API-ключ из AI Studio, тот же что и для YandexGPT. По сути в один клик получаешь ещё и доступ к семантике.

Подключал, по дороге собрал коллекцию граблей. Этим и поделюсь.

Универсальный шлюз для работы с разными голосовыми помощниками и разными умными домами и умными устройствами.