One of the most frequently asked questions is how to tackle the problem of replicating the 'copy creatives' functionality in the DFP UI. While most of the time it's as simple as this trio-trio-trio of steps:
- Fetch a creative using getCreativesByStatement.
- Give it a unique name.
- Create a new copy on the DFP server.
Some creative types are weak against copying techniques such as making a copy of an image creative with existing assets. The process might be a bit more complicated, but I promise you, we won’t let you walk in the tall grass alone. In the past, the asset information lived in a variety of different places. Custom, image, and template creatives all had assets defined specifically for their type, nested in non-standard locations. You then had to go and look for an assetUrl to download into a byte array so that you could set it on a new asset object. On top of this, not every creative had an assetUrl. So in some cases, the task was all but impossible.
The good news is, we’ve refactored our creative types to use the CreativeAsset object, so that each is in a more canonical location, as well as to allow for the reuse of assetIds. Rather than having an assortment of fields - different for each creative type - you have one neat asset object to encapsulate all of them. What does this mean for you? You can reuse your assets across multiple types of creatives without having to write code to handle each different type of creative. All you have to do is extract the CreativeAsset object, leaving the ID, and set it on a new creative.
You can mimic this by following an example (like this one for Java) for copying assets between image creatives.
It's super effective.
As usual, remember that no question is too Farfetch'd and feel free to reach out to us with any questions or concerns you have!
- Nicholas Chen, DFP API Team
