Статус delivered у дистрибьютора означает только одно: файлы ушли в систему площадки. Это не значит, что трек уже прошёл внутреннюю обработку и стал доступен слушателям. Между «отправлено» и «опубликовано» есть несколько этапов на стороне самого сервиса, и любой из них может стать точкой остановки.
Что означает delivered на самом деле
В цепочке доставки дистрибьютор работает как транспорт: он упаковывает метаданные и аудио в стандартный пакет и передаёт его на приёмный сервер площадки. Delivered - подтверждение того, что пакет принят сервером. Дальше начинается внутренний процесс площадки: парсинг метаданных, проверка аудиофайла, сопоставление ISRC с уже существующими в базе, Content ID-сканирование, финальная модерация. Каждый из этих шагов выполняется независимо, со своей очередью и своими таймаутами. Дистрибьютор на этот процесс не влияет и видит его снаружи - через обратный статус, который площадка возвращает (а иногда не возвращает вовремя).
Технические причины, по которым трек не появляется
Большинство случаев «трек не виден» объясняется одной из нескольких ситуаций.
- Очередь на модерации площадки. Некоторые сервисы обрабатывают входящие релизы пакетами раз в несколько часов или раз в сутки. В периоды высокой нагрузки - пятница, начало месяца, конец квартала - очередь вырастает, и нормативные 7-14 дней от загрузки до появления могут сдвигаться на несколько дней даже при delivered.
- Конфликт ISRC. Если код уже занят другим треком в базе площадки, релиз попадает в ручную проверку или откладывается до разрешения коллизии. Площадка может не вернуть явную ошибку дистрибьютору - статус останется delivered, трека не будет.
- Проблема с метаданными, не видимая на стороне дистрибьютора. Площадки применяют собственные правила к полям: длина названия, запрещённые символы, несоответствие формата поля артиста тому, что есть в их базе. Пакет принят, но при парсинге конкретное поле вызывает ошибку - релиз уходит на ручной разбор.
- Content ID или rights conflict. Если аудио совпадает с уже заявленным клеймом в системе площадки, релиз задерживается до выяснения правообладателя. Это отдельная от модерации процедура, и она может идти параллельно с visible-статусом у дистрибьютора.
- Технический сбой доставки. Пакет был принят сервером, но при записи в базу произошёл сбой. Площадка считает, что ничего не получила, и не запрашивает повторно. Дистрибьютор видит delivered, площадка - пустоту. Редкая, но реальная ситуация.
- Задержка индексации поиска. Трек может быть уже в базе площадки, но поисковый индекс ещё не обновился. В этом случае страница существует и доступна по прямой ссылке, но в поиске по названию не отображается. Это отдельная от доставки проблема.
Какой срок ожидания считать нормальным
Стандартный срок от загрузки до появления на площадках - 7-14 дней, и большая часть этого времени приходится именно на внутренние процессы сервисов. Если дата выхода уже прошла или ещё не наступила, но трека нет через 14 дней после подтверждения delivered - это уже повод не ждать, а проверять. Важно не путать ситуацию: если релиз загружен в срочном режиме за 5-7 дней до выхода, небольшие задержки вероятнее, чем при стандартной подаче за 3-4 недели. Буфер перед датой выхода нужен именно для того, чтобы такие задержки не ломали план релиза.
Что проверять самостоятельно до обращения в поддержку
Прежде чем писать дистрибьютору и площадке, имеет смысл сделать несколько проверок - они часто объясняют ситуацию без лишней переписки.
Первое - проверить прямую ссылку, если дистрибьютор её предоставил. Если страница открывается, но в поиске трека нет, проблема только в индексации: нужно ждать от нескольких часов до пары суток. Если страница не открывается - трек либо не попал в базу, либо заблокирован.
Второе - проверить ISRC. Откройте кабинет дистрибьютора и убедитесь, что код присвоен и соответствует треку. Если код был присвоен дистрибьютором автоматически, попросите подтвердить, что он не конфликтует с другой записью в глобальных реестрах.
Третье - проверить дату выхода в настройках релиза. Иногда дата сохраняется в UTC, а артист ориентируется на московское время - формально трек ещё не должен быть виден.
Четвёртое - проверить, нет ли у этого трека или исполнителя активных claims или страйков на других площадках. Один конфликт может тормозить прохождение модерации на параллельных сервисах, если они используют общие базы Content ID.
К кому обращаться и в каком порядке
Первый адрес - дистрибьютор. Он единственный, кто видит технический статус доставки с обеих сторон: что ушло, что вернулось в ответ от площадки и вернулось ли вообще. Запрос в поддержку должен содержать: название трека, ISRC, UPC, дату загрузки, дату выхода, название площадки и снимок экрана с текущим статусом в кабинете. Чем точнее данные, тем быстрее разбирают запрос.
Если дистрибьютор подтверждает, что со своей стороны всё чисто и пакет был принят площадкой без ошибок, следующий шаг - прямой запрос в поддержку площадки. Для этого нужны те же данные плюс скриншот ответа от дистрибьютора. Яндекс Музыка, VK Музыка и Звук работают с официальными запросами через формы для правообладателей - не через общую пользовательскую поддержку. Использование неправильного канала удлиняет процесс.
Площадка обычно отвечает в течение нескольких рабочих дней, но в нагруженные периоды срок может быть больше. Если ответа нет через неделю - имеет смысл повторить запрос с пометкой о первичном обращении.
Когда нужна повторная доставка
Повторная отправка пакета - крайняя мера, и к ней прибегают только после того, как дистрибьютор и площадка подтвердили, что исходный пакет не был обработан корректно. Самостоятельно инициировать повторную доставку через кабинет без согласования не стоит: если первый пакет всё-таки находится в очереди площадки, второй создаст дубликат - и тогда начнётся отдельная процедура разрешения конфликта дублей, которая займёт ещё больше времени. Дистрибьютор сам инициирует повторную доставку, когда убеждается в необходимости этого на основе технических логов.
Если релиз в итоге появится позже заявленной даты выхода, это не означает автоматическую потерю данных прослушиваний - стримы начнут считаться с момента появления трека. Однако питчинг в редакционные плейлисты, который требует опережения на 3-4 недели, в такой ситуации уже невозможен: площадки не принимают питч на вышедший релиз.
Что делать прямо сейчас
- Откройте кабинет дистрибьютора и зафиксируйте текущий статус релиза скриншотом с датой и временем.
- Проверьте прямую ссылку на трек (если дистрибьютор её выдаёт при delivered) - откройте в браузере и в приложении площадки.
- Проверьте правильность даты выхода и часового пояса в настройках релиза.
- Убедитесь, что ISRC присвоен и виден в кабинете - и что нет конфликтных claims на этот трек на других платформах.
- Если трека нет спустя 14 дней после delivered - напишите в поддержку дистрибьютора с полными данными: трек, ISRC, UPC, площадка, дата загрузки, дата выхода, скриншот статуса.
- Если дистрибьютор подтвердил отсутствие ошибок на своей стороне - обратитесь в поддержку площадки напрямую через канал для правообладателей, приложив ответ дистрибьютора.
- Не инициируйте повторную доставку самостоятельно без подтверждения от дистрибьютора - это создаёт дубликат и удлиняет процесс.
Если вы выпускаете релизы через нас, задержку доставки разбирает наша команда на стороне дистрибьютора - обращайтесь напрямую, мы видим технические логи и можем запросить площадку официально. Подробнее о том, как устроена дистрибуция музыки и что происходит с треком после загрузки, - на соответствующей странице. Там же - сроки, форматы и что проверять перед подачей, чтобы таких ситуаций не возникало.
