No change to analytics when specifying segmentation_type

[RileyJohnGibbs]

I’m making asynchronous calls to get stats for a campaign, with segmentation_type specified. Specifically I’m trying to break out the reporting by CONVERSION_TAGS, but there’s no difference in the stats I get back when I fetch them, no matter what segmentation_type I specify.

I can confirm that the segmentation_type field is being recognized by the Twitter API, because I get an error (barely intelligible) about metric_groups when I specify CONVERSION_TAGS as my segmentation_type unless, it seems, I only pass in WEB_CONVERSION as the metric_groups value.

[JBabichJapan]

Hi,

Could you please confirm the objective of the campaign you are trying to fetch stats for? The most likely cause is that it’s not an objective that is setup to track conversions (website clicks or conversions). You should always be able to see same metrics in Ads UI and Ads API and when you cannot find the same numbers, please double check that the stats are showing as different between UI and API for the same entities and let us know the specifics to make it easier to repro the issue (including Ads UI links and twurl repro is very appreciated).

Thanks,

John

[RileyJohnGibbs]

Thanks. I checked the objective for the campaign I’m testing on and it does appear to be website clicks. The Twitter campaign ID (as shows up in the post data below) is 758ab.

Our API call uses the URL:
https://ads-api.twitter.com/1/stats/jobs/accounts/18ce54ba1mx
with post data:
placement=ALL_ON_TWITTER&metric_groups=WEB_CONVERSION&start_time=2017-01-09T08:00:00Z&entity=CAMPAIGN&end_time=2017-01-11T08:00:00Z&granularity=TOTAL&entity_ids=758ab&segmentation_type=CONVERSION_TAGS

The reporting in the UI with stats by conversion tag is found here:
https://ads.twitter.com/accounts/18ce54ba1mx/campaigns_dashboard?endString=2017-01-31T00%3A00%3A00.000&fi=39305899&metric_set=conversions&startString=2017-01-09T00%3A00%3A00.000&summary_metric=impressions&log_ec=false&show_bulk_export_button=true&cursor=

[juanshishido]

@RileyJohnGibbs: Could you clarify what the issue is? Is the request to the POST /1/stats/jobs/accounts/:account_id endpoint not working when you specify segmentation_type? Or are you not seeing the data you expect to see?

Here are the results* of the async request you specified:

twurl -X POST -H ads-api.twitter.com "/1/stats/jobs/accounts/18ce54ba1mx?placement=ALL_ON_TWITTER&metric_groups=WEB_CONVERSION&start_time=2017-01-09T08:00:00Z&entity=CAMPAIGN&end_time=2017-01-11T08:00:00Z&granularity=TOTAL&entity_ids=758ab&segmentation_type=CONVERSION_TAGS"
{  
  "data_type":"stats",
  "time_series_length":1,
  "data":[  
    {  
      "id":"758ab",
      "id_data":[  
        {  
          "segment":{  
            "segment_name":{segment_name},
            "segment_value":"nvm0j"
          },
          "metrics":{  
            "conversion_purchases":{  
              "order_quantity_engagement":null,
              "sale_amount_engagement":null,
              "sale_amount_view":[  
                148500000
              ],
              "post_view":[  
                2
              ],
              "order_quantity":[  
                3000000
              ],
              "assisted":null,
              "post_engagement":null,
              "sale_amount":[  
                148500000
              ],
              "metric":[  
                2
              ],
              "order_quantity_view":[  
                3000000
              ]
            },
            "conversion_sign_ups":{  
              "order_quantity_engagement":null,
              "sale_amount_engagement":null,
              "sale_amount_view":null,
              "post_view":null,
              "order_quantity":null,
              "assisted":null,
              "post_engagement":null,
              "sale_amount":null,
              "metric":null,
              "order_quantity_view":null
            },
            "conversion_site_visits":{  
              "order_quantity_engagement":null,
              "sale_amount_engagement":null,
              "sale_amount_view":null,
              "post_view":null,
              "order_quantity":null,
              "post_engagement":null,
              "sale_amount":null,
              "metric":null,
              "order_quantity_view":null
            },
            "conversion_custom":{  
              "order_quantity_engagement":null,
              "sale_amount_engagement":null,
              "sale_amount_view":null,
              "post_view":null,
              "order_quantity":null,
              "post_engagement":null,
              "sale_amount":null,
              "metric":null,
              "order_quantity_view":null
            },
            "conversion_downloads":{  
              "order_quantity_engagement":null,
              "sale_amount_engagement":null,
              "sale_amount_view":null,
              "post_view":null,
              "order_quantity":null,
              "post_engagement":null,
              "sale_amount":null,
              "metric":null,
              "order_quantity_view":null
            }
          }
        }
      ]
    }
  ],
  "request":{  
    "params":{  
      "start_time":"2017-01-09T08:00:00Z",
      "segmentation_type":"CONVERSION_TAGS",
      "entity_ids":[  
        "758ab"
      ],
      "end_time":"2017-01-11T08:00:00Z",
      "country":null,
      "placement":"ALL_ON_TWITTER",
      "granularity":"TOTAL",
      "entity":"CAMPAIGN",
      "platform":null,
      "metric_groups":[  
        "WEB_CONVERSION"
      ]
    }
  }
}

* Of course these results are retrieved after making a request to the GET /1/stats/jobs/accounts/:account_id endpoint, downloading the .gz file from the url (after seeing "status": "SUCCESS"), and gunzip-ing the file.

[RileyJohnGibbs]

@juanshishido: Ah, I found the problem. It looks like our code was burrowing down into the response and only spitting back out the “metrics” value of the first item in the “id_data” list. It was very helpful to see the entire structure of the expected response, so thank you very much for posting that!

[juanshishido]

@RileyJohnGibbs: Fantastic! Thanks for following up and letting us know. Glad to hear it’s working now.