От AI-чатов к воспроизводимому ASO-процессу

ASO-специалист экспортирует отчёт по ключевым словам, открывает AI-чат и получает перспективное предложение по метаданным. Второй специалист повторяет задачу в другом AI-инструменте с немного изменённым промптом. Через несколько недель никто не может ответить на четыре простых вопроса:

• Какие данные анализировал AI?
• Каким инструкциям он следовал?
• Почему одно предложение приняли, а другое отклонили?
• Что в итоге изменили в Store?

Проблема не в качестве AI-модели. Проблема в том, что чат используется как система хранения решений.

Надёжнее организовать ASO как проверяемый production-процесс. До анализа через ASO.dev подготавливается текущий baseline приложения — экспортом или через MCP. Затем специалист собирает нужных для задачи конкурентов и ключевые слова, а их источники вместе с промптами, отчётами и решениями сохраняются в Git. LLM анализирует эти известные входные данные, а перед финальным действием результат обязательно проверяет человек.

Так отдельный AI-диалог превращается в процесс, который вся команда может изучить и воспроизвести.

О терминологии: в 2025 году Apple переименовала Apple Search Ads в Apple Ads. В этой статье используется актуальное название, хотя в именах экспортов и исторических отчётах ещё могут встречаться «Apple Search Ads» и «ASA».

У каждого компонента должна быть одна понятная роль.

Сам процесс намеренно прост:

Текущие данные приложения из ASO.dev
(экспорт и/или MCP)
    ↓
Исследование задачи в ASO.dev
(ручной и автоматический поиск конкурентов,
Spy, ключи конкурентов, поиск органических ключей)
    ↓
Ветка задачи с описанием данных
    ↓
LLM-анализ по версионируемому промпту
    ↓
Отчёт и предложение метаданных
    ↓
Проверка через ASO.dev MCP и кросс-локализацию
    ↓
Ревью Pull Request
    ↓
Ручное одобрение и финальное действие
    ↓
Применённый результат зафиксирован в Git

Экспорт и MCP — не взаимоисключающие источники. Перед началом работы ASO.dev позволяет подготовить текущий baseline приложения любым из двух способов: экспорт даёт команде фиксированный файл, а MCP — поддерживаемые live-данные выбранного приложения. Можно использовать один способ или объединить оба. Если baseline получен через MCP, зафиксируйте использованные значения и время получения в задаче, чтобы анализ оставался воспроизводимым.

Следующий слой — данные конкретной задачи. В ASO.dev специалист может добавить известных конкурентов вручную, воспользоваться автоматическим поиском конкурентов и собрать кандидатов в ключевые слова через Spy, анализ конкурентов, поиск ключей и поиск органических ключевых слов. Проверенные результаты этих инструментов становятся входами pipeline. Для каждого входа нужно сохранить источник, дату, Store, страну и применённые фильтры.

AI-чаты удобны как рабочая среда, но плохо подходят для командного хранения результатов.

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

Скриншот или CSV без описания не фиксирует дату экспорта, рынок, язык, период, полноту и фильтры. Без этих сведений правдоподобную рекомендацию всё равно невозможно нормально проверить.

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

Фраза «выглядит хорошо» в чате не показывает, какой именно title, subtitle, keyword field, изменение ставки или список минус-слов был утверждён.

Git сам по себе не делает анализ правильным. Он делает входные данные, правила, результат и решение достаточно прозрачными для проверки.

Для старта не нужен большой платформенный проект. Достаточно небольшого приватного репозитория:

aso-workspace/
├── README.md
├── AGENTS.md
├── apps/
│   └── my-app/
│       ├── app-context.md
│       ├── exports/
│       ├── reports/
│       └── proposals/
├── prompts/
│   └── metadata-optimization.md
├── workflows/
│   └── metadata-update.md
└── templates/
    └── pull-request.md

У этих файлов разный жизненный цикл:

• app-context.md содержит относительно стабильный контекст продукта и бренда;
• exports/ хранит датированные снимки или манифесты со ссылками на защищённое хранилище;
• prompts/ содержит переиспользуемые инструкции для анализа;
• workflows/ определяет необходимые входные данные, результат, проверку и правила одобрения;
• reports/ и proposals/ содержат датированные результаты задач, а не один постоянно перезаписываемый файл final.

Инструкция для агента должна быть короткой и однозначной. Она должна требовать от LLM:

1. прочитать контекст приложения и подходящий workflow до начала работы;
2. указать, получен ли текущий baseline приложения через экспорт ASO.dev, MCP или оба способа, и зафиксировать время получения;
3. указать источник, дату, Store, страну, язык, период и фильтры каждого выбранного исследовательского набора;
4. считать зафиксированный baseline и выбранные данные задачи входами анализа;
5. не выдумывать метрики ранжирования, популярности, расходов, конверсий и выручки;
6. разделять исходные данные, наблюдения, допущения и рекомендации;
7. создавать новый датированный отчёт, а не перезаписывать историю;
8. перечислять отсутствующие или устаревшие входные данные;
9. останавливаться до любого production-действия и запрашивать одобрение человека.

Эти инструкции повышают стабильность результата, но не являются границей безопасности. Production-доступ всё равно должен ограничиваться реальными правами инструмента и ручным процессом подтверждения.

Предположим, команда хочет пересмотреть title, subtitle и keyword field для App Store США.

Опишите scope до сбора данных:

Приложение: Example App
Store: App Store
Страна: США
Язык: en-US
Поля: title, subtitle, keyword field
Цель: улучшить покрытие релевантных ключей без изменения позиционирования бренда

Так анализ не распространится на несвязанные локализации или новые продуктовые обещания.

git checkout main
git pull
git checkout -b aso/us-metadata-2026-07

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

До начала исследования подготовьте текущее состояние приложения через экспорт ASO.dev или MCP. Baseline может включать поддерживаемые идентификаторы приложения, Store и локализацию, а также актуальные метаданные, нужные для задачи. Экспорт создаёт фиксированный файл, а MCP может подготовить тот же рабочий контекст непосредственно из выбранного приложения. При использовании MCP сохраните нужные значения и время получения в отчёте или манифесте задачи.

Затем соберите необходимые для задачи исследовательские данные:

Специалист проверяет результаты и экспортирует выбранных конкурентов и ключевые слова, которые должны войти в pipeline. Найденные сущности — кандидаты, а не готовые рекомендации: нерелевантные приложения, брендовые запросы и ключи со слабым интентом нужно исключить или явно пометить до LLM-анализа.

Рядом с данными добавьте файл export-info.md:

# Информация об экспорте

Дата экспорта: 2026-07-20
Приложение: Example App
Store: App Store
Страна: US
Язык: en-US
Период анализа: 2026-06-20 — 2026-07-19
Текущий baseline: ASO.dev MCP, получен 2026-07-20 09:00 UTC
Источники исследования: ручные конкуренты, автоматический поиск конкурентов, Spy, поиск органических ключей

Известные ограничения:
- не все автоматически найденные конкуренты проверены;
- данные о выручке отсутствуют.

Ограничения являются частью набора данных. LLM не должна «дополнять» их догадками.

Задача для AI-ассистента может быть короткой, потому что детали уже находятся в репозитории:

Прочитай AGENTS.md, apps/my-app/app-context.md,
workflows/metadata-update.md, зафиксированный baseline приложения
и выбранные исследовательские данные US от 2026-07-20.

Используй prompts/metadata-optimization.md.

Проанализируй текущие title, subtitle и keyword field.
Создай отчёт и предложение метаданных.
Явно укажи отсутствующие данные и допущения.
Не выполняй production-действия.

Ожидаемый результат — не просто предложенная строка. Это проверяемый отчёт, содержащий:

• происхождение данных;
• релевантные кластеры ключей;
• оценку текущего покрытия метаданных;
• предлагаемые поля;
• обоснование каждого изменения;
• отклонённые варианты;
• риски и нерешённые вопросы.

После подготовки аналитического предложения используйте ASO.dev MCP, чтобы подтвердить нужное приложение и проверить поддерживаемые поля метаданных. Проверка может включать длину полей, обязательные значения, локализацию, форматирование, дубли и соответствие выбранному приложению.

Для метаданных App Store откройте Кросс-локализацию для целевой страны. На странице одновременно видны основная и дополнительные локали, которые индексируются в этом storefront. Повтор слова в title, subtitle или keyword field другой индексируемой локали не усиливает индексацию и расходует ограниченное место метаданных.

MCP предоставляет ту же проверку в машиночитаемом виде. Вызовите get_editor_data с кодом целевой страны и добавьте asoOnly: true, если нужны только title, subtitle и keywords. ASO.dev выберет относящиеся к стране кросс-локали и вернёт validation с предупреждениями или ошибками, указав затронутое поле, локаль и связанную локаль или поле. Зафиксируйте вместе с предложением страну, набор проверенных локалей и оставшиеся предупреждения о повторах.

AI Companion работает локально. AI может просматривать и редактировать поддерживаемые метаданные в локальном пространстве ASO.dev, но финальное сохранение остаётся ручным. Так проверка работает с реальным состоянием приложения, а промпт не превращается в разрешение на публикацию.

Pull Request должен отвечать на реальные вопросы ревьюера:

• Какой экспорт использовался?
• Какие поля входят в scope?
• Что изменилось и почему?
• Для какой страны и какого набора кросс-локалей выполнена MCP-проверка?
• Какие предупреждения о повторах связывают две локали или поля?
• Какие предупреждения остались?
• Что требует явного одобрения?

Ревью должно сопоставлять предложение с исходными данными, правилами бренда, ограничениями Store и точным diff. Одобрение относится к версии из Pull Request, а не к любому будущему варианту, который сгенерирует AI.

После того как ответственный сотрудник вручную сохранит утверждённые метаданные, дополните задачу:

• финальными применёнными значениями;
• приложением и локализацией;
• именем одобрившего специалиста;
• датой применения;
• разницей между утверждённой и реально применённой версией.

Так замыкается связь между анализом и production.

Та же модель ревью подходит для анализа Apple Ads, но путь применения будет другим.

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

LLM может классифицировать запросы по действиям:

• масштабировать;
• продолжить сбор данных;
• добавить как Exact;
• рассмотреть как Negative;
• увеличить или снизить ставку;
• остановить после проверки специалистом.

У каждой рекомендации должны быть данные и указание на ограничения выборки. Утверждённое изменение затем вносится через Apple Ads или другой явно авторизованный интерфейс и фиксируется в репозитории.

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

Ветки изолируют задачи, не скрывая работу от команды:

aso/us-keyword-research-2026-07
aso/de-localization-2026-07
aso/review-analysis-2026-07
apple-ads/us-search-terms-2026-07
workflow/metadata-approval-v2
prompt/competitor-analysis-v2

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

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

История Git долговечна. Это полезно для решений и опасно для секретов.

Никогда не добавляйте в репозиторий учётные данные, приватные ключи, токены доступа, персональные данные и лишнюю финансовую информацию. Запись в .gitignore не удаляет секрет, который уже попал в коммит.

Сырые экспорты тоже не всегда стоит хранить в Git:

• небольшие очищенные CSV можно коммитить, если доступ к репозиторию правильно ограничен;
• большие или чувствительные экспорты можно оставить в контролируемом объектном хранилище, а в Git сохранить неизменяемую ссылку, checksum, метаданные экспорта и правила доступа;
• до сохранения пользовательских или коммерчески чувствительных данных определите сроки хранения и порядок удаления.

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

Безопасный процесс по умолчанию:

1. проанализировать;
2. предложить;
3. проверить;
4. провести ревью;
5. одобрить;
6. применить вручную;
7. зафиксировать результат.

Команда может внедрить этот процесс без переноса всех старых отчётов.

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

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

Перед слиянием ASO- или Apple Ads-задачи проверьте:

• явно указаны приложение, Store, страна, язык и период;
• определён аналитический набор данных или неизменяемая ссылка на него;
• отсутствующие данные и допущения видны;
• промпт и workflow версионируются;
• в отчёте доказательства отделены от рекомендаций;
• поддерживаемые метаданные проверены для нужного приложения и целевой страны;
• повторы слов между соответствующими кросс-локалями разобраны;
• учётные и чувствительные данные не попали в историю Git;
• человек проверил точную предлагаемую версию;
• финальный применённый результат будет зафиксирован.

Когда эти ответы находятся в репозитории, AI перестаёт быть изолированным помощником и становится частью проверяемого ASO-процесса.