DDEX Documentation

    Introduction to DDEX at Meta

    The intended audience of this document is music partners who use Meta's Rights Manager for Music (RM4M) to manage their content. These music partners usually want to (either/both):

    • Manage rights to sound recordings and music video references through Meta's Rights Manager
    • Manage sound recordings available in Meta's Audio Library
    Meta supports version 4.2 of the DDEX Electronic Release Notification (ERN) standard. If a music partner is unable to provide their metadata using ERN 4.2, Meta can also accept version 3.8.3. This document describes specific requirements for the Meta DDEX feed. All feeds delivered to Meta should follow either the Audio Album profile or the Single Resource Release (SRR) profile, as published by DDEX.

    The ERN spec requires these five top-level elements to be present in every XML message:

    • <MessageHeader> provides information about the message itself: a unique identification number, the sender and recipient, and a timestamp.
    • <PartyList> provides information about all the entities involved in the creation of the music work - artists, composers, labels, etc.
    • <ResourceList> contains the details about the sound recordings, music video references, and any associated artwork.
    • <ReleaseList> defines the releases that can be made from the resources in this message.
    • <DealList> defines the key commercial information for each release, such as which territories the release can be made available in, usage rights, and start date for each release.
    In accordance with the DDEX convention, the XML message filename needs to include a unique release identifier for the resource (either Album or Single Resource Release). The Release ID is the UPC, EAN, or GRid provided within the <ReleaseId> element. The <ReleaseId> element is not required for the SRR feed.

    ERN Choreography

    For data transmission, Meta supports the SFTP Batch Profile as defined in version 6.1 of the DDEX ERN Choreography Standard. This Batch Profile choreography also applies to delivery via S3.

    • The trigger to indicate that a batch has finished uploading a is zero-byte semaphore file. The name of the this file must be the string BatchComplete_ followed by the BatchId and the .xml file extension.
    • We recommend to limit the number of audio tracks per batch to 200 or fewer.
    • For music video reference delivery, we recommend delivering one video per batch.
    • Priority indicator prefix is not currently supported. Batches are ingested in order of BatchId.

    A simplified example of accepted batch choreography for an audio product delivery is as follows: 

    /20231001123000000 {batch folder}
--/888012345678 {release_id folder}
----/resources
------888012345678_1_1.flac
------888012345678_1_2.flac
------888012345678.jpg
----888012345678.xml
--BatchComplete_20231001123000000.xml

    Acknowledgement Messages

    Meta supports ERN Acknowledgement (ACK) Messages. These messages follow the 6.1 Choreography Standard and will allow you to have a much more accurate and timely understanding of the status of your content deliveries.

    The standard calls for placing all ACK files into a single /acknowledgements folder that sits at the root of your delivery location.

    All files will be named as follows: ACK_ErnMessageId_YYYYMMDDhhmmssnnn.xml

    • ErnMessageID is the MessageId value inside the XML you deliver to us that accompanies your release
    • YYYYMMDDhhmmssnnn is the timestamp at which the ACK file is placed into the /acknowledgements folder.

    We currently support the communication of two different ACK statuses:

    • SuccessfullyIngestedByReleaseDistributor - This indicates that “A Release has been successfully ingested by the ReleaseDistributor."
    • ProcessingErrorAtReleaseDistributor - This indicates that "The ReleaseDistributor has encountered a processing error with respect to the Release." With any error, we will include a short description of the specific issue inside of the ErrorText field.

    We aim to have all ACK messages deposited into the /acknowledgements folder within 3 hours of the delivery of the product it is meant to acknowledge. Partners wishing to process these messages should remove them as soon as that processing has been completed. Meta will remove any unprocessed messages approximately 7 days after delivery.

    Selecting a Release Profile

    Meta_SRP - PADPIDA2013071501L
    Meta_AAP - PADPIDA2018010804X

    Meta supports two delivery profiles. Each has a different purpose.

    Single Resource Release profile: This profile is used to deliver (a.) sound recording ownership rights on a per-track basis for audio fingerprinting, or (b.) music video ownership rights on a per-video basis for video fingerprinting. Meta does not use any album-level metadata from this feed.

    For sound recording deliveries that utilize a Single Resource feed, all Releases in the <ReleaseList> must have a ReleaseType of SingleResourceRelease. Furthermore the <SoundRecordingId> element in the <ResourceList> needs to contain an <ISRC> tag.

    For music video deliveries, all Releases in the <ReleaseList> must have a ReleaseType of VideoSingle. Furthermore the <VideoId> element in the <ResourceList> needs to contain an <ISRC> tag.

    Audio Album profile: The Audio Album profile is used to deliver audio releases with full track and release metadata. This is the only profile that can be used to make content available in Meta's suite of Audio Library products (eg. FB Reels, IG Stories).

    Each Audio Album feed must contain two types of releases:

    • At least one product-level release with a <ReleaseType> of:
      • Album
      • Single
      • EP
      • ClassicalAlbum
      • DigitalBoxSetRelease
      • User Defined: UserDefinedValue="Mini Album"
      • User Defined: UserDefinedValye="Double Album"
    • For each track, a release with a <ReleaseType> of TrackRelease.

    If you deliver your content with fingerprint rights and Audio Library rights in a single Audio Album feed:

    • The rights ownership information for any given sound recording must be associated with only one release. Any future messages containing rights ownership information for that sound recording will be treated as an update and thus overwrite previous messages.
    • You must deliver both Meta PartyIds in the <MessageHeader> as individual <MessageRecipient>s. Please see below for an example.

    Before Delivery

    1. Set up your account

    Sign up for Rights Manager and contact your partner representative. Your partner representative will create your account and set up your delivery location (S3 or SFTP) for delivering your content.

    Provide your DDEX Party ID to your partner representative. If you don’t have a DDEX Party ID, you can apply for one at http://dpid.ddex.net.

    2. Read through Meta's Sound Recording Reference Policy

    By participating in Rights Manager, you represent that your organization owns and/or controls exclusive rights to the content you include in Rights Manager in your delivered territories. References uploaded to Rights Manager and/or offered in Facebook/Instagram music products must additionally meet all of the following content standards.

    References must sufficiently distinct from other references. References unlikely to be sufficiently distinct include, but are not limited to:

    • production loops
    • soundbeds
    • sound effects
    • sound-alikes
    • karaoke recordings
    • classical music recordings of compositions in the public domain
    • meditation, yoga, or sleep music
    • DJ sets, continuous mixes, or other similar compilations
    References must be music content. References unlikely to be music content include, but are not limited to:

    • spoken word recordings
    • comedy recordings
    • film recordings (that are not the musical score to a film)
    • speeches
    • prayer recordings
    • audiobooks
    • podcasts
    • nature or wildlife recordings
    • ambient sound recordings

    ONLY DELIVER CONTENT THAT MEETS THESE STANDARDS. References uploaded to Rights Manager and/or offered in Facebook/Instagram music products that do not meet these standards may be deleted entirely and/or prevented from matching user content without notice.

    Note that as with all content uploaded to Facebook and Instagram, the relevant Community Standards apply.

    3. Send test files and validate for applicable cases

    Test both the Single Resource Release profile and the Audio Album profile. Detailed instructions for each profile are outlined below. In order to guarantee seamless ingestion, audio batches should not contain more than 200 tracks; video batches should be one video per batch.

    1. Create a folder inside your delivery location named for the BatchId (timestamp in YYYYMMDDhhmmssnnn format).
    2. Upload the test contents into this batch folder.
    3. After you’ve completed the upload of all of the files for the test, create a 0kb file whose name starts with the string BatchComplete_, followed by the same timestamp that is the BatchId, and finally the file extension .xml. The presence of this file tells Meta that the batch is ready for download and processing.

    4. Review the test batches

    After uploading the test batches, work with your partner representative to review the results and work out any kinks in the delivery choreography or XML creation.

    5. Complete end-to-end testing.

    Once your test batches look correct, deliver around 10 album profile releases and/or 10 single resource/video releases for end-to-end testing. If these are ingested without failure, your partner representative will then ask for your full catalog to be delivered.

    Message Header

    The header identifies both the sender (you) and the recipient (Meta) by the sender's unique DDEX Party ID (DPid).

    <MessageHeader>
    <MessageThreadId>1</MessageThreadId>
    <MessageId>9543BD3607862A82E04400144FEAB9A6</MessageId>
    <MessageSender>
        <PartyId>PADPIDAXXXXXXXXXXX</PartyId>
        <PartyName>
            <FullName>Example Rights Holder</FullName>
        </PartyName>
    </MessageSender>
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyName>
            <FullName>Meta_SRP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2023-09-01T18:05:17.631Z</MessageCreatedDateTime>
    <MessageControlType>LiveMessage</MessageControlType>
</MessageHeader>

    If you act as a distributor and plan to deliver sound recordings or music video references for a third party, use the <SentOnBehalfOf> element to provide the DPid of the third party. Note: this third party will need to have its own content licensing agreement with Meta.

    <MessageHeader>
    <MessageThreadId>1</MessageThreadId>
    <MessageId>9543BD3607862A82E04400144FEAB9A6</MessageId>
    <MessageSender>
        <PartyId>PADPIDAXXXXXXXXXXX</PartyId>
        <PartyName>
            <FullName>Example Distributor</FullName>
        </PartyName>
    </MessageSender>
    <SentOnBehalfOf>
        <PartyId>PADPIDAYYYYYYYYYYY</PartyId>
        <PartyName>
            <FullName>Example Rights Holder</FullName>
        </PartyName>
    </SentOnBehalfOf>
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyName>
            <FullName>Meta_SRP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2023-02-03T09:57:14Z</MessageCreatedDateTime>
</MessageHeader>

    If you are delivering content for both fingerprinting and audio library purposes, provide both Meta DPids in the <MessageHeader> as individual <MessageRecipient>s. 

    <MessageHeader>
    <MessageThreadId>1</MessageThreadId>
    <MessageId>9543BD3607862A82E04400144FEAB9A6</MessageId>
    <MessageSender>
        <PartyId>PADPIDAXXXXXXXXXXX</PartyId>
        <PartyName>
            <FullName>Example Distributor</FullName>
        </PartyName>
    </MessageSender>
    <SentOnBehalfOf>
        <PartyId>PADPIDAYYYYYYYYYYY</PartyId>
        <PartyName>
            <FullName>Example Rights Holder</FullName>
        </PartyName>
    </SentOnBehalfOf>
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyName>
            <FullName>Meta_SRP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageRecipient>
        <PartyId>PADPIDA2018010804X</PartyId>
        <PartyName>
            <FullName>Meta_AAP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2017-02-03T09:57:14Z</MessageCreatedDateTime>
</MessageHeader>

    Resource List

    The <ResourceList> contains the details about the sound recordings or music videos (primary resources) and associated artwork (secondary resources) that make up the delivery. On a 10-track Audio Album, for example, resource references A1 through A10 are the sound recordings and A11 is the album artwork. Single Resource Release feeds should not contain any artwork.

    Sound Recording IDs

    Meta requires every <SoundRecording> element to include a valid ISRC code.

    <SoundRecording>
  <ResourceReference>A1</ResourceReference>
  <Type>MusicalWorkSoundRecording</Type>
  <ResourceId>
     <ISRC>USRE50702485</ISRC>
  </ResourceId>
  <DisplayTitleText>...

    Video IDs

    Meta requires every <Video> element to include a valid ISRC code. This should be the ISRC of the video itself, not of the underlying Sound Recording.

    <Video>
  <ResourceReference>A1</ResourceReference>
  <Type>ShortFormMusicalWorkVideo</Type>
  <ResourceId>
    <ISRC>USVD35482355</ISRC>
  </ResourceId>
  <DisplayTitleText>...

    Sound Recording and Music Video Metadata

    For guidelines on how to populate the sound recording and/or music video metadata, please refer to the Music Metadata Style Guide v2.1 from the Music Business Association.

    Delivery of Artist Information

    Artist ID

    Every artist should have an associated Party identification. The ERN standard requires the provision of at least one identifier but allows for the inclusion of multiple identifiers for each Party. Each identifier may either be an International Standard Name Identifier (ISNI), a proprietary identifier, or a Meta ID.

    1. Internal ID: These IDs are created by a rights holder (label/distributor), generally for internal use.

      2. Example: <PartyId Namespace="DPID:PADPIDXXXXXXXXXXXXX">12345</PartyId>

    2. External ID: These are global identifiers for an artist, such as ISNI.

      3. Example: <PartyId IsISNI="true">0000000123456789</PartyId>

    3. Meta ID: These IDs are created by Meta. We have assigned one of these IDs to every artist available in our system. After your full catalog has been delivered, we will generate (and share) a CSV file that contains these IDs along with associated artist name information. This file will include:
      • ISRC
      • Artist name
      • Meta ID

    XML updates can thereafter be sent to backfill any available IDs in a partner's catalogue. In so doing, please provide the Meta ID with the applicable PartyID. For example:

    Facebook Single Release Profile (Fingerprint Feed):
    • <PartyId Namespace="DPID:PADPIDA2013071501L">123123456456</PartyId>
    Facebook Audio Album Profile (Audio Library Feed):
    • <PartyId Namespace="DPID:PADPIDA2018010804X">123123456456</PartyId>

    Artist Profile URL

    ERN4.2 also allows for the delivery of an artist's page URL. This can be either a Facebook profile page or an Instagram handle, or both.

    Here is a composite containing details for how all of this should look: 

    <Party>
  <PartyReference>PArtist1</PartyReference>
  <PartyName>
    <FullName>Great Artist</FullName>
  </PartyName>
  <PartyId>
    <ISNI>0000000045871863</ISNI>  <!-- ISNI value -->
    <ProprietaryId Namespace="PADPIDA9999999999Z">100123</ProprietaryId>  <!-- External ID -->
    <ProprietaryId Namespace="PADPIDA2018010804X">181077133824492</ProprietaryId>  <!-- Internal Meta ID -->
  </PartyId>
  <ArtistProfilePage>https://www.facebook.com/GreatArtist</ArtistProfilePage>
  <ArtistProfilePage>https://www.instagram.com/greatartistofficial</ArtistProfilePage>
</Party>

    Translations

    Meta supports the ingestion of artist, album, and track translation data. This data is used to help inform our search algorithm and other product implementations. If provided, users who have their devices set to a particular language will see that language's version of the artist name or track title in search results and throughout the product. To provide this data, utilize the LanguageAndScriptCode element with TitleType="TranslatedTitle", noting the language of translation, and add it to the SoundRecording and Release elements.

    Example:

    <SoundRecording>
  ...
  <DisplayTitleText>Example Title (Live)</DisplayTitleText>
  <DisplayTitle ApplicableTerritoryCode="WorldWide" IsDefault="True">
    <TitleText>Example Title (Live)</TitleText>
  </DisplayTitle>
  <DisplayTitle LanguageAndScriptCode="ja-Jpan" ApplicableTerritoryCode="Worldwide">
    <TitleText>例題 (生で)</TitleText>
  </DisplayTitle>
  <DisplayTitle LanguageAndScriptCode="ja-Latn" ApplicableTerritoryCode="Worldwide">
    <TitleText>エグザーンプル・タイタル (リブ)</TitleText>
  </DisplayTitle>
    ...
</SoundRecording>

    Sound Recording and Music Video Ownership

    Sound recording and/or music video ownership is applied using the <ResourceRightsController> tag. The example below specifies that Example Rights Holder owns the Sound Recording in Canada and Mexico. The <PartyId> must be set to the DPID of the rights owner.

    We only support values 0.0 and 100.0 for the <RightSharePercentage> tag, whereby 100.0 means that you hold ownership in the respective territories, and 0.0 means that you do not. We recommend that you initially set the value to 100.0, and set the value to 0.0 in the case of takedowns. If the <RightSharePercentage> is omitted, 100.0 is assumed.

    <ResourceList>
    <SoundRecording>
      <ResourceReference>A1</ResourceReference>
      ...
      <ResourceRightsController>
        <RightsControllerPartyReference>PRightsHolder</RightsControllerPartyReference>
          <RightsControlType>RightsController</RightsControlType>
          <RightSharePercentage>100.00</RightSharePercentage>
          <DelegatedUsageRights>
            <UseType>UserMakeAvailableUserProvided</UseType>
          </DelegatedUsageRights>
      </ResourceRightsController>
      ...
    </SoundRecording>
</ResourceList>

    Technical Sound Recording, Video, and Image Details

    In order to allow the highest possible chance of matching user-generated content, as well as the highest quality audio for our Audio Library products, Meta requires all sound recordings to be delivered in FLAC format - with at least a 44.1kHz sample rate and 16bit resolution. We can accept higher qualities as well if they are offered.

    Music video content delivered for the purposes of copyright protection should be delivered in the highest quality available to the provider. This includes, but is not limited to the following conditions:

    • Videos must be delivered in the original framerate.
      • Videos that were originally progressive must not be delivered interlaced.
      • Videos that were originally interlaced should be delivered interlaced.
      • Telecine content or pulldown flags are not allowed.
      • Videos should never be upscaled.
    • Content must be delivered in the original aspect ratio.
    • Content must be delivered in its archive format. For example, an asset that is archived as MPEG-2 PS stream cannot be used to generate a ProRes asset, or vice versa.

    Images should be delivered in either JPG or PNG format, in the highest possible quality available. However, images may not exceed 85 million pixels in size. This means that, for square images, anything over 9200x9200 pixels will cause the product to fail ingestion.

    Release List

    Single Resource Release profile

    A full product delivery of a single resource release including an ERN XML message, an audio file, and the applicable deal terms.

    • Set <ReleaseType> to SingleResourceRelease

    Audio Album profile

    Communicating The Sequencing Of Tracks

    As described in the DDEX KB , use <ResourceGroup> to communicate the track sequence using <ResourceGroupContentItem> accompanied with <ResourceType> set to SoundRecording .

    Use Cases

    Full new album

    A full product delivery of an album release including the ERN XML message, audio files, artwork files, and applicable deal terms.

    • Set <ReleaseType> to Album
    • <ReleaseResourceReferenceList>should reference all of the delivered audio and album art resources.

    Full new single (release)

    A full product delivery of a single release including the ERN XML message, audio files, artwork files, and applicable deal terms.

    • Set <ReleaseType> to Single

    Full new multi-disc

    A full product delivery of a multi-disc release including the ERN XML message, audio files, artwork files, and applicable deal terms.

    • Set <ReleaseType> to Album
    • The main release should contain multiple <ResourceGroup> s, each with a <SequenceNumber> , corresponding to the multiple discs.

    Full Update

    A full update, with new audio or image files as well as the updated ERN XML message.

    • Update both the message ID and timestamp.
    • The hashsums of the files should be different from any previous delivery.
    • Provide additional metadata updates as necessary.

    Update track metadata

    A metadata-only update, with the media files notincluded and not referenced in the ERN XML message.

    Meta supports only complete metadata updates. You must include all track metadata, including values that haven’t changed. The latest metadata update will always take precedence (ie. previously delivered metadata will be overwritten).

    • Remove the <TechnicalSoundRecordingDetails> and <TechnicalImageDetails> section for each resource, since the files are not included.
    • A common mistake is to remove the entire <Image> block rather than just the <TechnicalImageDetails> section within, and to remove all references to it. This has the incorrect effect of removing the artwork from the album entirely.

    Accepted Audio ReleaseType s

    Single Resource Release Profile Audio Album Profile
    SingleResourceReleaseAlbum
    Single
    TrackRelease
    VideoTrackRelease
    EP
    ClassicalAlbum
    DigitalBoxSetRelease
    UserDefined: UserDefinedValue="Mini Album"
    UserDefined: UserDefinedValue="Double Album"
    UserDefined: UserDefinedValue="Snippet"
    If a product is delivered to Meta and does not contain any of the above ReleaseType s, it will fail on its attempt to process through the system.

    Music Video profile

    The list of accepted <ReleaseType> s is made up of VideoSingle and VideoTrackRelease . If a product is delivered to Meta and does not contain the above <ReleaseType> s, it will not process through the system accordingly.

    Use Cases

    Full video: A full product delivery of a single release including the XML file, video file, art file, and deal terms.

    • Set <ReleaseType> to VideoSingle .

    Asset + Metadata Update: A full update with a new video file as well as an updated XML file.

    • Update both the <MessageId> and <MessageCreatedDateTime> .
    • Provide additional metadata updates as necessary.

    Metadata-Only Update:an XML-only update, with media files not included and not referenced in the XML file.

    • Meta supports only complete metadata updates. You must include all video track metadata, including values that haven’t changed.
    • The latest metadata update will always take precedence (ie. previously delivered metadata will be overwritten).
    • Delete the <TechnicalVideoDetails> and <TechnicalImageDetails> sections for each resource, since the files are not included.

    Deal List

    The <DealList> defines the key commercial information for each release, such as territories in which the release can be made available, usage rights, and the start/end dates for each release. Each <ReleaseDeal> element defines the deals for a release from the <ReleaseList> , linked to said release by its <ReleaseReference> .

    Meta reads Deals on a per-track basis, and as such, only Deals for individual TrackReleases will be processed (eg. R1, R2, etc). Any Deals referenced for a <ReleaseType> of Album, Single, or otherwise (eg. R0) will be ignored.

    Start Dates / Ends Dates for Each Feed

    Meta Single Release Profile (Fingerprint Feed)

    References will become active on the date-time specified in the <ValidityPeriod>/<StartDate> (or <StartDateTime> ). To activate a reference as soon as it is received, provide a <ValidityPeriod>/<StartDate> (or <StartDateTime> ) in the past. Marking an <EndDate> on the fingerprint feed removes the audio or video reference from Rights Manager and prevents any UGC matches from occurring.

    The following example specifies that, for user-generated content that matches to the reference, it will be blocked worldwide starting on 2023-01-10. Content blocking will end at 23:59:59 on 2023-04-26 (more on this below). Starting at 00:00:00 on 2023-04-27 and continuing indefinitely, any user-generated content uploaded to Meta's various platforms that matches to the reference will instead be monetized. 

    <Deal>
    <DealTerms>
        <TerritoryCode>Worldwide</TerritoryCode>
        <ValidityPeriod>
            <StartDateTime>2023-01-10T00:00:00</StartDateTime>
            <EndDateTime>2023-04-26T11:59:59</EndDateTime>
        </ValidityPeriod>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <UseType>UserMakeAvailableUserProvided</UseType>
        <RightsClaimPolicy>
            <RightsClaimPolicyType>BlockAccess</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>
<Deal>
    <DealTerms>
        <TerritoryCode>Worldwide</TerritoryCode>
        <ValidityPeriod>
            <StartDateTime>2023-04-27T00:00:00</StartDateTime>
        </ValidityPeriod>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <UseType>UserMakeAvailableUserProvided</UseType>
        <RightsClaimPolicy>
            <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>

    Meta Audio Album Profile (Audio Library Feed)

    The album feed accepts a start date for the references delivered. Marking an end date on the Audio Library feed removes the reference from the Audio Library only. In the case of takedowns, as with the fingerprint feed, Meta recommends sending an <EndDate> value of yesterday or prior.

    For both feeds, if the <DealTerms> do not specify an <EndDate> , the references are valid indefinitely.

    Date & Time

    Absolute vs Relative Time

    Meta distinguishes between absolute and relative time. Simply put, the difference can be attributed to whether or not a timezone offset is provided.

    Absolute time is signaled by including a timezone offset (eg. "...18:00:00Z" or "...18:00:00-07:00"). In practice, absolute time results in an action being applied at the exact same point in time ("global roll-out") across the world. For example, a StartDateTime of "2023-06-10T18:00:00Z" results in availabilities of:

    • "2023-06-10 10:00 PST" for users in California.
    • "2023-06-10 18:00 GMT" for users in the United Kingdom.
    • "2023-06-10 19:00 CET" for users in Germany.
    • "2023-06-11 03:00 JST" for users in Japan.

    Relative time is signaled by not including a timezone offset (eg. "...18:00:00"). Ordinarily, this would mean an action being applied at the same time of day for users in their local timezone ("gradual roll-out"). For example, a StartDateTime of "2023-06-10T18:00:00" would result in availabilities of:

    • "2023-06-10 18:00 PST" for users in California.
    • "2023-06-10 18:00 GMT" for users in the United Kingdom.
    • "2023-06-10 18:00 CET" for users in Germany.
    • "2023-06-11 18:00 JST" for users in Japan.

    However, due to the global nature of Meta's products, and our unique UGC-based product offering, all relative time data will instead be read as absolute time in ET. So, a StartDateTime of "2023-06-10T18:00:00" results in availabilities of:

    • "2023-06-10 15:00 PST" for users in California.
    • "2023-06-10 23:00 GMT" for users in the United Kingdom.
    • "2023-06-11 00:00 CET" for users in Germany.
    • "2023-06-11 08:00 JST" for users in Japan.

    If there is a desire by the releasing party to have the content available on a territory-by-territory basis, specific StartDateTime s with timezone offsets can be utilized. For example, to make content available on 2023-06-10 at 6pm local time in each of US, GB, DE, and JP:

    <ReleaseDeal>
   <Deal>
       <DealReleaseReference>R1</DealReleaseReference>
       <DealTerms>
           <TerritoryCode>US</TerritoryCode>
           <ValidityPeriod>
               <StartDateTime>2023-06-10T18:00:00-05:00</StartDateTime>
           </ValidityPeriod>
           <CommercialModelType>RightsClaimModel</CommercialModelType>
           <UseType>UserMakeAvailableLabelProvided</UseType>
       </DealTerms>
   </Deal>
   <Deal>
       <DealTerms>
           <TerritoryCode>GB</TerritoryCode>
           <ValidityPeriod>
               <StartDateTime>2023-06-10T18:00:00+0:00</StartDateTime>
           </ValidityPeriod>
           <CommercialModelType>RightsClaimModel</CommercialModelType>
           <UseType>UserMakeAvailableLabelProvided</UseType>
       </DealTerms>
   </Deal>
   <Deal>
       <DealTerms>
           <TerritoryCode>DE</TerritoryCode>
           <ValidityPeriod>
               <StartDateTime>2023-06-10T18:00:00+01:00</StartDateTime>
           </ValidityPeriod>
           <CommercialModelType>RightsClaimModel</CommercialModelType>
           <UseType>UserMakeAvailableLabelProvided</UseType>
       </DealTerms>
   </Deal>
   <Deal>
       <DealTerms>
           <TerritoryCode>JP</TerritoryCode>
           <ValidityPeriod>
               <StartDateTime>2023-06-10T18:00:00+09:00</StartDateTime>
           </ValidityPeriod>
           <CommercialModelType>RightsClaimModel</CommercialModelType>
           <UseType>UserMakeAvailableLabelProvided</UseType>
       </DealTerms>
   </Deal>
</ReleaseDeal>

    Interpretation of Date & Time for Fingerprint and Audio Library Content

    Date only (eg. "2023-06-10")

    • Description: Exact time (midnight ET) applied globally for all users.
    • Type: Absolute time ("global roll-out")
    • Interpretation (when the date is applied):
      • For users in US (EST): "2023-06-10T00:00:00-05:00" (or "2023-06-10T05:00:00Z")
      • For users in UK (BST): "2023-06-10T05:00:00+00:00" (or "2023-06-10T05:00:00Z")
      • For users in DE (CET): "2023-06-10T06:00:00+01:00" (or "2023-06-10T05:00:00Z")
      • For users in JP (JST): "2023-06-10T13:00:00+09:00" (or "2023-06-10T05:00:00Z")

    Date-time without timezone (eg. "2023-06-10T09:00:00")

    • Description: Exact time (parsed as ET) applied globally for all users.
    • Type: Absolute time ("global roll-out")
    • Interpretation (when the date is applied):
      • For users in US (EST): "2023-06-10T09:00:00-05:00" (or "2023-06-10T14:00:00Z")
      • For users in UK (BST): "2023-06-10T14:00:00+00:00" (or "2023-06-10T14:00:00Z")
      • For users in DE (CET): "2023-06-10T05:00:00+01:00" (or "2023-06-10T14:00:00Z")
      • For users in JP (JST): "2023-06-10T22:00:00+09:00" (or "2023-06-10T14:00:00Z")

    Date-time with timezone (eg. "2023-06-10T09:00:00Z")

    • Description: Exact time (whatever is provided) applied globally for all users.
    • Type: Absolute time ("global roll-out")
    • Interpretation (when the date is applied):
      • For users in US (EST): "2023-06-10T04:00:00-05:00" (or "2023-06-10T09:00:00Z")
      • For users in UK (BST): "2023-06-10T09:00:00+00:00" (or "2023-06-10T09:00:00Z")
      • For users in DE (CET): "2023-06-10T10:00:00+01:00" (or "2023-06-10T09:00:00Z")
      • For users in JP (JST): "2023-06-10T18:00:00+09:00" (or "2023-06-10T09:00:00Z")

    For start and end dates, Meta reserves the right to a grace period for operational overhead.

    Multiple Deals for the same Release

    In accordance with the DDEX Knowledge Base, Meta does not support multiple <ReleaseDeal> elements with an identical <DealReleaseReference>. If an identical <DealReleaseReference> is used for multiple <ReleaseDeal> elements, only the last <ReleaseDeal> element will take effect.

    Using a Custom Policy

    To apply a custom match policy, the <DealTerms> for the track must grant Meta rights for user-generated content and aided user-generated content; that is, the terms must include exactly one of the combinations of types below based off of each feed. Meta ignores any deals for other release types and any other deal terms.

    Meta <DealTerms> for Audio and Video Fingerprint Feed (typically Single Release Profile)

    <CommercialModelType> must be RightsClaimModel
    <UseType> must be UserMakeAvailableUserProvided

    Meta <DealTerms> for Audio Library Feed (typically Audio Album Profile)

    <CommercialModelType> must be RightsClaimModel
    <UseType> must be UserMakeAvailableLabelProvided

    <DealTerms> support for <ValidityPeriod>s

    Meta only supports a single <ValidityPeriod> for each <DealTerms>. To provide a new <ValidityPeriod>, you must provide an update for that Release.

    <RightsClaimPolicy>

    In order for your content to match user-generated content on Meta's platforms, you must supply a <RightsClaimPolicy> with a <RightsClaimPolicyType> value. The <RightsClaimPolicyType> defines the match policy of your reference. Matches will only be created if you include this element. The following table maps ERN allowed values to the Rights Manager action.

    ERN RightsClaimPolicyType Meta Rights Manager
    MonetizeClaim Ad Earnings
    BlockAccessBlock
    ReportUsageMonitor (Track)

    RightsClaimPolicy is a required field for all fingerprinting DealTerms, unless a takedown is being communicated.

    Custom use of <RightsClaimPolicyType> + <Condition>

    The <Condition> element within <RightsClaimPolicy> specifies a match percentage on user-generated content. Conditional policies only apply if the match duration or percentage falls under a specified threshold.

    For example, the sample below will apply a match policy of Claim Ad Earnings, but only if the duration of the match is greater than 90% of the duration of the reference file. 

    <RightsClaimPolicy>
    <Condition>
        <Value>90</Value>
        <Unit>Percent</Unit>
        <RelationalRelator>MoreThanOrEqualTo</RelationalRelator>
    </Condition>
    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
</RightsClaimPolicy>

    <TerritoryCode>

    The <TerritoryCode> can help to specify different match policies for different territories. To do so, provide multiple <Deal> elements, each with their own respective characteristics (eg. StartDate, RightsClaimPolicy).

    In this example, the deal specifies to claim ad earnings in the US and block in Canada. The match conditions are over 10% of a reference match.

    <Deal>
    <DealTerms>
        <TerritoryCode>US</TerritoryCode>
        <ValidityPeriod>
            <StartDateTime>2023-09-01T00:00:00</StartDateTime>
        </ValidityPeriod>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <UseType>UserMakeAvailableUserProvided</UseType>
        <RightsClaimPolicy>
            <Condition>
                <Value>10</Value>
                <Unit>Percent</Unit>
                <RelationalRelator>MoreThanOrEqualTo</RelationalRelator>
            </Condition>
            <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>
<Deal>
    <DealTerms>
        <TerritoryCode>CA</TerritoryCode>
        <ValidityPeriod>
            <StartDateTime>2023-09-01T00:00:00</StartDateTime>
        </ValidityPeriod>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <UseType>UserMakeAvailableUserProvided</UseType>
        <RightsClaimPolicy>
            <Condition>
                <Value>10</Value>
                <Unit>Percent</Unit>
                <RelationalRelator>MoreThanOrEqualTo</RelationalRelator>
            </Condition>
            <RightsClaimPolicyType>BlockAccess</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>

    Takedowns

    For takedowns, Meta recommends setting the <EndDate> to the date the deal expires, as explained by this DDEX knowledge base article. To remove a sound recording or music video from Rights Manager, you must provide an <EndDate> that is in the past. This applies to the single resource profile and the album release profile.

    Meta Single Release Profile Deal List (Fingerprint Feed)

    Provide an <EndDate> in the past. This will deactivate the reference in Rights Manager and remove its match policy. You can also perform a takedown by setting <RightSharePercentage> to 0.0 for Worldwide or all territories.

    Meta Audio Album Profile Deal List (Audio Library Feed)

    Provide an <EndDate> in the past. This will remove the track from the Audio Library.

    Take Down by Territory

    There are two ways to accomplish a territorial takedown:

    • provide the territories that will continue to have rights with a StartDate AND provide the territories to be removed with an EndDate; or
    • only provide the territories that will continue to have rights with a StartDate
    In either instance, the end result will be affirmative rights for one set of territories, and no more rights for the rest.

    Examples

    Example 1. Takedown by Territory

    <!--
Assuming you had ownership in the past on DE, US, CA and MX.
And you lost ownership in CA and MX.
Please note that deal definitions for the remaining territories (DE and US in this case)
need to present in the message.
-->
<DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <Deal>
            <DealTerms>
                <TerritoryCode>CA</TerritoryCode>
                <TerritoryCode>MX</TerritoryCode>
                <ValidityPeriod>
                    <StartDateTime>2023-08-15T00:00:00</StartDateTime>
                    <EndDateTime>2023-09-01T00:00:00</EndDateTime>
                </ValidityPeriod>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                <UseType>UserMakeAvailableUserProvided</UseType>
                <UseType>UserMakeAvailableLabelProvided</UseType>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
        <Deal>
            <DealTerms>
                <TerritoryCode>DE</TerritoryCode>
                <TerritoryCode>US</TerritoryCode>
                <ValidityPeriod>
                    <StartDateTime>2023-08-15T00:00:00</StartDateTime>
                </ValidityPeriod>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                <UseType>UserMakeAvailableUserProvided</UseType>
                <UseType>UserMakeAvailableLabelProvided</UseType>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>

    Example 2. Takedown of a Single Track Within a Product

    <DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <Deal>
            <DealTerms>
                <TerritoryCode>Worldwide</TerritoryCode>
                <ValidityPeriod>
                    <StartDateTime>2023-08-15T00:00:00</StartDateTime>
                    <EndDateTime>2023-09-01T00:00:00</EndDateTime>
                </ValidityPeriod>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                <UseType>UserMakeAvailableUserProvided</UseType>
                <UseType>UserMakeAvailableLabelProvided</UseType>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
        <Deal>
        <DealReleaseReference>R2</DealReleaseReference>
        <DealReleaseReference>R3</DealReleaseReference>
            <DealTerms>
                <TerritoryCode>Worldwide</TerritoryCode>
                <ValidityPeriod>
                    <StartDateTime>2023-08-15T00:00:00</StartDateTime>
                </ValidityPeriod>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                <UseType>UserMakeAvailableUserProvided</UseType>
                <UseType>UserMakeAvailableLabelProvided</UseType>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>

    Example 3. Full Takedown Using Territory List

    <!--
Assuming you had ownership in the past on DE, US, CA and MX.
And you lost ownership in all of these territories.
-->
<DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <DealReleaseReference>R2</DealReleaseReference>
        <DealReleaseReference>R3</DealReleaseReference>
        <Deal>
            <DealTerms>
                <TerritoryCode>DE</TerritoryCode>
                <TerritoryCode>US</TerritoryCode>
                <TerritoryCode>CA</TerritoryCode>
                <TerritoryCode>MX</TerritoryCode>
                <ValidityPeriod>
                    <StartDateTime>2023-08-15T00:00:00</StartDateTime>
                    <EndDateTime>2023-09-01T00:00:00</EndDateTime>
                </ValidityPeriod>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                    <UseType>UserMakeAvailableUserProvided</UseType>
                    <UseType>UserMakeAvailableLabelProvided</UseType>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>

    Example 4. Full Takedown Using Worldwide

    <!--
Assuming you have ownership in the past on DE, US, CA and MX.
And you lost ownership in all of these territories.
-->
<DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <DealReleaseReference>R2</DealReleaseReference>
        <DealReleaseReference>R3</DealReleaseReference>
        <Deal>
            <DealTerms>
                <TerritoryCode>Worldwide</TerritoryCode>
                <ValidityPeriod>
                    <StartDateTime>2023-08-15T00:00:00</StartDateTime>
                    <EndDateTime>2023-09-01T00:00:00</EndDateTime>
                </ValidityPeriod>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                    <UseType>UserMakeAvailableUserProvided</UseType>
                    <UseType>UserMakeAvailableLabelProvided</UseType>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>