Чем журнал изменений в Директе отличается от выгрузки Changes

14.10.2026 · 8 мин чтения

В кабинете Яндекс Директа вкладка истории читается как дневник: кто и когда поменял минус-фразы, бюджет или объявление. Выгрузить эту ленту методом API нельзя. Сервис Changes присылает только сигнал, что объект трогали. Фразу для клиента я собираю из своего снимка настроек: сохраняю состояние до правки и сравниваю его с состоянием после.

В рекламном кабинете я открываю вкладку, когда нужно вспомнить живую правку. Там видно, кто тронул минус-фразы, кто сдвинул бюджет и кто переписал объявление. Это человеческий журнал. Его читает любой сотрудник, у которого есть доступ к кабинету. Запрос про выгрузку истории изменений аккаунта почти всегда про эту ленту: забрать дневник и положить его в отчёт или отдать агенту. Я сам сначала хотел ровно этого.

API так не умеет. Документация описывает другие сущности, а не экран интерфейса. Вкладка через методы не проброшена. Честный ответ на выгрузку «как в кабинете» у меня один: никак. Журнал остаётся на экране. В рабочий контур я забираю сигнал Changes и свой эталон объектов. Путать эту память с аудитом перед запуском не стоит. Аудит отвечает, можно ли стартовать. Здесь я помню, что уже меняли в живом ведении.

Новый Мастер отчётов в интерфейсе тоже не замена. Срез экрана не становится журналом и не становится снимком объектов. Одну задачу я не закрываю соседней вкладкой.

Журнал отвечает, кто нажал. Changes отвечает, трогали ли объект. Снимок отвечает, что именно стало другим. Пока у меня есть только сигнал, фразу «добавили минус-фразы в кампанию» я не пишу. Для неё нужна разница двух состояний. Разговор про оптимизацию и про эффективность в письме клиенту держится на этой разнице, а не на сыром логе. Если второй половины нет, отчёт либо молчит, либо начинает додумывать.

Сервис Changes раскладывает события на три среза: сам объект, его потомки и статистика. В документации это типы, окна и объекты, читается сухо. Для работы мне нужен смысл среза, а не пересказ справочника. Каждый срез — детектор. Он говорит, что что-то менялось. Он не пишет, какую фразу добавили и кто это сделал. Имя сотрудника и текст правки остаются во вкладке. Без прошлого снимка из детектора человеческую фразу не собрать.

SELF я читаю как сигнал про сам объект, который запросил. Менялись его собственные параметры, и я открываю эталон этого объекта, а не соседние сущности. CHILDREN я читаю как сигнал про потомков: менялось то, что живёт внутри, и сверка только карточки родителя здесь врёт. STAT я читаю как сигнал, что менялась статистика. Это не правка настроек. Цифры приезжают своими методами, и я не записываю STAT в список решений за неделю. Срез только выбирает, какой кусок снимка открыть.

Журнал остаётся в кабинете. Changes присылает только тип сигнала.

В день правки я не начинаю с журнала. Сначала файл «было», потом сама правка, потом файл «стало», и только затем смотрю, какой срез загорелся. Снимок для меня не скрин кабинета и не полный дамп. Это выгрузка объектов, о которых я потом пишу клиенту. В эталоне кампании, ключевые фразы, бюджет и стратегия. Беру их методами в духе Campaigns.get и Keywords.get. Состав полей один и тот же на обоих съёмах.

На качественную еженедельную выжимку я закладываю одну или две недели, пока накопится слой «было». Если завести контур потом, сравнивать будет не с чем. Поэтому эталон появляется в ту же неделю, когда я впервые отдаю автоматический отчёт. Статистика кампании без слоя «что правили» остаётся набором цифр, которые клиент и так открывает в кабинете.

Регламент у меня на двоих. Один человек отвечает за эталон и следит, чтобы набор полей не плыл. Второй пишет текст выжимки и не подменяет файлы догадкой. Если оба правят состав каждую неделю, сравнение ломается: то нет ключей, то нет бюджета. Набор я фиксирую один раз и меняю осознанно, как скоупы приложения, а не на глаз после созвона.

Эталон до правки и повторный съём после неё я держу одним составом полей.

Когда контур только стартует, прошлого снимка нет. Тогда я беру старый клиентский PDF или Excel и говорю: вот как мы описывали настройки раньше. Новый съём сравниваю с этим слоем. Это костыль на старт, не замена регулярного эталона. Через одну или две недели его должен сменить съём из API. На месяцы старый файл единственным контуром я не оставляю: он помнит прошлую подачу, а не текущие объекты. Как только второй файл того же состава уже есть, сравнение идёт только между ними.

Получение токена и сервис Reports я уже разобрал в статье про API. Здесь тот же вход и ничего больше про выдачу доступа: технический логин, одобренная заявка и токен сотрудника, которым я хожу и за цифрами. Отдельный ключ только на историю Яндекс не выдаёт. Отдельного ключа только на Changes тоже нет. Кто обещает выгрузить ленту кабинета отдельным методом, продаёт ожидание, которого в API нет. Если доступ обновляю, обновляю сразу оба контура, и отчёт, и память настроек. Дальше в этом тексте только история изменений.

Через API я не редактирую Мастер кампаний. Это тип кампании, а не новый Мастер отчётов в интерфейсе. Интересы аудиторий через API не правлю. Товарную кампанию целиком тоже не правлю. Если решение приняли руками в таком месте, разница ключей и бюджета его не покажет. К файлам я тогда добавляю короткую пометку. Список решений за неделю собирается из разницы снимков плюс эти пометки. Из одной вкладки честный список не собрать: вкладка по API не едет.

Экран настроек API в кабинете показывает статус заявки и остаток баллов. Это не журнал правок. Параметры говорят, что доступ открыт. История в интерфейсе говорит, кто нажал. Снимок говорит, что стало другим. Три слоя я держу отдельно и не подписываю один другим. Клиенту пишу прямо: человеческую ленту кабинета не выгружаем, зато каждую неделю видим разницу объектов. Так ожидание журнала не протекает в отчёт.

Доступ, журнал кабинета и снимок объектов я проверяю как три разных слоя.

Если объявления правили руками, а снимок хранит только ключи и бюджет, фраза «ничего не меняли» формально верна и фактически ложна. Состав полей обязан совпадать с тем, о чём я обещаю писать. Иначе отчёт молчит там, где правка была, или додумывает то, чего в двух файлах нет.

Курсы по API чаще учат методы и молчат про вкладку. После такого разбора легко решить, что доступ плохой, раз дневник не скачивается. Доступ здесь ни при чём: вкладки в методах нет. Рабочий обход один — эталон объектов и одна или две недели, пока есть с чем сравнивать. Расширение браузера, которое обещает скачать журнал, я в контур не ставлю: оно часто ломает доступ. Живу на официальных методах и своём снимке, и тогда письмо не врёт, когда минусы добавили накануне вечером.

SEO

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