VK Ads

Сам кабинет VK Ads подключается двумя способами: через обычный вход VK или по Client ID + Client Secret из настроек доступа клиента. Во втором случае LidFly сам получает и обновляет токены, а в кабинете показывает статус «Полный доступ».

Для новых подключений используйте единый endpoint /mcp/v3. Полный VK endpoint /mcp/vk остаётся для legacy/advanced сценариев. Все meta-инструменты из tools/list, включая get_provider_context, resolve_campaign_scope, search_skills, get_skill и get_skill_resource, AI вызывает напрямую; в call_tool/call_write_tool передаются только внутренние инструменты, найденные через search_tools. Для сложных сценариев, включая goal_mode, skill-ответ возвращает точную версию и digest подписанного workflow, не расширяя права и scope.

Через то же подключение внешний ИИ может читать личную переписку инструментами support_get_messages/support_get_attachment. При неожиданной внутренней ошибке read-only support_prepare_report создаёт очищенный черновик с incident ID и ничего не отправляет. ИИ показывает его пользователю и только после явного текстового согласия вызывает support_send_error_report (отчёт разработчикам) или support_send_message (обращение в поддержку); при необходимости до пяти изображений загружаются через support_request_image_upload. Выбранный VK-кабинет не меняет владельца диалога.

Если доступно несколько VK Ads подключений или кабинетов, AI сначала вызывает get_provider_context. Если известна кампания, resolve_campaign_scope принимает точный ID или полное точное название и сначала проверяет Пространства. Поиск по названию последовательно читает страницы VK до конца в общем ограниченном бюджете времени; timeout или неполная пагинация возвращают incomplete, а не ложный результат об отсутствии. Затем AI передаёт в рабочие инструменты точные workspace_project_id, connection_id и при необходимости client_id. Campaign write без workspace_project_id проходит только когда call_write_tool preflight по campaign id нашёл единственный Workspace/provider scope. Для собственного кабинета нужен только connection_id. Если пользователь явно добавил VK user ID из переключателя, LidFly использует скрытый _user_id для чтения и ограниченных write-действий.

После OAuth или подключения по Client ID + Client Secret LidFly сохраняет отдельное VK Ads подключение, синхронизирует его основной кабинет, клиентов агентства и клиентов менеджера, показывает уровень доступа и позволяет выбрать рабочий кабинет ИИ. Встроенный чат, /mcp/v3, /mcp/vk и /mcp/vk/lite автоматически передают нужный connection_id, а для клиентского кабинета ещё и client_id.

Для новых подключений используйте OAuth или Client ID + Client Secret. Если старое подключение уже было создано по готовому access token, в его карточке «Сохранённый доступ» остаётся поле для замены истёкшего токена.

Важно: OAuth подключает не выбранный в верхнем меню кабинет VK Ads, а VK-пользователя, который подтвердил доступ. Если в браузере можно переключиться на кабинет клиента, но после «Найти кабинеты VK Ads» он не появляется в LidFly, значит VK API не отдаёт этот кабинет как клиента агентства или менеджера для текущего токена.

Для таких случаев в личном кабинете есть ручное добавление VK user ID из переключателя VK Ads. VK Ads API не показывает список этих скрытых клиентов отдельным методом, поэтому ID вводится вручную один раз. LidFly проверяет доступ к объектам через недокументированный фильтр _user_id и дальше подставляет этот фильтр автоматически для чтения и ограниченных write-действий.

Стоимость зависит от числа доступных ИИ кабинетов. Актуальные условия — на странице тарифов.

Если клиентский кабинет — отдельный VK-логин, подключите его дополнительным OAuth либо попросите клиента передать Client ID и Client Secret из настроек доступа VK Ads. При подключении по ключам LidFly получает токены серверно, обновляет их автоматически и даёт встроенному чату и MCP полный доступ к чтению и редактированию в рамках прав VK Ads.

Если кабинет должен быть доступен через агентство или менеджера, он должен вернуться из agency/clients.json или /api/v3/manager/clients.json. Ручной ID из интерфейса VK Ads не заменяет official API-доступ: для agency_client_credentials нужен user id клиента из AgencyClients/ManagerClients, иначе VK отвечает Unknown client.

Переключение sudo в браузере VK Ads не равно official API-доступу. Но если клиент виден в переключателе, можно добавить его VK user ID в LidFly: чтение кампаний, групп и объявлений пойдёт через скрытый _user_id. Объектная статистика и realtime в таком manual режиме зависят от VK API и могут возвращать пустые или нулевые данные; тогда LidFly подставляет доступный агрегат кабинета через statistics/users и faststat/users. Для надёжной детализации по кампаниям, группам и объявлениям нужен official agency/manager API-доступ или отдельный VK OAuth клиента. В manual режиме можно менять max_price и статусы через mass-action, часть полей кампаний (budget_limit, budget_limit_day, даты, max_price) и название лид-формы. price групп, создание, загрузка креативов и single update объектов требуют official agency/manager API-доступ или отдельный VK OAuth клиента.

Для групп с автостратегией max_goals ставочный лимит меняется через max_price. Обычное поле price может дать успешный ответ API, но остаться прежним при проверочном чтении.

Добавлена диагностика статистики мини-приложений, включая сценарии Senler: агент отличает подписку в приложении от social_network.vk_subscribe, находит приложение, трекер, событие и сверяет результат с колонкой «Результат» в интерфейсе VK Ads.

Разбор с примерами использования

vk_get_campaigns показывает новые кампании первыми. Если VK вернул только часть списка, результат содержит пометку «НЕПОЛНАЯ ВЫБОРКА» и следующий offset — ИИ продолжает пагинацию и не делает выводы по одной странице.

Пустой ответ VK Ads API помечается как not_observed — это отсутствие наблюдения в проверенном кабинете, а не доказательство того, что кампаний нет. Тот же контракт используют инструменты кампаний Яндекс Директа, поэтому ИИ не выдаёт неполную проверку за пустой кабинет.

vk_prepare_campaign безопасно проверяет полный payload без записи: фактические paid_event_type/priced_event_type, goal_mode, совместимость стратегии и max_price, бюджеты и даты, формат возраста, CTA и реальные массивы options.targetings/options.settings выбранного пакета. goal_mode=required требует валидную именованную цель кампании или группы, forbidden запрещает её, unsupported останавливает запись. Цель нельзя требовать только из-за site_conversions или наличия options.settings.priced_goal. priced_event_type=41, включая пакет 3122 «Вступить», и priced_event_type=51 для лид-формы — фиксированные события с goal_mode=forbidden: priced_goal не передаётся. ID лид-формы не является PricedGoal.source_id. Пакет 3509 с priced_event_type=0 также не является goal-оптимизированным.

При несовместимости preflight возвращает package_priced_goal_forbidden, package_priced_goal_required или package_goal_policy_unsupported до POST. LidFly не удаляет цель автоматически: ИИ предлагает согласовать выбранное фиксированное событие пакета без именованной цели либо совместимый goal/oCPM-пакет. Создание группы проверяет только goal-policy пакета и родительской кампании, оставляя окончательную package-валидацию VK. Обновление общей цели кампании проверяет пакеты групп с пределом 20 страниц/1000 групп; повтор страницы или незавершённая проверка возвращает campaign_goal_policy_scan_incomplete без POST.

ready=true означает успешный локальный и каталоговый preflight, но окончательную проверку всего payload выполняет VK только при создании. После подтверждения vk_create_campaign повторяет проверку, принимает ровно одну bootstrap-группу без баннеров и создаёт кампанию с группой только в статусе blocked. Вложенные баннеры запрещены и при отдельном создании группы.

Перед каждым объявлением vk_prepare_banner перечитывает группу, package, площадки, допустимые patterns, banner fields, CTA и тип URL. Связь площадок с шаблонами берётся из матрицы package.options.targetings.pads.patterns; PackagesPads служит только запасным источником, потому что VK может не вернуть в нём patterns. Поле pattern_relation_source показывает использованный источник, а неполный каталог не выдаётся за ошибку креатива. Только ready=true и normalized_arguments допускаются в vk_create_banner. Новый баннер всегда создаётся blocked. POST выполняется один раз; при timeout/5xx результат проверяется по журналу и GET readback без автоматического повтора. Два баннера в группе — A/B-варианты, а не последовательный показ видео.

Для event 51 порядок такой: vk_get_packages → vk_prepare_campaign → blocked-create без priced_goal → vk_get_lead_forms → vk_prepare_banner с внутренним URL https://vk.com/leadads/form/<id>. Пока URL-only контракт не подтверждён на выделенном тестовом кабинете, preflight возвращает lead_form_binding_unverified и не выполняет запись. Недокументированное content.lead_form_id не подставляется.

До POST LidFly сохраняет журнал операции и безопасный verification context без рекламных текстов, raw URL, payload и токенов. Детерминированный отказ VK сохраняется как очищенный provider_error — та же причина доступна через get_write_operation_status. При unknown/ambiguous status-tool делает только GET. Нужная защитная остановка кампании или баннера возвращается как отдельный подтверждаемый next_write.

Создание standalone Look-alike через документированный публичный VK API недоступно. LidFly не подменяет его списком ремаркетинга и не использует seed segment как ID готовой LAL. Похожую аудиторию нужно создать в интерфейсе VK Ads, дождаться готовности и затем использовать её собственный ID в связи сегмента.