Админка, сбор статистики и проверка профиля

20.09.2026 · реализация закрытого технического пилота. Текущая админка доступна только владельцу приватного проекта. Публичная многопользовательская биржа и реальные расчёты ещё не запущены.

Реализовано

• /admin: обзор, реальные агрегаты по отслеживаемым видео и площадкам, группировка по кампании, модерация, предварительный расчёт, журнал операций.
• Серверные адаптеры TikWM и InAPI; ключи хранятся в секретах окружения, не в браузере и не в исходном репозитории.
• Постоянная база: профили, одноразовые коды, видео, снимки счётчиков, журнал сбора, журнал предварительных начислений.
• Подтверждение профиля: получить код → добавить в био → сервер читает профиль и ищет полный код → фиксирует внешний ID и дату подтверждения.
• Добавление видео: нормализация URL, защита от подмены домена, точный внешний ID, проверка автора, уникальность публикации, фиксация baseline.
• Серверный обработчик scheduled и cron 0 */6 * * *: 03:00, 09:00, 15:00, 21:00 МСК. При запуске вычитывает просроченные видео пачками по 10 до 12 минут, остаток отмечает в журнале. Таймер браузера удалён. Конфигурация готова, но фактическую регистрацию Cron Trigger на управляемом Sites пока нельзя подтвердить доступными инструментами: круглосуточный запуск не объявлен включённым.
• Только проверенный автор и допуск оператора позволяют предварительный расчёт TikTok. Для Instagram — статистика без начисления. Понижение счётчика и резкий скачок отправляют запись на проверку, а не автоматически меняют деньги.
• Статус провайдера и ошибки сохраняются без ключей и сырых персональных данных; ошибка API не записывает нулевой счётчик.

API и проверенные ответы

TikWM: базовый адрес https://api.tikwmapi.com, заголовок x-tikwmapi-key. Профиль — GET /user/info?unique_id=…, био data.user.signature, внешний ID data.user.id. Видео — GET /?url=<video_id>, метрики data.play_count, digg_count, comment_count, автор data.author.id. Проверены успешные живые ответы профиля и видео. Документация.

InAPI: профиль — GET /api/v1/public/people/byname?username=…, видео — GET /api/v1/public/media/info?media_id=…. Ключ передаётся сервером в query согласно документации; URL с ключом запрещён в логах. Публичная документация не показывает полный контракт каждого ответа, поэтому нормализация дополнительно проверена живыми запросами. Документация без ключа в ссылке.

Короткие TikTok-ссылки пока не поддерживаются: принимается полный URL. Не выполняется произвольный fetch пользовательского адреса — запросы уходят только на фиксированные домены провайдеров. Пароли соцсетей, cookies авторизации и скрытые аккаунты не используются. Сторонний парсер может кешировать данные и возвращать устаревшие значения; это ограничение нужно учитывать при проверке био и окончательной сверке денег.

Проверка био

Код генерируется криптографически, имеет 64 бита случайности, привязан к владельцу кабинета, площадке и неизменному внешнему ID. Срок действия 24 часа; до 20 проверок, не чаще одной в минуту. Новый код заменяет прежний. Проверка требует точного совпадения всего кода в био и того же ID профиля; подстрока внутри другого токена не подходит. Чужой профиль, закрытый профиль и истёкший код не подтверждаются. После успеха повторная проверка идемпотентна, код можно удалить.

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

Расчёт

eligible_observed = max(0, high_water_views − baseline_views).

pending_target_kopecks = min(floor(eligible_observed × rate_kopecks / 1000), video_cap_kopecks).

До одобрения и достижения min_views (по умолчанию 5 000 общих просмотров на публикации) начисление равно нулю. После достижения порога начисляется накопленный прирост относительно baseline, а не только просмотры сверх порога. Это выбранное правило Clippy; приведённый текст Vyro не раскрывает момент начала учёта. Порог фиксируется при добавлении вместе со ставкой и лимитом.

Журнал добавляет только разницу между новым суммарным результатом и уже начисленным. Целочисленный расчёт предотвращает ошибки дробных денег, уникальный ключ video/high_water — повторное начисление; сохранение снимка и расчёта происходит одной транзакционной пачкой. Ставка и лимит фиксируются при добавлении видео, не изменяются задним числом. При отказе/аномалии суммы остаются в истории, но отражаются как приостановленные.

Это предварительный расчёт, не payable ledger. Не реализованы подтверждённое финансирование кампании и резерв общего бюджета, полноценный антифрод, договорная сверка, бухгалтерские документы, доступный баланс и реальная отправка денег WinWork. До их подключения интерфейс не предоставляет реальные выплаты. Кошелёк основного прототипа содержит отдельно обозначенные демонстрационные суммы и не смешивается с реальными метриками админки.

Следующий производственный этап

Заменить закрытый доступ владельца на серверные роли admin/moderator/finance/clipper/advertiser; привязать принятые задания к видео и договору; внедрить резерв бюджета и двойную запись денег; включить очередь сбора и серверное расписание; обработать retry/backoff по квоте, удаление и приватизацию постов, апелляции и ручное разрешение аномалий; установить сроки хранения и очистку; согласовать локализацию данных и договоры с API-поставщиками; подключить WinWork по реальному контракту. Нельзя переносить приватный пилот в массовую эксплуатацию одним изменением доступности ссылки.

Проверки

Автотесты: строгая проверка доменов/ссылок, точный токен био, исключение ранних просмотров, денежный лимит, невалидные счётчики, точное преобразование Instagram shortcode. Сервер отклоняет запросы без идентичности владельца; операции изменения проверяют same-origin. Для финального E2E-подтверждения нужен профиль, в который пользователь действительно добавит выданный код: подставлять успех без чтения био нельзя.

Изменение от 20 сентября: проверка заказчиком

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

Интеграционные тесты исполняют реальные SQL-запросы сборщика в SQLite: порог 4 999/5 000, накопленный прирост, повторный сбор, отказ/одобрение, лимит, HTTP 429, падение счётчика и обход 12 видео (больше одной пачки).

Уточнение правила, 20 сентября

Подтверждено по FAQ Vyro: отсчёт идёт с подачи, включая время проверки. Начисление возможно после одобрения и порога. Версия расчёта 3 возвращает вычет стартового счётчика. Исторические начисления сохраняются: автоматического списания прежних сумм нет, новые начисления появляются только при превышении уже начисленной суммы. Миграция версии 2 сохранена.