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

Разработчик получил ТЗ на пушу, прочитал его и начал звонить: "А что имеется в виду под сегментацией? Какой формат данных передавать? На какой домен ставить трекер?" Полчаса разговоров — и уже потеряно время. Вот минимальный набор, без которого ТЗ на пушу становится гаданием.

Основной блок ТЗ:
— Целевая аудитория (возраст, гео, ОС, система отслеживания — ID юзера или внешний ключ)
— Размер аудитории или условие для попадания в аудиторию
— Текст пуша: заголовок, тело, максимальная длина (иначе обрежется)
— URL назначения и параметры UTM (utm_source, utm_medium, utm_campaign минимум)
— Временное окно отправки (в какой timezone считать?)
— Расписание: одноразовая отправка, регулярная, trigger-based
— Действия при клике и при отклонении (куда пойти, что логировать)

Что уточнить про трекинг:
Если нужны метрики кроме стандартных (sent, clicked, unsubscribed) — описать прямо: "логировать время между отправкой и кликом", "считать re-engagement по дате последнего клика". Указать, где хранятся логи и кто их смотрит. Разработчик должен знать, кому в конце дня отправить отчёт.

Техническое:
Среда отправки (staging/prod), дата деплоя, тестовые ID аккаунтов для проверки. Если есть ограничения: "не больше 1000 пушей в минуту" или "только HTTPS", написать явно. Контакт того, кто согласует финальный тест.

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