Facebook Premium Music Video DDEX Requirements

The intended audience of this document is music partners who wish to deliver their Premium Music Video (PMV) content to Facebook Rights Manager to manage that content. Music Rights Manager partners have the option to:

  • Manage their rights to PMVs through Facebook's Rights Manager;
  • Manage PMVs available on Facebook for user consumption; and
  • Manage PMVs available in Facebook's Video Library.
Facebook supports version 3.8.2 of the DDEX Electronic Release Notification (ERN) standard. This document describes specific requirements for the Facebook DDEX PMV feed. All PMV feeds delivered to Facebook should follow the Video Album Release Profile as published by DDEX.

Facebook requires these four top-level elements to be present in every DDEX ERN message:

  • <MessageHeader> provides information about the message itself: a unique identification number, the sender and recipient, and a timestamp.
  • <ResourceList> contains the details about the PMVs and 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 the unique Release ID for the resource (either album or single release). The Release ID is the UPC, EAN, or GRid provided by the <ReleaseId> element. The <ReleaseId> element is not required for the SRR feed, but can be delivered if necessary.

ERN Choreography

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

  • The trigger to indicate that a Batch is complete 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.
  • Facebook does not provide FtpAcknowledgementMessages
  • We recommend that batch size be limited to 25 products or fewer while not exceeding an overall batch size of 100GB. Any products >100GB in size must be delivered as the only product in its batch.
  • Priority indicator prefix is not currently supported. Batches are ingested in order of BatchId.

A simplified example of accepted batch choreography is as follows:

20200401123000000 {batch folder}
--888012345678 {release_id folder}
----resources
------888012345678_1_1.mov {premium music video file}
------888012345678.jpg {screen capture image}
----888012345678.xml
--BatchComplete_20200401123000000.xml

The Video Album Profile

Facebook works in a slightly different way compared to other DSPs in that we utilize two different DDEX Party IDs (DPids) to signal differing intentions for the content contained within the delivery.

  • PADPIDA2013071501L - for the fingerprinting of your videos to match them against user-generated content uploads
  • PADPIDA2018010804X - for the use of your videos in Video Library or as on-demand streaming content
These will need to be delivered in accordance with your intention. More on this, plus examples, below.

All PMV deliveries to Facebook should be sent using the Video Album profile. It is used to deliver video releases with full track and release metadata. Each Video Album feed must contain two types of releases:

  • At least one release with a <ReleaseType> of VideoAlbum or VideoSingle.
  • For each video, a release with a <ReleaseType> of VideoTrackRelease.

Before Delivery

1) Send test files and validate for applicable cases.

Test delivery of both the video fingerprinting and video streaming/library <Deal>s. Detailed instructions for each <CommercialModelType> and <UseType> are outlined below.

In order to guarantee seamless ingestion, batches should not contain more than 200 files.

When you’ve uploaded all of the files for the test, create a file whose name starts with the string BatchComplete_YYYYMMDDhhmmssnnn, followed by the file extension .xml and upload that file to the root of the batch folder. The presence of this file tells Facebook that the batch is ready. The Batch ID indicated by YYYYMMDDhhmmssnnn should be the same as the batch folder name on the SFTP in which this file is contained.

2) Review the test batches.

After uploading the test batches, work with your partner representative to review the results.

3) Complete end-to-end testing.

Once your test batches look correct, deliver around 10 video releases for end-to-end testing.

Message Header

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

<MessageHeader>
    <MessageThreadId>1</MessageThreadId>
    <MessageId>9543BD3607862A82E04400144FEAB9A6</MessageId>
    <MessageSender>
        <PartyId>PADPIDAXXXXXXXXXXX</PartyId>
        <PartyName>
            <FullName>Example Label</FullName>
        </PartyName>
    </MessageSender>
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyName>
            <FullName>Facebook_FP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2017-9-01T18:05:17.631Z</MessageCreatedDateTime>
    <MessageControlType>LiveMessage</MessageControlType>
</MessageHeader>

If you are delivering video content for a third party, use the <SentOnBehalfOf> element to provide the DPid of the third party.

<MessageHeader>
    <MessageThreadId>1</MessageThreadId>
    <MessageId>9543BD3607862A82E04400144FEAB9A6</MessageId>
    <MessageSender>
        <PartyId>PADPIDAXXXXXXXXXXX</PartyId>
        <PartyName>
            <FullName>Example aggregator</FullName>
        </PartyName>
    </MessageSender>
    <SentOnBehalfOf>
        <PartyId>PADPIDAYYYYYYYYYYY</PartyId>
        <PartyName>
            <FullName>Example label</FullName>
        </PartyName>
    </SentOnBehalfOf>
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyName>
            <FullName>Facebook_FP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2017-02-03T09:57:14Z</MessageCreatedDateTime>
</MessageHeader>

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

<MessageHeader>
    <MessageThreadId>1</MessageThreadId>
    <MessageId>9543BD3607862A82E04400144FEAB9A6</MessageId>
    <MessageSender>
        <PartyId>PADPIDAXXXXXXXXXXX</PartyId>
        <PartyName>
            <FullName>Example aggregator</FullName>
        </PartyName>
    </MessageSender>
    <SentOnBehalfOf>
        <PartyId>PADPIDAYYYYYYYYYYY</PartyId>
        <PartyName>
            <FullName>Example label</FullName>
        </PartyName>
    </SentOnBehalfOf>
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyName>
            <FullName>Facebook_FP</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageRecipient>
        <PartyId>PADPIDA2018010804X</PartyId>
        <PartyName>
            <FullName>Facebook_AL</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2017-02-03T09:57:14Z</MessageCreatedDateTime>
</MessageHeader>

You can also combine the two DPids into one single <MessageRecipient>:

<MessageHeader>
    ...
    <MessageRecipient>
        <PartyId>PADPIDA2013071501L</PartyId>
        <PartyId>PADPIDA2018010804X</PartyId>
        <PartyName>
            <FullName>Facebook</FullName>
        </PartyName>
    </MessageRecipient>
    <MessageCreatedDateTime>2017-02-03T09:57:14Z</MessageCreatedDateTime>
</MessageHeader>

Resource List

The <ResourceList> contains the details about the videos (primary resources) and associated artwork (secondary resources) that make up the delivery. On a VideoSingle, for example, resource reference A1 is the video recording and A2 is the artwork or screengrab.

Video IDs

Facebook 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. More details on this later in the document.

<VideoId>
    <ISRC>USRE50702485</ISRC>
</VideoId>

Video Metadata

DisplayArtist

Facebook will work with you to ensure that your premium music videos are published to the correct artist pages. To meet this end, it is vital that you provide accurate <DisplayArtist> information in your XML. Videos will be published to the page of the first <DisplayArtist>, or to the one with SequenceNumber="1". While we cannot accept Facebook page URLs via XML at this time, if you have these URLs available, please get in contact with us and we'll work with you to have them included as part of your onboarding process.

VideoType

<VideoType> is a required field that allows for the proper classification of your video content on the platform. The allowed value set is extensive, however Facebook is primarily concerned with the following values:

Value Description
ShortFormMusicalWorkVideoA Video whose audio content corresponds exactly or approximately to that of an audio-only Single, which itself embodies at least one MusicalWork.
LyricVideoAn audio-visual Recording (often a slide show) with captions showing the lyrics.
TrailerVideoA Video created specifically to promote another Video that embodies a MusicalWork.
NonMusicalWorkTrailerA Video created specifically to promote another Video that does not embody a MusicalWork.
BehindTheScenesAn audio-visual Recording documenting events happening behind the scenes.
UserDefined: UserDefinedValue="Jukebox"A single Video containing multiple other Videos stitched together into one unit.
UserDefined: UserDefinedValue="MusicalSlate"An audio-visual Recording with no or limited visual movement. Example: an art track.

For guidelines on how to populate the remaining Video Resource metadata, please refer to the Music Metadata Style Guide v2.1 from the Music Business Association.

Video Ownership

Video ownership is applied using the <RightsController> tag under the <VideoDetailsByTerritory> element.

The example below specifies that Example Label owns the Video Recording in Canada and Mexico. The <PartyId> must be set to the DPID of the rights owner and should match the sender's <PartyId>.

We only support values 0.00 and 100 for the <RightSharePercentage> tag. 100 means that you hold ownership in the respective territories and 0.00 means that you do not. We recommend that you initially set the value to 100 and send an update with the value set to 0.00 for takedowns. If the <RightSharePercentage> is omitted, 100 is assumed.

<ResourceList>
    <Video>
        ...
        <ResourceReference>A1</ResourceReference>
        ...
        <VideoDetailsByTerritory>
            <TerritoryCode>CA</TerritoryCode>
            <TerritoryCode>MX</TerritoryCode>
            ...
            <RightsController>
                <PartyName>
                    <FullName>Example Label</FullName>
                </PartyName>
                <PartyId>PADPIDAXXXXXXXX</PartyId>
                <RightsControllerRole>RightsController</RightsControllerRole>
                <RightSharePercentage>100.00</RightSharePercentage>
            </RightsController>
            ...
        </VideoDetailsByTerritory>
        ...
    </Video>
</ResourceList>

Technical Video and Image Details

In order to ensure the highest possible level of match for UGC content, as well as highest quality for our Video Library and streaming offerings, Facebook requires premium music videos to be delivered in the highest quality available to the provider. Guidance on other quality offerings are below, however please note that videos should never be upscaled:

File Type (in order of preference) Resolutions
ProRes 422 HQ QuickTime4K, UHD, 2K, HD, SD
MPEG-4/Quicktime4K, UHD, 2K, HD, SD
MPEG-2 Program Stream854x480 (16:9), 640x480 (4:3)

General Requirements

A/V sources must be delivered in the highest quality available. This includes, but is not limited to:

  • 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.
  • Content must be delivered in the original aspect ratio.
    • Crop dimensions should be supplied for content with inactive pixels due to letterboxing, pillarboxing, or windowboxing.
  • 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.

Videos not meeting these requirements may not be published.

ProRes 422 HQ Requirements

All ProRes 422 HQ files must adhere to the iTunes Video and Audio Asset Guide from Apple, Inc. ProRes files must have the .mov extension.

Audio Track
CodecAES3 LPCM (SMPTE 302M)
Sample Rate48KHz
ChannelsStereo
TracksSingle

MPEG-4 Requirements

All Quicktime files (except ProRes) sent with the .mov extension. All MP4 files (14496-14) sent with the .mp4 extension.

Video Track
CodecH.264 Main or High Profile
BitrateUp to 1080p: 15Mbps or higher
UHD & 4K: 50Mbps or higher
GOP StructureIntra (IDR-Only)
Closed GOP with max 5 second IDR interval
ScantypeProgressive or Interlaced (must match original source scantype)
Audio Track
CodecAES3 LPCM (SMPTE 302M)
Sample Rate48KHz
ChannelsStereo
TracksSingle

MPEG-2 Program Stream Requirements

All MPEG-2 Program Stream files must adhere to MPEG-2 Part 1, Systems (ISO/IEC- 13818-1).

Video Track
CodecMPEG-2
Bitrate4Mbps or higher
GOP StructureClosed GOP with max 5 second I-Frame interval
ScantypeProgressive or Interlaced (must match original source scantype)
Audio Track
CodecMPEG-1 Layer II
Sample Rate48KHz
Bitrate384Kbps

Image Requirements

Images should be screen captures from the actual delivered video file. Do not increase the size of a smaller image to meet the minimum size standard. Only the active pixel area may be included (no letterboxing / black bars on outer portions of image).

Aspect Ratio16:9 or 4:3 (for legacy videos)
Size 3840 x 2160 @ 4K
Minimum: at least 1920 wide or 1080 high
File Extension JPEG with .jpg (quality unconstrained)
PNG with .png
Color ProfileRGB

Closed Captioning Requirements

Facebook accepts Closed Caption files in either SCC or TTML format. If your captions were authored in SCC format, they should be delivered as SCC files with a .scc file extension; if your captions were authored in TTML format, they should be delivered as TTML files with a .ttml file extension. Converting captions from one format to the other is prohibited.

  • Caption files must be delivered in the same package with the video it references.
  • Captions must be validated for proper sync against the associated video file.
  • Captions should display and synchronize to within one second of the initial, audible dialog to be represented in text.

Release List

Video Album profile

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

Use Cases

Full New Album: a full product delivery of an album release including the XML file, video files, artwork file, and deal terms.

  • Set <ReleaseType> to VideoAlbum.
  • <ReleaseResourceReferenceList> should reference all of the delivered video and album art resources.
  • As described in the DDEX KB, use <ResourceGroup> to communicate the video track sequence using <ResourceGroupContentItem> accompanied with <ResourceType> set to Video.
  • Note: although accepted by Facebook, VideoAlbum is an uncommon <ReleaseType>.

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

  • Set <ReleaseType> to VideoSingle.
  • Note: Facebook presumes that the majority of premium music video packages will be sent as VideoSingle.

Asset + Metadata Update: A full update, with new video or image files 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.

  • Facebook 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.

Release Metadata

Each <Release> within the <ReleaseList> contains the details about the video releases (the product-level release and the video track-level release) that make up the delivery. On a VideoSingle, for example, release reference R0 is the overall video product and R1 is the video track. Below are a few important fields for your delivery.

RelatedRelease

<RelatedRelease> is a required field that allows for the proper linking between the premium music video and its associated audio release. This node should be added to the VideoTrackRelease.

<Release>
    ...
    <ReleaseReference>R1</ReleaseReference>
    ...
    <ReleaseType>VideoTrackRelease</ReleaseType>
    ...
    <ReleaseDetailsByTerritory>
        ...
        <RelatedRelease>
            <ReleaseId>
                <GRid>A00000000000000001</GRid>
                <ISRC>EXMPLE000001</ISRC>  <!-- ISRC value is required -->
                <ICPN IsEan="false">190000000001</ICPN>
            </ReleaseId>
            <ReferenceTitle>
                <TitleText>Example Title</TitleText>
            </ReferenceTitle>
            <ReleaseRelationshipType>IsEquivalentToAudio</ReleaseRelationshipType>
        </RelatedRelease>
        ...
    </ReleaseDetailsByTerritory>
    ...
</Release>

Synopsis

<Synopsis> allows for a description of the premium music video to be sent along with the rest of the more standard metadata. This node should also be added to the VideoTrackRelease. Unlike <VideoType> and <RelatedRelease>, this node is optional.

<Release>
    ...
    <ReleaseReference>R1</ReleaseReference>
    ...
    <ReleaseType>VideoTrackRelease</ReleaseType>
    ...
    <ReleaseDetailsByTerritory>
        ...
        <Synopsis>The hottest pop anthem of the season! "Cool Breeze", the sizzling performance by Steve Stevenson featuring Craig Chilmark.</Synopsis>
    </ReleaseDetailsByTerritory>
    ...
</Release>

For guidelines on how to populate the remaining Video Release metadata, please refer to the Music Metadata Style Guide v2.1 from the Music Business Association.

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>, which is referenced by its <ReleaseReference>.

Facebook reads Deals on a per-track basis, and as such, Deals for individual TrackReleases should be included for processing (eg. R1, R2, etc). Deals referenced for a <ReleaseType> of VideoAlbum, VideoSingle, or otherwise (eg. R0) should not be included in delivery.

StartDates / EndDates

Fingerprinting

The references are active on the date-time specified in <ValidityPeriod>/<StartDate>. Provide a <ValidityPeriod>/<StartDate> in the past to activate the references as soon as they are received. Marking an end date for the fingerprint <Deal> deactivates the video reference in Rights Manager.

The following example specifies that user-uploaded versions of this video reference will be blocked worldwide between 2018-01-10 and 2018-04-26, then will not be blocked from 2018-04-27 onward.

<Deal>
    <DealTerms>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <Usage>
            <UseType>UserMakeAvailableUserProvided</UseType>
        </Usage>
        <TerritoryCode>Worldwide</TerritoryCode>
        <ValidityPeriod>
            <StartDate>2018-01-10</StartDate>
            <EndDate>2018-04-26</EndDate>
        </ValidityPeriod>
        <RightsClaimPolicy>
            <RightsClaimPolicyType>BlockAccess</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>
<Deal>
    <DealTerms>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <Usage>
            <UseType>UserMakeAvailableUserProvided</UseType>
        </Usage>
        <TerritoryCode>Worldwide</TerritoryCode>
        <ValidityPeriod>
            <StartDate>2018-04-27</StartDate>
        </ValidityPeriod>
        <RightsClaimPolicy>
            <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>

Note: Facebook does not currently offer monetization on user-uploaded content, so all Monetize policies will default to ReportUsage.

On-Demand Streaming and/or Video Library

The references will be available for use or streaming on the <StartDate> delivered in the XML. Marking an <EndDate> for this <UseType> removes the reference from the Video Library or from streaming on the platform.

The following example specifies that the reference will be available for streaming in the US starting on 2020-04-01, and in Video Library in CA on 2020-04-15.

<Deal>
    <DealTerms>
        <CommercialModelType>AdvertisementSupportedModel</CommercialModelType>
        <Usage>
            <UseType>OnDemandStream</UseType>
        </Usage>
        <TerritoryCode>US</TerritoryCode>
        <ValidityPeriod>
            <StartDate>2020-04-01</StartDate>
        </ValidityPeriod>
    </DealTerms>
</Deal>
<Deal>
    <DealTerms>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <Usage>
            <UseType>UserMakeAvailableLabelProvided</UseType>
        </Usage>
        <TerritoryCode>CA</TerritoryCode>
        <ValidityPeriod>
            <StartDate>2020-04-15</StartDate>
        </ValidityPeriod>
    </DealTerms>
</Deal>

For all usages -- fingerprinting, Video Library, or streaming -- if the <DealTerms> do not specify an <EndDate>, the references are valid indefinitely.

Date & Time

Absolute vs Relative Time

Facebook 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:00Z" or "...18:00-0700"). 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 "2018-01-01T18:00Z" results in availabilities of:

  • "2018-01-01 10:00 PST" for users in California.
  • "2018-01-01 18:00 GMT" for users in the United Kingdom.
  • "2018-01-01 19:00 CET" for users in Germany.
  • "2018-01-02 03:00 JST" for users in Japan.

Relative time is signaled by not including a timezone offset (eg. "...18:00:00"). In practice, relative time results in an action being applied at the same time of day for users in their local timezone ("gradual roll-out"). For example, a <StartDateTime> of "2018-01-01T18:00" results in availabilities of:

  • "2018-01-01 18:00 PST" for users in California.
  • "2018-01-01 18:00 GMT" for users in the United Kingdom.
  • "2018-01-01 18:00 CET" for users in Germany.
  • "2018-01-01 18:00 JST" for users in Japan.

For any delivery of fingerprint data, Facebook only supports absolute date-time. For any delivery of Video Library or streaming data, Facebook supports both absolute and relative date-time.

Interpretation of Date & Time for Fingerprint Content

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

  • Description: Exact time (midnight PST) applied globally for all users.
  • Type: Absolute time ("global roll-out")
  • Interpretation (when the date is applied):
    • For users in US (EDT): "2018-06-10T03:00-0400" (or "2018-06-10T07:00Z")
    • For users in UK (BST): "2018-06-10T08:00+0100" (or "2018-06-10T07:00Z")
    • For users in JP (JST): "2018-06-10T16:00+0900" (or "2018-06-10T07:00Z")

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

  • Description: Exact time (parsed as PST) applied globally for all users.
  • Type: Absolute time ("global roll-out")
  • Interpretation (when the date is applied):
    • For users in US (EDT): "2018-06-10T13:00-0400" (or "2018-06-10T17:00Z")
    • For users in UK (BST): "2018-06-10T18:00+0100" (or "2018-06-10T17:00Z")
    • For users in JP (JST): "2018-06-11T02:00+0900" (or "2018-06-10T17:00Z")

Date-time with timezone (eg. "2018-06-10T09: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 (EDT): "2018-06-10T05:00-0400" (or "2018-06-10T09:00Z")
    • For users in UK (BST): "2018-06-10T10:00+0100" (or "2018-06-10T09:00Z")
    • For users in JP (JST): "2018-06-10T18:00+0900" (or "2018-06-10T09:00Z")

Interpretation of Date & Time for Video Library or Streaming Content

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

  • Description: Midnight local time for each user.
  • Type: Relative time ("gradual roll-out")
  • Interpretation (when the date is applied):
    • For users in US (EDT): "2018-06-10T00:00-0400" (or "2018-06-10T04:00Z")
    • For users in UK (BST): "2018-06-10T00:00+0100" (or "2018-06-09T23:00Z")
    • For users in JP (JST): "2018-06-10T00:00+0900" (or "2018-06-09T18:00Z")

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

  • Description: Specified local time for each user.
  • Type: Relative time ("gradual roll-out")
  • Interpretation (when the date is applied):
    • For users in US (EDT): "2018-06-10T09:00-0400" (or "2018-06-10T13:00Z")
    • For users in UK (BST): "2018-06-10T09:00+0100" (or "2018-06-10T08:00Z")
    • For users in JP (JST): "2018-06-10T09:00+0900" (or "2018-06-10T00:00Z")

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

  • Description: Exact time applied globally for all users.
  • Type: Absolute time ("global roll-out")
  • Interpretation (when the date is applied):
    • For users in US (EDT): "2018-06-10T05:00-0400" (or "2018-06-10T09:00Z")
    • For users in UK (BST): "2018-06-10T10:00+0100" (or "2018-06-10T09:00Z")
    • For users in JP (JST): "2018-06-10T18:00+0900" (or "2018-06-10T09:00Z")

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

Multiple Deals for the same Release

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

Using a Custom Policy Inline

To apply a custom match policy, the <DealTerms> for the track must grant Facebook 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. Facebook ignores any deals for other release types and any other deal terms.

Facebook <DealTerms> for Video Fingerprinting

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

Facebook <DealTerms> for On-Demand Video Streaming

<CommercialModelType> must be AdvertisementSupportedModel
<UseType> must be OnDemandStream or Stream

Facebook <DealTerms> for Video Library

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

<DealTerms> support for <ValidityPeriod>s

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

<RightsClaimPolicy>

For your uploaded content to match user content on Facebook, you must supply <RightsClaimPolicy>. Per DDEX standards, when you supply this tag, at minimum, it must contain <RightsClaimPolicyType>. Here's an example:

<RightsClaimPolicy>
    <RightsClaimPolicyType>ReportUsage</RightsClaimPolicyType>
</RightsClaimPolicy>

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

<RightsClaimPolicyType>

Defines the Rights Manager policy for the video. Match rules are only created if you include this value. The following table maps DDEX tags to the Rights Manager action. Please note that Facebook does not currently offer monetization on user-uploaded content, so all Monetize policies will default to ReportUsage.

DDEX RightsClaimPolicyType Facebook Rights Manager
MonetizeClaim Ad Earnings
BlockAccessBlock
ReportUsageMonitor

Custom use of <RightsClaimPolicyType> + <Condition>

The <RightsClaimPolicy> and <Condition> specifies match percentage on UGC content. Conditional policies only apply if the match duration or percentage exceeds/falls under a specified threshold.

For example, the sample below will apply a match policy of BlockAccess, but only if the duration of the match is greater than 90% of the duration of the reference file. <ReferenceCreation> is not supported at this moment, and the condition is always applied to the reference resource, not to the consumer resource.

<Condition>
    <Value>90</Value>
    <Unit>Percent</Unit>
    <RelationalRelator>MoreThanOrEqualTo</RelationalRelator>
</Condition>
<RightsClaimPolicyType>BlockAccess</RightsClaimPolicyType>

<TerritoryCode>

The <TerritoryCode> can specify different policies for different territories. Multiple <Deal> tags allow different territories to have different rules such as start date or policy.

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>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <Usage>
            <UseType>UserMakeAvailableUserProvided</UseType>
        </Usage>
        <TerritoryCode>US</TerritoryCode>
        <ValidityPeriod>
            <StartDate>2017-09-01</StartDate>
        </ValidityPeriod>
        <RightsClaimPolicy>
            <Condition>
                <Value>10</Value>
                <Unit>Percent</Unit>
                <RelationalRelator>MoreThanOrEqualTo</RelationalRelator>
            </Condition>
            <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>
<Deal>
    <DealTerms>
        <CommercialModelType>RightsClaimModel</CommercialModelType>
        <Usage>
            <UseType>UserMakeAvailableUserProvided</UseType>
        </Usage>
        <TerritoryCode>CA</TerritoryCode>
        <ValidityPeriod>
            <StartDate>2017-09-01</StartDate>
        </ValidityPeriod>
        <RightsClaimPolicy>
            <Condition>
                <Value>10</Value>
                <Unit>Percent</Unit>
                <RelationalRelator>MoreThanOrEqualTo</RelationalRelator>
            </Condition>
            <RightsClaimPolicyType>BlockAccess</RightsClaimPolicyType>
        </RightsClaimPolicy>
    </DealTerms>
</Deal>

Takedowns

For takedowns, Facebook recommends setting the <EndDate> to the date the deal expires, as explained by this DDEX knowledge base article. To remove a Video from Rights Manager, you must provide an <EndDate> that is in the past.

Fingerprinting

Provide an <EndDate> in the past. This will deactivate the reference from Rights Manager fingerprinting and remove the match policy for the video. In concert, please also set <RightSharePercentage> to 0.00 for either Worldwide or all territories listed individually.

On-Demand Video Streming

Provide an <EndDate> in the past or remove the streaming <Deal> entirely. This will remove the streaming video from the platform.

Video Library

Provide an <EndDate> in the past or remove the Video Library <Deal> entirely. This will remove the video from the Video Library.

Take Down by Territory

To remove rights in the <DealTerms> for one or more territories but continue to assert rights in others, simply supply the <TerritoryCode>s in which you still want to assert rights. Ownership will be removed in all omitted territories.

Examples

Example 1: Takedown by territory

<!--
Assuming the ownership in the past was in DE, US, CA and MX, 
and ownership has been lost in CA and MX.
Please note that deal definitions for the remaining territories (DE and US in this case) 
need to be present in the message.
-->
<ResourceList>
    <Video>
        ...
        <VideoDetailsByTerritory>
            <TerritoryCode>DE</TerritoryCode>
            <TerritoryCode>US</TerritoryCode>
            <RightsController>
                <PartyName>
                    <FullName>...</FullName>
                </PartyName>
                <PartyId>PADPIDAXXXXXXXX</PartyId>
                <RightsControllerRole>RightsController</RightsControllerRole>
                <RightSharePercentage>100.00</RightSharePercentage>
            </RightsController>
        </VideoDetailsByTerritory>
        ...
    </Video>
</ResourceList>
...
<DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <Deal>
            <DealTerms>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                <Usage>
                    <UseType>UserMakeAvailableUserProvided</UseType>
                </Usage>
                <TerritoryCode>DE</TerritoryCode>
                <TerritoryCode>US</TerritoryCode>
                <ValidityPeriod>
                    <StartDate>2017-10-12</StartDate>
                </ValidityPeriod>
                <RightsClaimPolicy>
                    <RightsClaimPolicyType>Monetize</RightsClaimPolicyType>
                </RightsClaimPolicy>
            </DealTerms>
        </Deal>
<!-- Including territories to be removed is optional for territorial takedown -->
        <Deal>
            <DealTerms>
                <CommercialModelType>RightsClaimModel</CommercialModelType>
                <Usage>
                    <UseType>UserMakeAvailableUserProvided</UseType>
                </Usage>
                <TerritoryCode>CA</TerritoryCode>
                <TerritoryCode>MX</TerritoryCode>
                <ValidityPeriod>
                    <EndDate>2017-10-15</EndDate>
                </ValidityPeriod>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>

Example 2: Full takedown using territory list

<!--
Assuming the ownership in the past was in DE, US, CA and MX, 
and ownership has been lost in all of these territories.
-->
<ResourceList>
    <Video>
        ...
        <VideoDetailsByTerritory>
            <TerritoryCode>DE</TerritoryCode>
            <TerritoryCode>US</TerritoryCode>
            <TerritoryCode>CA</TerritoryCode>
            <TerritoryCode>MX</TerritoryCode>
            <RightsController>
            <PartyName>
                <FullName>...</FullName>
            </PartyName>
            <PartyId>PADPIDAXXXXXXXX</PartyId>
            <RightsControllerRole>RightsController</RightsControllerRole>
                <RightSharePercentage>0.00</RightSharePercentage>
            </RightsController>
        </VideoDetailsByTerritory>
        ...
    </Video>
</ResourceList>
...
<DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <Deal>
        <DealTerms>
            <CommercialModelType>RightsClaimModel</CommercialModelType>
            <Usage>
                <UseType>UserMakeAvailableUserProvided</UseType>
            </Usage>
            <TerritoryCode>DE</TerritoryCode>
            <TerritoryCode>US</TerritoryCode>
            <TerritoryCode>CA</TerritoryCode>
            <TerritoryCode>MX</TerritoryCode>
            <ValidityPeriod>
                <EndDate>2017-10-15</EndDate>
            </ValidityPeriod>
        </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>

Example 3: Full takedown using “Worldwide”

<!--
Assuming the ownership in the past was in DE, US, CA and MX, 
and ownership has been lost in all of these territories.
-->
<ResourceList>
    <Video>
        ...
        <VideoDetailsByTerritory>
            <TerritoryCode>Worldwide</TerritoryCode>
            <RightsController>
            <PartyName>
                <FullName>...</FullName>
            </PartyName>
            <PartyId>PADPIDAXXXXXXXX</PartyId>
            <RightsControllerRole>RightsController</RightsControllerRole>
                <RightSharePercentage>0.00</RightSharePercentage>
            </RightsController>
        </VideoDetailsByTerritory>
        ...
    </Video>
</ResourceList>
...
<DealList>
    <ReleaseDeal>
        <DealReleaseReference>R1</DealReleaseReference>
        <Deal>
            <DealTerms>
            <CommercialModelType>RightsClaimModel</CommercialModelType>
            <Usage>
                <UseType>UserMakeAvailableUserProvided</UseType>
            </Usage>
            <TerritoryCode>Worldwide</TerritoryCode>
            <ValidityPeriod>
                <EndDate>2017-10-15</EndDate>
            </ValidityPeriod>
            </DealTerms>
        </Deal>
    </ReleaseDeal>
</DealList>

Links to DDEX Standards