# Шаблон отчёта маркетингового аудита

BEIZ Studio · 24 октября 2026

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

Пояснение: https://beizstudio.com/journal/useful-audit/
Услуга: https://beizstudio.com/services/audit/

## 1. Задача и границы

- Бизнес и проверяемые страницы/аккаунты:
- Главный вопрос аудита:
- География, аудитория и языки:
- Период данных:
- Дата проверки:
- Что включено:
- Что не проверялось:
- Кто со стороны бизнеса объясняет процесс:

## 2. Источники и ограничения

Для каждого источника заполните:

- Название и ссылка с подходящими правами доступа:
- Период и дата выгрузки:
- Что считается обращением / квалифицированным обращением / продажей:
- Проверка полноты и повторов:
- Недостающие данные и ограничения:

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

## 3. Резюме для решения

- Что удалось подтвердить:
- Что остаётся гипотезой:
- Какие данные нужно получить:
- Что стоит сделать первым и почему:
- Что можно отложить:

## 4. Карточка находки

Скопируйте карточку для каждой отдельной проблемы или гипотезы.

- ID и название:
- Вопрос, на который отвечает находка:
- Наблюдение:
- Источник, период и способ воспроизведения:
- Статус: подтверждено / гипотеза / недостаточно данных:
- Подтверждённое последствие:
- Возможное последствие, которое ещё нужно проверить:
- Рекомендация:
- Обоснование приоритета:
- Зависимости:
- Ответственный:
- Оценка трудоёмкости и кто её подтвердил:
- Критерий приёмки:
- Дата повторной проверки и результат:

### Заполненный учебный пример

- ID: DEMO-01.
- Вопрос: событие «заявка» действительно означает принятое обращение?
- Наблюдение: в условной тестовой среде событие появляется при нажатии кнопки пустой формы, до сохранения обращения.
- Основание: повторяемый тест пустой формы, журнал событий и отсутствие сохранённой заявки. Это описание сценария для обучения, реальные измерения к нему не приложены.
- Вывод: такое событие описывало бы нажатие, а не принятое обращение.
- Неизвестно: число настоящих заявок, размер искажения отчёта и влияние на продажи.
- Рекомендация: разделить нажатие и подтверждённое получение обращения.
- Приоритет: исправить определение события до сравнений стоимости подтверждённой заявки.
- Ответственный: исполнитель формы и аналитики, назначаемый командой.
- Приёмка: пустая форма и ошибка сохранения не создают событие успешной заявки; корректно принятый запрос создаёт одно событие.

## 5. План действий

Для каждой задачи: ID находки → действие → ответственный → зависимость → оценка → согласованная дата → проверка → статус.

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

## 6. Проверка результата

- Что изменилось и когда:
- Как проверено техническое исправление:
- Какое определение метрики используется:
- Какие сопоставимые периоды сравниваются:
- Что ещё изменилось за это время:
- Что можно заключить, а что пока нельзя:

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