Content ID deliveries: DDEX or YouTube XML?

The features described in this article are available only to partners who use YouTube's Content ID matching system.

Content ID is now supported in DDEX. All music partners are encouraged to use DDEX for all Content ID deliveries going forward for the following reasons:

The Content Delivery team recently launched a new processing pipeline that runs fully on Google technologies. The new pipeline brings massive improvements in terms of reliability, speed, and usability (reporting, search indexing in “CMS”, etc.). We're in the process of moving metadata formats over to this new pipeline, and we'll only be moving the ones that we have a long-term commitment to (for music, that is DDEX and not YouTube's XML format).

In addition to the technical improvements brought about by the new pipeline, the move to DDEX also has some operational benefits for partners:

  • Partners have the option of unifying their CID and Art Track ingestions into a single delivery.
  • It no longer requires partners to store our internal Asset IDs/Reference IDs as they can now deliver and update using industry codes (ISRC) or their Proprietary IDs (Custom IDs).
  • Complex operations like removing a track from Content ID are now very simple. A DDEX Takedown will automatically deactivate all the appropriate references without the need to specify reference IDs. Similarly, references can be reactivated by simply specifying a deal and an ISRC. No need to manually reactivate by reference ID or redeliver the binaries.
  • Content ID feeds are now fully idempotent. Accidentally resubmitting the same feed will not create duplicate assets.
  • Maintenance cost - For as long as DDEX remains a widely adopted industry standard for music, we will support it. Which means no music label will have to maintain any YouTube-specific infrastructure.
Was this article helpful?
How can we improve it?