Twitter Pre Roll Media Creatives Issue


#1

As Per https://dev.twitter.com/ads/campaigns/video-views-preroll-objective, we need to create a Media Creative associated with a line item.

Ad Account "18ce54ewujg"
We have a campaign "94ttx"
Line Item “9juph” for which we created a Media Creative via Ads API, now while fetching the Media Creatives associated with this campaign we are getting more and more creative objects in the https://dev.twitter.com/ads/reference/get/accounts/account_id/media_creatives as the campaign spends.

We were under the impression that media creatives are specifically user/account owned objects created either natively/ads api, but as the ad is spending more and more its returning objects (tweet ids) which do not belong to the ad account

Example of few tweet ids are 892037443913883648, 892065068694724608, 892082683697799168

For each media_creative imported/created we show a unique ad in our UI, but in this case the ads are growing as the spend increases.

Can someone please guide us with the right UX here, maybe we missed something at our end. Would like to rectify that and make the behaviour same as native


#2

Thanks for the question, @abhishek_pyro.

We’re only seeing a single media creative entity:

$ twurl -H ads-api.twitter.com "/2/accounts/18ce54ewujg/media_creatives?line_item_id=9juph&with_deleted=true"
{
  "request": {
    "params": {
      "with_deleted": true,
      "account_id": "18ce54ewujg",
      "line_item_id": "9juph"
    }
  },
  "next_cursor": null,
  "data": [
    {
      "line_item_id": "9juph",
      "landing_url": null,
      "serving_status": "ACTIVE",
      "id": "1cvl5",
      "created_at": "2017-07-28T19:19:24Z",
      "account_media_id": "2px29",
      "updated_at": "2017-07-28T19:19:25Z",
      "approval_status": "ACCEPTED",
      "deleted": false
    }
  ]
}

It’s possible that you’re seeing many promoted_tweets entities being returned when making a request to the GET accounts/:account_id/promoted_tweets endpoint for that line item (9juph). This is something we’re aware of and actively investigating.

In this example, given that this is a VIDEO_VIEWS_PREROLL campaign, the ad is the video itself. Taking the account_media_id, from above:

$ twurl -H ads-api.twitter.com "/2/accounts/18ce54ewujg/account_media/2px29"
{
  "request": {
    "params": {
      "account_media_id": "2px29",
      "account_id": "18ce54ewujg"
    }
  },
  "data": {
    "video_id": "13_891015157777911808",
    "media_url": null,
    "creative_type": "PREROLL",
    "vast_url": null,
    "id": "2px29",
    "account_id": "18ce54ewujg",
    "created_at": "2017-07-28T19:19:21Z",
    "updated_at": "2017-07-28T19:19:21Z",
    "deleted": false
  }
}

The ad is 13_891015157777911808. You can retrieve additional information using the GET accounts/:account_id/videos endpoint. You should not need to make any requests to the GET accounts/:account_id/promoted_tweets endpoint in this case.

Please let us know whether this helps clarify.


#3

Thanks for the help here, my bad I assumed this was coming via the Media Creatives end point.

Regarding GET accounts/:account_id/promoted_tweets, the logic we have in our app is we make the batch call for all tweets (to save on multiple single calls and to avoid rate limit) and then resolve its parents on the basis of its line item id, its the case that Pre Roll items are being associated with the tweets returned in this call (many tweets for one pre roll line item).

The reason was that natively we can associate tweets as well as videos with a Pre Roll campaign so we used to fetch and associate both Media/Tweets with the line item (since we weren’t clear on the behaviour).

Thank you for your quick help on this, we will add this logic at our end.


#4

That makes a lot of sense. We are discussing ways to prevent these promoted_tweets entities from being returned.

I appreciate the follow up, @abhishek_pyro! If you have any follow ups, please don’t hesitate to reach out.

Thanks again!


#5

We are discussing ways to prevent these promoted_tweets entities from being returned.

Following up here. @abhishek_pyro: confirming this has been resolved. Thanks!