Delivery report - это технический документ, который дистрибьютор формирует в момент отправки релиза на площадки. Он фиксирует, что именно было передано, когда, в каком формате и с какими метаданными. При смене дистрибьютора этот документ становится единственным доказательством того, что именно вы и ваш прежний партнёр поставили трек на Яндекс Музыку, VK Музыку или любой другой сервис - и именно вы имеете право отозвать его или перевыпустить через нового дистрибьютора.
Что входит в delivery report
Единого стандарта формата нет: одни дистрибьюторы выдают PDF, другие - CSV или выгрузку из личного кабинета. Но содержание в большинстве случаев одинаковое. В документе фиксируются:
- ISRC каждого трека и UPC релиза
- название релиза, исполнитель, featured-артисты точно в том виде, в котором они ушли на площадки
- список площадок, на которые была отправлена доставка
- дата и время отправки
- статус доставки по каждой площадке - принято, отклонено, в обработке
- версия метаданных: язык, жанр, дата релиза, территории
- технические параметры аудиофайла, который был отправлен
Именно связка ISRC + статус доставки + дата - это то, что имеет доказательную силу при любых спорах. Всё остальное в документе - полезный контекст, но не ключевое.
Почему delivery report не то же самое, что скриншот из кабинета
Личный кабинет дистрибьютора показывает текущее состояние: трек есть на площадке, статистика накапливается, роялти начисляются. Но этот интерфейс не является документом - он меняется в реальном времени, и после смены дистрибьютора вы теряете доступ к нему вместе с аккаунтом. Delivery report, выгруженный и сохранённый в момент работы, остаётся у вас независимо от того, что происходит с аккаунтом прежнего партнёра.
Бывает и другая ситуация: дистрибьютор закрывается или блокирует аккаунт до завершения выплат. В таком случае delivery report - часть доказательной базы для обращения в службу поддержки площадки напрямую. Площадка видит у себя трек с конкретным ISRC: если вы можете документально подтвердить, что именно вы являетесь правообладателем и именно через вас этот ISRC был зарегистрирован, позиция при разборе конфликта становится более обоснованной.
Роль документа при переходе к новому дистрибьютору
Когда вы переходите от одного дистрибьютора к другому, стандартная механика такая: прежний дистрибьютор делает takedown - площадки убирают трек. Новый дистрибьютор загружает его заново с теми же ISRC, и через 7-14 дней трек появляется снова. В идеальном сценарии накопленная статистика прослушиваний на большинстве площадок сохраняется, потому что она привязана к ISRC, а не к аккаунту дистрибьютора.
Проблема возникает, когда прежний дистрибьютор не выполняет takedown - либо затягивает его, либо отказывается делать. В этот момент новый дистрибьютор не может поставить трек: площадка видит конфликт - один и тот же ISRC от двух источников. Delivery report от нового дистрибьютора с датой отправки и подтверждением от старого дистрибьютора или его отсутствием в системе площадки - это материал для разбора конфликта через техподдержку.
Отдельная история - случаи, когда ISRC был присвоен дистрибьютором из своего пула и формально принадлежит ему, а не артисту. Тогда при смене партнёра трек технически нужно перевыпускать с новым кодом, и delivery report со старым ISRC помогает доказать историю релиза - что это тот же контент, просто с другим идентификатором. Это важно для переноса истории стримов там, где площадка готова делать такие правки вручную.
Споры о правообладании: что нужно сверх delivery report
Delivery report подтверждает факт доставки, но не подтверждает право собственности на фонограмму само по себе. В споре о правообладании он работает в связке с другими документами:
- Договор с дистрибьютором - он фиксирует, кто является правообладателем мастера и на каких условиях передаются права на дистрибуцию
- Сплит-соглашение - если несколько сторон участвуют в правах на мастер
- Регистрация ISRC - кто является организацией, выдавшей код: в России коды выдаёт уполномоченное национальное агентство, либо зарубежная организация через дистрибьютора
- Мастер-файл с метаданными - дата создания, инженер, студия
Delivery report в этом комплекте закрывает один конкретный вопрос: когда и куда была осуществлена поставка и кем. Именно этого часто не хватает при разборе конфликтов, которые инициируют площадки через процедуру matching - когда сервис автоматически определяет совпадение аудио и не может установить приоритетного правообладателя.
Восстановление истории релиза
Случается, что артист несколько лет работал с одним дистрибьютором, потом перешёл к другому, потом к третьему - и при этом не сохранял никаких документов. Теперь ему нужно подтвердить историю конкретного трека: когда он вышел, через кого, с какими метаданными. Это может понадобиться для регистрации в РАО или ВОИС, для участия в тендере на управление правами на музыку, для оформления каталожной сделки.
В этом случае delivery report запрашивается у каждого из прошлых дистрибьюторов. Большинство профессиональных партнёров хранят эти данные и выдают их по запросу даже после окончания сотрудничества - это стандартная практика. Если дистрибьютор закрылся, нужно обращаться напрямую к площадкам: Яндекс Музыка, VK Музыка, Звук и другие сервисы хранят логи поступления контента. Получить их труднее, и это не всегда возможно без официального запроса от юридического лица, но прецеденты есть.
Если речь идёт о дистрибуции музыки через нового партнёра, разумно сразу договориться о формате отчётности: какие документы выдаются при поставке, как хранятся, в каком виде их можно запросить после окончания сотрудничества. Это не паранойя, а часть базовой гигиены работы с каталогом.
Как дистрибьюторы формируют delivery report на практике
Крупные дистрибьюторы работают через стандарт DDEX - набор XML-форматов для обмена данными с площадками. Каждая отправка через DDEX автоматически логируется: площадка отвечает подтверждением или кодом ошибки, и этот обмен фиксируется на стороне дистрибьютора. Именно из этих логов формируется delivery report.
Небольшие дистрибьюторы могут формировать отчёты вручную или полуавтоматически - тогда документ выглядит как таблица или текстовый файл. Ключевой вопрос здесь не формат, а полнота: есть ли там дата, ISRC, список площадок и статус по каждой. Если есть - документ пригоден для использования. Если нет - просите расширенную версию или уточняйте, из каких логов её можно сформировать.
При работе с лейблом ситуация чуть сложнее: delivery report формирует лейбл или его дистрибьютор, и артист может не иметь прямого доступа к этому документу. Если вы работаете с музыкальным лейблом, стоит заранее прописать в договоре, что при окончании сотрудничества лейбл передаёт артисту delivery report по каждому релизу.
Что сделать прямо сейчас
- Зайдите в кабинет текущего дистрибьютора и найдите раздел с отчётами о доставке. Если такого раздела нет - напишите в поддержку с запросом delivery report по вашему каталогу.
- Выгрузите или сохраните документы в форматах, которые не привязаны к аккаунту: PDF, CSV, XLS. Храните их отдельно от аккаунта дистрибьютора - в облаке или на локальном диске.
- Убедитесь, что в документах есть ISRC каждого трека, UPC релиза, дата отправки и статус по площадкам. Если чего-то не хватает - запросите дополнительный отчёт.
- Если вы планируете смену дистрибьютора, запросите delivery report до инициирования takedown: после удаления трека с площадок восстановить часть данных сложнее.
- Если вы оформляете сотрудничество с лейблом, добавьте в договор пункт о передаче delivery report при завершении контракта - это стандартное условие, которое нормальный партнёр не станет оспаривать.
- Если прошлые дистрибьюторы недоступны, обратитесь напрямую в службы поддержки площадок с запросом истории поступления контента по ISRC - на некоторых сервисах это возможно.
