Spotify Onboarding Guideline

Version v2.14

You can download a version of the below guidelines at this link: Spotify Onboarding Guideline v2.14

Overview

This document is intended to provide information and advice for setting up your direct feed and delivering content to Spotify, along with specific requirements for delivering DDEX. Please ensure this document is read by everyone involved in the feed setup and managing deliveries as it includes information to avoid common mistakes we’ve seen in previous integrations.

The integration will be handled by Spotify Content Provider Operations. If you have any questions please reach out.

1. Delivery

1.1 Validation and Testing

All XML's must be verified against the DDEX XSD before delivery to Spotify. This will allow you to identify any errors that may be present in your delivery and will save both our time and yours.

During the testing process it's important to keep previous versions of deliveries saved (including the XML) so that you can return to an earlier version if necessary. Please make note of all changes and communicate them to Spotify when delivering a test product. It is also important that you only make changes to the delivery or metadata that Spotify have requested during the testing process. The tests we require are as follows:

1. An insert with a product type of ‘album’

2. An update to add a new territory to the same UPC and change the product type to ‘ep’

3. An update to set a global timed release for all tracks on the same UPC and change the product type to ‘single’

4. An update to remove streaming rights to track 1 on the same UPC and change the product type to ‘compilation’

5. A takedown for the whole product

These test deliveries must also include the following artist roles: main artist, featured artist, producer and remixer at product level; and main artist, featured artist, composer, lyricist, producer and remixer at track level. In addition, you will need to deliver a second product to demonstrate your ability to communicate classical-music metadata:

1.2 Instant-Grat Releases

Instant-grat setups are not supported by Spotify. Products delivered in this way will appear on artist page with only X amount of tracks live and with no indication that it's a pre-order / pre-stream. This causes confusion for users and leads to many complaints that the album is 'broken'. Followers receive a notification to tell them the album is released, when in fact it isn't.

Once the full album goes live, ie. remaining tracks are switched on, no further notification is sent to drive followers to the actual album release on release day. Not only is this a bad experience for users, it's a bad marketing experience for the label and artist.

For this reason we may take down releases that are delivered in this format. In order for single tracks to be available ahead of the full product release you will need to deliver them as separate single releases instead.

1.3 Track Linking

Track linking is a process which groups recordings that have been ingested from different sources. It is specifically designed to provide a better user experience by removing duplicate tracks from the charts section, popular tracks section, and avoiding gaps in playlists due to territorial availability. Tracks that are linked will subsequently share a play count.

Track linking is never 100% guaranteed. When attempting to track link two versions of a recording, the metadata should be as identical as possible (i.e. duration, title, version, artist, ISRC), and the audio used should be the exact same. Chances of track linking are decreased with each differing piece of metadata between the two tracks. Newly delivered recordings which are unmatched to any existing recordings will create new Spotify recording groups, which have a unique play count. This is calculated for each different recording of a composition.

To ensure there is no disruption in service please ensure all replacement content is:

1. Exactly the same as the initial delivery in regards to track audio, duration, title, version, artists, and ISRC to encourage track linking

2. Delivered at least 5 business days in advance of the earliest live date

To minimise disruption in user experience:

1. Please wait until both releases are live in the client, and see if they have linked by comparing the play counts prior to removing the old content

2. Alternatively, if you wish to remove the old content at the same time the new content goes live, please make sure the old content has an end date which matches the live date of the new content, or a takedown to take effect the same day as the new content goes live.

Disclaimer: please note that during this period of transition there may be some fluctuation in the popular tracks section of your artist page; this is normal and you should find that popular tracks normalise within 72 hours of the new content being live on the client.

1.4 Product Primary ID and ISRC Codes

The product Primary ID is used to identify your product within the Spotify backend systems. Where possible the Primary ID should always be a UPC or EAN. For DDEX the Primary ID is the product folder name - this should also be referenced within the element.

When an Insert is delivered through your feed with a Primary ID that doesn’t match an existing product, it will create a new product. When an Insert, Update or Takedown is delivered through your feed with a Primary ID matching an existing product, the delivery will apply to the existing product.

In addition, all tracks must be delivered with valid and registered ISRC codes.

1.5 Product Structure

The original Insert delivery of a product must contain all assets and reference all tracks, even if some of the tracks will not be made available to play on the service. All tracks referenced in an XML must be present in the delivery otherwise ingestion will fail. The disc / track structure of a product cannot be altered once it is first ingested, meaning that tracks or discs cannot be added or removed nor can the number of tracks per disc be changed. A track can be made unavailable by delivering an Update without clearance rights for that track but you should not attempt to remove that track from the product.

To change the structure of a product you will need to redeliver an amended version under a new UPC / Primary ID and then takedown the previous version once you have allowed 5 business days for track linking to occur (see section 1.3 Track Linking).

1.6 Required Metadata Fields

We require all content to be delivered with the name of the record label, and the copyright P and C lines at product level. We will request updates for any content which does not have this information.

1.7 Minimum Track Duration

The track duration for all audio files delivered to Spotify must be at least 2 seconds.

1.8 Timed Releases

All content delivered with a sales start date and time is subject to Spotify Service Level Guidelines. Content must be fully delivered in a timely manner (5 business days ahead of earliest sales start date) in order to be published according to the specified sales start date/time. Content providers must sanity check the sales start date/time using Spotify Catalogue Manager. All times displayed are local time, according to the time zones specified in Spotify Service Level Guidelines.

We advise sending a test delivery, checking Spotify Catalogue Manager to confirm sales start date/time has been ingested correctly, then check the Spotify client to confirm the content has gone live as expected. Please reach out to Content Operations should you have any queries regarding your test delivery.

2. DDEX

Spotify accepts DDEX deliveries of ERN 3.8 and above. You will need to provide Spotify with your DDEX PartyName and PartyID before you begin delivering content. Your deliveries must contain these as they will be used to issue royalties for your content, so it is essential they correspond exactly to what we have in our systems. Any deliveries which do not contain both your Party Name and Party ID will fail ingestion.

Spotify’s DDEX PartyName and PartyID are:

PartyName: Spotify PartyID: PADPIDA2011072101T

2.1 Manifest File

The Manifest file, otherwise known as the ManifestMessage or BatchComplete file, must not be empty. Although the DDEX standard allows for an empty file in exceptional circumstances, we require the file to be populated fully.

2.2 Delivery Structure

Deliveries must follow the DDEX standard for file-naming and structure. It is essential to include a BatchComplete file once all files belonging to a delivery and all its products have been uploaded completely. The BatchComplete file must contain the necessary information as specified in the DDEX standard. Below is an example of how the delivery should be structured and named:

|- 20161024145603123/

|- 992348492819/

|- 992348492819.xml

|- resources/

|- 992348492819_01_001.flac

|- ...

|- 992348492819.tif

|- BatchComplete_ 20161024145603123.xml

2.3 Deal Terms

Spotify require the Commercial Model and Usage types displayed below. We will ignore any additional Commercial Model Types and Use Types that are sent in the XML.

<Deal>

<CommercialModelType>SubscriptionModel</CommercialModelType>

<Usage>

<UseType>ConditionalDownload</UseType>

<UseType>Stream</UseType>

</Usage> ... <Deal>

<CommercialModelType>AdvertisementSupportedModel</CommercialModelType>

<Usage>

<UseType>Stream</UseType>

</Usage>

Please note that, unless otherwise agreed, tracks / products must be made available for both advertisement-supported (Free) and subscription (Premium) tiers at the same time - if the availability of either tier is delivered with a different start date or not at all then the track / product will not be made available until both rights are present.

2.4 File Formats

Accepted audio formats are the Free Lossless Audio Codec (FLAC) or Waveform Audio File Format (WAVE, or more commonly known as WAV). Audio shall be 16- bit or 24-bit 2-channel with a 44.1kHz or higher sample rate. WAVE files must only use format code 0x0001(WAVE_FORMAT_PCM) and never 0xFFFE(WAVE_FORMAT_EXTENSIBLE). WAVE files must have valid fmt and data subchunks, and contain nothing other than audio data after the beginning of the data subchunk. Only full tracks are of interest and ‘sample clips’ shall never be delivered. FLAC format is strongly preferred over WAVE.

Images should be delivered in the highest resolution available, preferably in a format using lossless encoding. The minimum dimension in either width or height of a cover art image asset is 640px. Do not upscale images. For cover art, the preferred aspect ratio is 1:1. To guarantee ingestion, all images should be RGB encoded using 24 bits per pixel. If transcoding to the format used in delivery is a lossy operation, please raise the issue in tech-to-tech discussion prior to doing so.

Accepted formats in order of preference are: TIFF, PNG or JPEG.

2.5 Release Types

The DDEX standard includes the release types of ‘Album’, ‘Single’ and ‘ClassicalAlbum’. However you can also communicate a release type of ‘EP’ or ‘Compilation’ as a user-defined value, for example:

<ReleaseType UserDefinedValue="EP">UserDefined</ReleaseType>

<ReleaseType UserDefinedValue="Compilation">UserDefined</ReleaseType>

2.6 Timed Releases

Please refer to DDEX.net for information on anything related to deals and commercial aspects. You can find useful information here on specifying sales start dates/times and handling different time zones.

2.7 Purge Message

We do not currently support the PurgeReleaseMessage; please do not deliver these as they will fail ingestion.