Problem tracking data on ad spend


#1

Hello everyone,

We have a problem tracking spend data for several accounts. We’ll be using @youlaapp (account ID 18ce54f4e4n) in this topic as an example.

We’re using the following method to gather spend data -
https://dev.twitter.com/ads/reference/1/get/stats/accounts/account_id

We are sending request -
https://ads-api.twitter.com/1/stats/accounts/18ce54f4e4n
entity=CAMPAIGN&granularity=DAY&metric_groups=ENGAGEMENT%2CBILLING&placement=ALL_ON_TWITTER&entity_ids=83tad&start_time=2017-05-31&end_time=2017-06-01

And getting this data in return -
{“data_type”:“stats”,“time_series_length”:1,“data”:[{“id”:“83tad”,“id_data”:[{“segment”:null,“metrics”:{“impressions”:[6795],“tweets_send”:null,“billed_charge_local_micro”:[5439488],“qualified_impressions”:null,“follows”:[1],“app_clicks”:[15],“retweets”:null,“likes”:[1],“engagements”:[50],“clicks”:[34],“card_engagements”:[15],“replies”:null,“url_clicks”:null,“billed_engagements”:[2],“carousel_swipes”:null}}]}],“request”:{“params”:{“start_time”:“2017-05-30T21:00:00Z”,“segmentation_type”:null,“entity_ids”:[“83tad”],“end_time”:“2017-05-31T21:00:00Z”,“country”:null,“placement”:“ALL_ON_TWITTER”,“granularity”:“DAY”,“entity”:“CAMPAIGN”,“platform”:null,“metric_groups”:[“ENGAGEMENT”,“BILLING”]}}}

Accordingly to documentation, spend is billed_charge_local_micro / 1000, which means 5439.488$ for @youlaapp.
But Twitter Ads cabinet shows much smaller amounts (screenshot attached).

How can we resolve the issue?


#2

Hi @HttpoolRu_Ads,

Could you check two things?

1 - Are you using the same Date window? That could be the problem.

2 - With the API you’re requesting only stats in Twitter placement “ALL_ON_TWITTER”, could you do the request again but with “PUBLISHER_NETWORK” in PLACEMENT, and later add the results and check if are the same?

Thanks


#3

Hi Hector,

Thanks for your reply.

  1. Are you using the same Date window? - Yes, it’s the same. Anyway, we have a 1000$ limit - not possible to reach 5439.488$ amount.

  2. We did this and received numbers which are also incorrect. Please check below

{
  "data_type": "stats",
  "time_series_length": 1,
  "data": [
    {
      "id": "83tad",
      "id_data": [
        {
          "segment": null,
          "metrics": {
            "impressions": [
              847989
            ],
            "tweets_send": null,
            "billed_charge_local_micro": [
              709606837
            ],
            "qualified_impressions": null,
            "follows": null,
            "app_clicks": [
              6156
            ],
            "retweets": null,
            "likes": null,
            "engagements": [
              6156
            ],
            "clicks": [
              6156
            ],
            "card_engagements": null,
            "replies": null,
            "url_clicks": [
              6156
            ],
            "billed_engagements": null,
            "carousel_swipes": null
          }
        }
      ]
    }
  ],
  "request": {
    "params": {
      "start_time": "2017-05-31T21:00:00Z",
      "segmentation_type": null,
      "entity_ids": [
        "83tad"
      ],
      "end_time": "2017-06-01T21:00:00Z",
      "country": null,
      "placement": "PUBLISHER_NETWORK",
      "granularity": "DAY",
      "entity": "CAMPAIGN",
      "platform": null,
      "metric_groups": [
        "ENGAGEMENT",
        "BILLING"
      ]
    }
  }
}

#4

Sorry,

In your first post you have shared the info about

the day 31-05-2017 but now you have shared it about the 01-06-2017.

Could you please do the last one again analyzing 31-05-2017?

Thanks!


#5

Hi @HttpoolRu_Ads,

I think the first issue is that you’re dividing bill_charged_local_micro by 1000, when in fact the _micro values need to be divided by 1,000,000 in order to get the actual representation in decimal.


#6

I think the same too, but it’s only the first problem, because if you divide by 1,000,00 you will get $5,43 , less than in the screenshot.

So it looks like they have a lot of traffic from TAP, and they are not requesting it in the API

Could it be @brooklynmike?

Thanks


#7

Hey guys,

Thanks for your support here, the issue is resolved.
It was both the dividing amount (1,000,000 is a correct number) and not including tap when requesting data.


#8