Product Requirements Document (PRD)¶
Product Requirements Document (PRD): Micro-Learning White-Label Platform (Flutter + Django) Версия: 1.0 Цель документа: зафиксировать требования к системе, которая позволяет из одной кодовой базы выпускать множество микро-обучающих приложений (“60 секунд в день”) с разным контентом и дизайном, поддержкой оффлайна, подписок, аналитики, автоматической сборкой и автопубликацией в сторы, а также с игровой механикой повторения через свайп-викторины. Обзор продукта
1.1. Проблема и ценность¶
Нужно выпускать много небольших тематических приложений (например, “Пушкин”, “Шагал”, “Понимать кино”) без написания нового приложения каждый раз. Контент и тема оформления должны задаваться из админки, а сборка/релиз происходить автоматически. Приложения должны работать оффлайн, иметь ежедневный контентный “ритуал” (1 урок в день), удержание (streak, напоминания) и “повторение” (swipe-quiz). Монетизация: подписки/IAP.
1.2. Продукт в двух словах¶
Платформа: – Backend: Django (кастомная админка + API + аналитика + управление билдом). – Frontend: Flutter (единый core + конфиг бренда/курса + оффлайн + мультимедиа + подписки + аналитика + викторины). – CI/CD: сборка множества flavor/targets и автопубликация в App Store / Google Play.
1.3. Персоны (минимум)¶
A) Пользователь-ученик (B2C): хочет 1 минуту контента в день, без сложного обучения, оффлайн, с прогрессом. B) Контент-редактор: заводит инсайты, медиа, вопросы для викторин, переводы, расписания, A/B варианты. C) Продакт/маркетолог: управляет брендом (иконки, скриншоты, тексты стор), параметрами paywall, пуш-стратегией, экспериментами. D) DevOps/релиз-менеджер: следит за пайплайном сборки и автодеплоем, мониторит ошибки. E) Администратор платформы: управляет пользователями, правами, конфигами, безопасностью.
1.4. Успех (KPI)¶
– D1 retention, D7 retention, D30 retention – Activation: доля пользователей, прошедших Day 1 (контент + вопрос) – Streak: средняя серия, % пользователей со streak >= 3/7/14 – Quiz engagement: % пользователей, проходящих викторины; accuracy – Conversion: trial→paid, free→paid, churn – Cost: стоимость поддержки N приложений (build time, релиз time) – Стабильность: crash-free sessions, API error rate, build failure rate Скоуп и принципы
2.1. Обязательные свойства системы¶
– White-label: один репозиторий Flutter, много приложений (разные Bundle ID / applicationId, иконки, название, цветовая схема, контент). – Оффлайн first: контент и медиа доступны без сети (после первичной синхронизации). – Контент “60 сек/день”: 1 основной элемент контента/день, с ограничениями. – Мультимедиа: текст, изображение, аудио, видео. – i18n: много языков (контент и UI). – Подписки/IAP: Apple/Google, желательно единая абстракция. – Аналитика: событийная + продуктовая воронка. – Автосборка из админки: кнопка “build” для бренда/всех брендов. – Автопубликация: после успешной сборки – отправка в Store, без ручной загрузки. – Викторины: swipe-повторение по пройденному материалу, гибкая связь с контентом.
2.2. Что не входит в MVP (если нужно урезать)¶
– Социальные функции (друзья/чаты/публичные лидерборды) – Генерация контента ИИ на лету (можно позже) – Сложные курсы с ветвлением, длинные уроки, видео-платформа – Встроенный редактор графики (иконки/скриншоты) внутри админки (можно интеграцией) Архитектура высокого уровня
3.1. Компоненты¶
A) Django Core API – контентный каталог, расписания, локализации – прогресс пользователей, streak, викторины, результаты – подписки/права доступа – конфигурации брендов и app-вариантов – аналитические события (опционально как зеркалирование) B) Django Admin (кастом) – управление брендами (app variants) – управление контентом (инсайты, медиа, серии, теги) – управление переводами – управление квизами – управление A/B параметрами / remote config (или прокси к Firebase) – управление build/release (статусы, кнопки, логи) – роли/права C) Build Orchestrator – очередь задач (Celery/RQ) – интеграция с CI (GitHub Actions/Buildkite/Bitrise) через API/Webhooks – хранение артефактов, статусов, журналов D) CI/CD – сборка Flutter (Android AAB, iOS IPA) на основе конфигов – подпись (keystore, provisioning profiles) – публикация (Fastlane deliver/pilot + supply) – при необходимости: TestFlight/Internal testing before production – матрица сборок по брендам E) Flutter App Core – загрузка BrandConfig + CourseConfig – оффлайн-база + media cache – daily flow + streak + notifications – paywall + entitlement – quiz module – analytics SDK
3.2. Потоки¶
– Пользователь: install → onboarding → sync pack → day content → completion → log events → (quiz triggers) → retention via notifications → subscription upsell – Редактор: добавить контент/переводы/quiz → publish content version → клиенты подтянут обновление – Маркетолог: поменять paywall params/remote config → измерить конверсию – Релиз: обновить core → “rebuild all” → CI builds matrix → auto upload stores → status in admin Модель мульти-приложений (White-label)
4.1. Сущность AppVariant (бренд/приложение)¶
Поля (минимальный набор): – id, slug – platform ids: android_application_id, ios_bundle_id – app name, short name – icons/splash assets (ссылки на файлы, версия) – theme: primary/secondary/background colors, typography, corner radius, card style – default locale, supported locales – course(s) attached: primary_course_id, optional secondary packs – store metadata: description, keywords, promo text, screenshots references, category, age rating notes (только хранение, публикация через fastlane metadata) – monetization config: paywall type, price tier, trial settings, entitlement mapping, feature flags – build config: flavor name, entrypoint (если нужно), dart-defines, firebase config ids – status: draft/active/paused/retired – content channel: content_version pin, rollout % (опционально)
4.2. Принцип сборки¶
Flutter проект поддерживает flavors. Каждый AppVariant соответствует flavor и набору ассетов. Конфиг бренда подставляется как: – compile-time: bundle id/app id, иконки, название, firebase files – runtime: theme + тексты + поведение (фичи), которые можно менять без нового релиза (remote config)
4.3. Массовые пересборки¶
– “Rebuild all” собирает список активных AppVariant и ставит задачи в очередь – Сборки можно делать параллельно (ограничение по macOS runners) – Релиз-стратегия: a) сначала internal testing/TestFlight, b) затем staged rollout production Контентная модель
5.1. Базовые сущности¶
Course (курс/тема): – id, slug, title per locale, description – content cadence rules (1/day, открытие в час, timezone behavior) – difficulty/target audience – tags, categories – content_versioning ContentItem (инсайт/день): – id, course_id – day_index (1..N) или publish_date (если привязка к календарю) – title, body (rich text), summary – media references: images[], audio, video (url + local cache hints + duration) – estimated_duration (target 60 sec) – key_takeaway (1 sentence) – quiz hooks: quiz_question_ids or tags for quiz selection – localization: translations per locale – status: draft/scheduled/published/archived – content_hash (для кэша) MediaAsset: – id, type (image/audio/video) – source url, CDN url – file size, duration, dimensions – checksum – offline_policy (mandatory/optional) – license metadata (важно для прав)
5.2. Версионирование контента¶
Нужно уметь обновлять контент без поломки прогресса. Требование: – контент должен иметь стабильные id – изменения текстов/медиа допустимы – удаление/перестановка day_index требует миграционной политики: “не трогать прошлое”, “вставка нового дня” и т.п. – клиент должен понимать: какие items обновились (by updated_at / content_hash)
5.3. Локализация контента¶
– UI strings: через Flutter i18n – ContentItem translations: через API, хранение в Django (таблица переводов) – fallback: если нет перевода, показывать default locale или скрывать item (настраиваемо) Daily Flow (основной UX)
6.1. Правила¶
– 1 новый item в сутки на пользователя (по локальному timezone устройства, плюс защита от манипуляций) – если пользователь не прошёл сегодня — показываем “сегодняшний” – если прошёл — показываем recap или quiz/архив (в зависимости от paywall) – допустимый catch-up: настраиваемо (например, максимум 1 день назад для paid) – streak: растёт при прохождении в consecutive days; правила freeze (опционально для paid)
6.2. Состояния дня¶
– Locked: день ещё не открыт – Available: можно пройти – Completed: пройден (с timestamp) – Missed: пропущен (для streak логики)
6.3. Онбординг¶
– выбор языка – разрешения: уведомления (опционально позже), трекинг (iOS), медиа загрузки (Wi-Fi only) – мини-демо: 1 пример инсайта + 1 вопрос – предложение скачать оффлайн-пакет (обязательно для хорошего опыта)
6.4. Референс-экраны (логически)¶
– Home/Today: карточка дня + прогресс + streak – Player/Reader: контент (текст/аудио/видео) – Quick Question: 1 вопрос по текущему инсайту – Result: “запомнил/не запомнил”, короткий takeaway – Archive (paid): прошлые дни – Quiz mode: swipe – Paywall – Settings: язык, уведомления, оффлайн, restore purchases Оффлайн и синхронизация
7.1. Offline requirements¶
– приложение должно работать без сети после первой синхронизации – минимум: текст + изображения текущего и ближайших N дней – опционально: аудио/видео по настройкам (Wi-Fi only, download on demand) – при плохой сети: graceful degradation (показать текст без видео)
7.2. Локальное хранилище¶
– локальная БД: таблицы: content_items, translations, progress, quiz_questions, quiz_results_pending, media_cache_index – файловый кэш: media assets by content_hash – политика очистки: LRU, ограничение по диску, “keep last 30 days”, “keep favorites”
7.3. Синхронизация¶
– при запуске и раз в X часов: pull updates – при завершении урока/квиза: write local → enqueue event → push when online – конфликт прогресса: server wins, но логировать anomaly; возможно “merge by max completed day”
7.4. Анти-чит по времени¶
– пользователи могут менять время устройства. Требование: – при наличии сети сверять server_time и вычислять offset – если offset слишком большой, ограничивать выдачу новых дней (soft lock) – оффлайн разрешать только в пределах последней подтвержденной даты Викторины и опросы (swipe repetition)
8.1. Назначение¶
– повторение через 3/7/14 дней – вовлечение и удержание – диагностика понимания (accuracy)
8.2. Типы вопросов (MVP)¶
– True/False statement (swipe right/left) – “This or That” (вариант A/B) – “Match” или “Fill in blank” — позже
8.3. Модель данных¶
QuizQuestion: – id – course_id, tags[], linked_content_item_ids[] – type – prompt (утверждение) + explanation (короткое объяснение) – correct_answer (boolean) – difficulty (1-3) – locales translations – stats fields (optional aggregated) QuizScheduleRule: – trigger: after_day_count (например, после 5 дней) или spaced schedule – selection: by tags/linked items, avoid repeats, prioritize mistakes – length: N questions per session – frequency caps: max 1 quiz session/day
8.4. Алгоритм выбора вопросов¶
– входные параметры: пройденные content_items, история ответов, даты, ошибки – приоритет: вопросы по контенту 3–7 дней назад вопросы, где пользователь ошибался разнообразие тегов
– исключать: вопросы, заданные в последние K дней (cooldown)
– гарантия: session always has N items (если не хватает — fallback to general pool)
8.5. UX правила¶
– свайп с haptic feedback – мгновенная обратная связь: “Верно/Неверно” + одно предложение почему – счетчик: streak quiz / points – завершение: summary (accuracy, “повтори эти 3 темы”) – связка с paywall: extended quizzes for paid (больше вопросов/архив ошибок)
8.6. Аналитика квизов¶
– quiz_started, quiz_completed, question_answered(correct/incorrect), time_per_question – влияние на retention: cohort analysis Монетизация и подписки
9.1. Модель¶
– Free: 1 урок/день + 1 мини-вопрос; ограниченный архив (например, 3 дня) – Paid subscription: полный архив, оффлайн-пакеты (аудио/видео), расширенные квизы, streak freeze, дополнительные режимы (“5 минут”) – Возможны IAP packs: “курс целиком”, “аудио пакет”, “доп. темы”
9.2. Требования к подписке¶
– In-App Purchase на iOS/Android – restore purchases – entitlement-слой в приложении (фича-флаги на основе подписки) – серверная валидация квитанций (рекомендуется) – защита от рассинхронизации: клиент периодически обновляет entitlement
9.3. Paywall¶
– несколько шаблонов paywall (A/B) – remote config параметризация: цена, текст, trial duration, порядок экранов – правила показа: after day 1, when opening archive, after quiz streak, etc. – событийная аналитика paywall: shown, CTA clicked, purchase initiated, purchase success/fail Аналитика, эксперименты, мониторинг
10.1. События (минимальный обязательный набор)¶
– app_install, app_open – onboarding_complete – content_day_available, content_view_start, content_view_complete – quick_question_answered (correct/incorrect) – streak_updated – notification_received/opened – quiz_started/completed/question_answered – paywall_shown/cta/purchase_success/restore – offline_download_started/completed/failed
10.2. Эксперименты¶
– Remote Config / Feature flags: – время пуша – правило выдачи catch-up – длина квиза – paywall template – A/B assignment: stable per user
10.3. Crash/Performance¶
– crash reporting (Crashlytics) – performance traces (startup time, API latency) – build pipeline monitoring: success rate, duration Django кастомная админка (требования)
11.1. Роли и права¶
– Superadmin: все – Content Editor: контент, переводы, квизы – Brand Manager: app variants, store metadata, paywall params – Release Manager: build/release controls, просмотр логов – Analyst: доступ к дашбордам без редактирования
11.2. Основные разделы админки¶
A) Brands (AppVariants) – создание/редактирование – загрузка ассетов (иконки, splash) – настройка темы – привязка к курсу – store metadata fields – сборка: кнопки Build / Release / Rollback – статус и история B) Courses – базовые параметры, правила daily flow – публикация версии C) Content Items – редактор (rich text) – медиа attach – превью (как будет выглядеть на телефоне) – перевод/локализация – статус и расписание публикации – массовые операции (bulk edit) D) Quizzes – банк вопросов – привязка к контенту/тегам – правила scheduling – статистика ошибок E) Experiments/Configs – параметры paywall – пуш-шаблоны – rollout rules F) Builds & Releases – список build jobs, фильтры по бренду – логи (stdout CI, fastlane logs) – артефакты (ссылки) – кнопка “Rebuild all active” – подтверждения перед production rollout – webhook health
11.3. UX требования к админке¶
– быстрый поиск по контенту, тегам, дням – понятная индикация “что опубликовано” и “что в черновике” – минимизация ошибок: предпросмотр изменений и предупреждения при “ломающих” правках (например, смена day_index) Build/Rebuild/Auto-Publish
12.1. Оркестрация из админки¶
– В админке “Build” создаёт BuildJob (brand_id, target platforms, release channel, commit hash, config version) – Django отправляет событие в CI через API (GitHub Actions workflow_dispatch или webhook) – CI возвращает статусы обратно (webhook endpoint Django) – Django обновляет BuildJob status: queued/running/succeeded/failed/published
12.2. Массовая пересборка¶
– “Rebuild all” создаёт группу BuildBatch – ограничение параллельности (особенно iOS) – стратегия обновления: – internal track/TestFlight first – staged rollout production after approval (можно auto, но нужен флажок)
12.3. Автопубликация¶
– Android: публикация в нужный track (internal/alpha/beta/production) – iOS: TestFlight + (опционально) auto submit for review – управление store metadata: – вариант 1: хранить метаданные в репозитории (fastlane metadata) и генерировать из Django – вариант 2: хранить в Django и экспортировать на build step
12.4. Управление версиями¶
– единая схема versioning для всех брендов – авто bump build number на каждый build – релиз notes: автогенерация из changelog + ручные правки в админке
12.5. Rollback¶
– хранить “последний стабильный build” на бренд – кнопка “Revert to previous” (на уровне стора обычно через staged rollout/previous release) – внутри приложения можно делать kill-switch через remote config Безопасность и соответствие – хранение секретов: только в CI secrets/vault, не в Django базе – API auth: JWT + refresh, rate limiting, device id – персональные данные минимизировать: email optional, лучше anonymous id – GDPR: consent management, data deletion request endpoint – контентные лицензии на медиа Нефункциональные требования
14.1. Производительность¶
– холодный старт < 2.5s на средних устройствах – today screen отрисовка < 200ms после данных – видео/аудио воспроизведение без лагов при оффлайн файлах – синхронизация не блокирует UI
14.2. Надёжность¶
– оффлайн режим без крашей – транзакционная запись прогресса – повторная отправка аналитики при неуспехе
14.3. Масштабируемость¶
– минимум 100 AppVariants – контент: 10k items на платформу – DAU: 1M+ (аналитика преимущественно клиентская) Технические решения и готовые пакеты (рекомендация) Flutter (минимизация своего кода): – State management: Riverpod или Bloc – Локальная БД: Drift (SQLite) для прогресса/контента + Hive для мелких настроек – Кеш медиа: cached_network_image + flutter_cache_manager; для больших файлов отдельный downloader – Видео: video_player + chewie – Аудио: just_audio – i18n: intl + локализация ARB (или easy_localization) – Notifications: firebase_messaging + flutter_local_notifications – IAP: in_app_purchase (или RevenueCat purchases_flutter) – Analytics: Firebase Analytics + Remote Config; Crashlytics – Networking: dio + retry/interceptors – Serialization: freezed + json_serializable Django: – API: Django REST Framework – Auth: simplejwt (JWT) – Admin: кастомная админка (можно поверх Django Admin, но с отдельными страницами) – Tasks: Celery + Redis (для оркестрации build jobs, публикаций, импорта контента) – Payments: dj-stripe (если Stripe участвует), либо только хранение entitlement от Apple/Google – Storage: S3-совместимое хранилище для media assets (MinIO/S3) – Observability: Sentry, structured logging CI/CD: – GitHub Actions (или Bitrise) – Fastlane (deliver/pilot + supply) – Firebase App Distribution для тестовых релизов – Matrix builds по брендам План релизов (модель этапов) Этап 0: Foundation – AppVariant модель, базовая админка брендов – Flutter flavors, конфиг загрузки темы и курса – Today flow + прогресс + streak (без видео, только текст/картинки) – оффлайн база и sync Этап 1: Media + Notifications + Analytics – аудио/видео поддержка – пуши и локальные напоминания – базовая аналитика + crash reporting Этап 2: Monetization – IAP subscription + restore – paywall + entitlement – ограничение архива/фич для free Этап 3: Quizzes – банк вопросов, привязка к контенту – swipe UX – расписания повторения – аналитика квизов Этап 4: Build/Release Automation – build jobs из админки – CI integration + статус обратно – автопубликация stores – rebuild all Acceptance Criteria (что считается “готово”) – Можно создать новый AppVariant в админке, прикрепить курс, задать тему и иконку. – Нажать “Build” и получить в админке успешный статус, артефакт и ссылку на опубликованный билд в нужном канале. – “Rebuild all” запускает сборку всех активных брендов и публикует без ручной загрузки. – Пользователь устанавливает приложение, проходит day 1 оффлайн после первичной загрузки, прогресс сохраняется. – Каждый день появляется один новый контентный item, streak корректный при пропусках/перезапусках. – После N дней запускается swipe-quiz; ответы сохраняются и влияют на приоритет повторения. – Подписка разблокирует архив и расширенные квизы; restore работает. – Аналитика собирает события и видны в дашборде. Список вопросов/рисков (фиксируем заранее) – Как хранить/публиковать store metadata и скриншоты: из Django генерировать fastlane metadata или вручную в App Store Connect/Play Console? – Как управлять Apple review и “submit for review” автоматически (возможно нужен полу-ручной шаг). – Лимиты CI по macOS runners (стоимость и параллельность). – Правовая часть: лицензии медиа, возрастные рейтинги. – Анти-чит времени: насколько строго блокировать выдачу новых дней. – Миграции контента при изменении day_index: нужна четкая политика.