Артист подписывается к новому дистрибьютору - условия лучше, поддержка живее, питчинг активнее. Но между решением уйти и моментом, когда каталог нормально работает на новой площадке, лежит зона риска. Треки уходят в takedown, потом появляются снова - но уже с другим UPC. Счётчик прослушиваний обнуляется. Плейлисты, куда попал трек, теряют ссылку. Роялти зависают между двумя системами. Всё это не катастрофа, но каждый из этих эффектов управляем - если понимать механику заранее.
Что происходит при уходе от старого дистрибьютора
Когда вы инициируете переход, первое действие - отзыв релизов у текущего дистрибьютора. Это называется takedown. Старый дистрибьютор направляет площадкам запрос на удаление, и трек исчезает из каталога. Скорость разная: одни площадки обрабатывают запрос за несколько дней, другие - за две-три недели. На этот период трек может быть недоступен для прослушивания.
Параллельно старый дистрибьютор закрывает учёт роялти. Всё, что было накоплено до момента takedown, остаётся у него в системе до следующего расчётного периода. Как правило, дистрибьюторы платят с задержкой в один-два расчётных периода - то есть деньги за последние месяцы работы придут уже после того, как вы формально ушли. Это нормально, но нужно следить за тем, чтобы платёжные реквизиты и контактные данные у старого дистрибьютора оставались актуальными ещё какое-то время после разрыва.
ISRC: главный идентификатор, который нужно сохранить
ISRC - это код, привязанный к конкретной мастер-записи. Он не принадлежит дистрибьютору, он принадлежит правообладателю. Если дистрибьютор присвоил ISRC вашему треку, вы вправе запросить этот код и использовать его при загрузке к новому дистрибьютору.
Это критически важно по одной причине: стриминговые площадки идентифицируют запись именно по ISRC. Если новый дистрибьютор загрузит тот же трек с новым ISRC, площадка воспримет его как другую запись. История прослушиваний, сохранения в библиотеках пользователей, связи с алгоритмическими плейлистами - всё это привязано к старому ISRC и к старому треку. Новая запись начинает с нуля.
Поэтому до отзыва релизов запросите у текущего дистрибьютора полный список ISRC по каждому треку. Большинство дистрибьюторов предоставляют эти данные в личном кабинете или по запросу в поддержку. Если дистрибьютор отказывается - это нарушение, поскольку ISRC закреплён за правообладателем, а не за дистрибьютором.
UPC и что с ним делать
UPC - это штрихкод релиза как продукта: альбома, EP или сингла. В отличие от ISRC, UPC технически может принадлежать дистрибьютору, который его сгенерировал. Одни дистрибьюторы передают UPC артисту по запросу, другие - нет, поскольку считают его своей инфраструктурой.
Потеря UPC менее критична, чем потеря ISRC: история прослушиваний конкретного трека хранится на уровне ISRC, а не UPC. Но UPC используется при сопоставлении релиза в системах мониторинга, в отчётах РАО и смежных организаций, а также в некоторых магазинных системах. Если вы работаете с лицензированием или синхронизацией, смена UPC может создать путаницу в документах.
Идеальный сценарий - сохранить и ISRC, и UPC. Реалистичный минимум - обязательно сохранить ISRC по каждому треку.
История прослушиваний: что сохраняется, что теряется
Здесь нет универсального ответа, потому что каждая площадка работает по-своему. Общая логика такая:
- Spotify сохраняет историю прослушиваний, если трек возвращается с тем же ISRC. Счётчик не обнуляется. Но если трек был удалён и добавлен с новым ISRC - это уже другой трек в системе.
- Apple Music работает аналогично: идентификация идёт по ISRC, история привязана к нему.
- YouTube Music сложнее: видеоконтент и аудио индексируются по-разному, и если у трека есть клип на YouTube с Content ID - это отдельный слой, который существует независимо от дистрибуции.
- Deezer, Tidal и другие площадки - логика та же, но скорость переиндексации и поведение при смене дистрибьютора может различаться.
Сохранённые треки в библиотеках пользователей - отдельная история. Если трек был удалён и добавлен с тем же ISRC, Spotify, как правило, восстанавливает его в сохранённых. Но это происходит не мгновенно, и в период отсутствия трека пользователь видит неактивную запись.
Редакционные и алгоритмические плейлисты - самое уязвимое место. Если трек попал в Discover Weekly или в редакционный плейлист, эта ссылка привязана к конкретному треку на платформе. Смена ISRC означает потерю этих позиций. Сохранение ISRC даёт шанс на восстановление, но не гарантирует его - площадки не обязаны автоматически возвращать трек в те же плейлисты.
Роялти в переходный период: как не потерять выплаты
Роялти за период до takedown остаются у старого дистрибьютора и выплачиваются в обычном ритме - просто уже после того, как вы формально не являетесь его клиентом. Это не должно быть проблемой, если вы не закрываете аккаунт принудительно и не удаляете платёжные данные.
Проблемы возникают в нескольких ситуациях. Во-первых, если между takedown и появлением трека у нового дистрибьютора есть окно - трек не доступен, прослушиваний нет, роялти не начисляются. Это прямые потери. Минимизировать их можно, сократив окно: подготовить загрузку у нового дистрибьютора заранее и подать takedown только после того, как новый релиз прошёл модерацию и готов к публикации. Некоторые дистрибьюторы позволяют выставить отложенную дату публикации - это даёт возможность скоординировать момент.
Во-вторых, если у старого дистрибьютора есть минимальный порог выплат, а накопленная сумма его не достигает - деньги могут зависнуть. Перед уходом стоит уточнить политику: некоторые дистрибьюторы выплачивают остаток при закрытии аккаунта, другие - только при достижении порога, что может занять время.
В-третьих, если вы работаете через лейбл или суб-дистрибьютора, цепочка выплат сложнее. Уточните заранее, кто и кому должен в переходный период.
Метаданные: возможность исправить ошибки при переходе
Смена дистрибьютора - один из редких моментов, когда метаданные можно переписать без риска потерять историю (при условии сохранения ISRC). Если в старых релизах были ошибки в написании имён, неправильно указаны роли, пропущены авторы или некорректно заполнен тег жанра - переход это исправляет.
Но здесь есть важный нюанс. Площадки при переиндексации сопоставляют ISRC с приходящими метаданными. Если метаданные сильно изменились - другое название трека, другой основной исполнитель - система может не сопоставить новый релиз со старым. В таком случае история прослушиваний не восстановится даже при совпадающем ISRC. Поэтому принципиальные данные - название трека и имя основного исполнителя - лучше не менять при переходе. Технические поля (роли, теги, описания) менять безопасно.
О том, как устроена работа с метаданными и почему ошибки в них приводят к потере роялти, подробнее в материале «Метаданные релиза: UPC, ISRC и роли, на которых теряют деньги».
Что делать: порядок действий при смене дистрибьютора
- Соберите все ISRC и UPC до начала процедуры. Зайдите в личный кабинет текущего дистрибьютора, выгрузите или зафиксируйте коды по каждому треку и релизу. Если коды недоступны в интерфейсе - запросите их в поддержку письменно.
- Проверьте условия выхода в текущем договоре. Некоторые дистрибьюторы требуют уведомление за определённый срок или имеют условия по незакрытым авансам. Уточните, есть ли финансовые обязательства перед уходом.
- Загрузите каталог к новому дистрибьютору заранее. Используйте те же ISRC. Дождитесь, пока все треки пройдут модерацию и получат статус «готов к публикации». Только после этого инициируйте takedown у старого дистрибьютора.
- Установите отложенную дату публикации у нового дистрибьютора. Если сервис это позволяет, выставьте дату выхода так, чтобы новый релиз появился на площадках сразу после или одновременно с удалением старого. Цель - минимизировать окно недоступности.
- Сохраните доступ к старому аккаунту и актуальные платёжные реквизиты. Роялти за последние периоды придут уже после ухода. Не закрывайте аккаунт принудительно и не меняйте платёжные данные до получения финального расчёта.
- Зафиксируйте текущую статистику перед переходом. Скриншоты или выгрузки из аналитики площадок - на случай расхождений и для сравнения после переиндексации.
- После появления треков у нового дистрибьютора проверьте сопоставление. Зайдите на площадки и убедитесь, что старые страницы треков перенаправляют на новые или что счётчики восстановились. Если трек появился как новый - обратитесь в поддержку площадки с подтверждением ISRC и объяснением ситуации.
