v1 stats end_time cannot be in the future


#1

Hello!

One change moving from Ads API v0 to v1 that I want to highlight is that stats endpoints do no longer allow end_time to be in the future.

For example, using hourly granularity in v0 would seemingly pad any future stats with zeros - something which I’ve grown quite accustomed to and is really convenient especially since when storing stats locally we store them using hourly granularity aligned by day. However, v1 won’t let you specify an end time in the future and thus introduces an extra layer of complexity when fetching stats for today as you can no longer rely on always having midnight aligned start and end times. It also makes it troublesome to fetch stats for today using daily granularity as outlined in this other thread Problem Stats V1 Granularity DAY.

Thus I cannot stress enough how nice and convenient it is to be able to specify an end_time in the future, and I’m hoping that you will considering bringing over this v0 end_time behavior to v1.

Here’s an example of fetching stats for today using midnight aligned dates in v0 and v1.

$ date && twurl -H ads-api.twitter.com "/0/stats/accounts/4no6av/line_items?metrics=billed_charge_local_micro&start_time=2016-04-05T00:00:00-0700&end_time=2016-04-06T00:00:00-0700&line_item_ids=4s8by&granularity=HOUR"|jsonpretty
Tue Apr  5 12:14:12 CDT 2016
{
  "data_type": "stats",
  "data": [
    {
      "start_time": "2016-04-05T07:00:00Z",
      "billed_charge_local_micro": [
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        10000,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0
      ],
      "end_time": "2016-04-06T07:00:00Z",
      "id": "4s8by",
      "granularity": "HOUR"
    }
  ],
  "request": {
    "params": {
      "start_time": "2016-04-05T07:00:00Z",
      "end_time": "2016-04-06T07:00:00Z",
      "line_item_ids": [
        "4s8by"
      ],
      "account_id": "4no6av",
      "granularity": "HOUR",
      "metrics": [
        "billed_charge_local_micro"
      ]
    }
  }
}
$ date && twurl -H ads-api.twitter.com "/1/stats/accounts/4no6av?entity=LINE_ITEM&metric_groups=BILLING&placement=ALL_ON_TWITTER&start_time=2016-04-05T00:00:00-07:00&end_time=2016-04-06T00:00:00-07:00&entity_ids=4s8by&granularity=HOUR"|jsonpretty
Tue Apr  5 12:13:30 CDT 2016
{
  "errors": [
    {
      "code": "INVALID_PARAMETER",
      "message": "Expected time before 2016-04-05T17:13:31Z, got \"2016-04-06 07:00:00 +0000\" for end_time",
      "parameter": "end_time"
    }
  ],
  "request": {
    "params": {
      "start_time": "2016-04-05T07:00:00Z",
      "entity_ids": [
        "4s8by"
      ],
      "end_time": "2016-04-06T07:00:00Z",
      "placement": "ALL_ON_TWITTER",
      "account_id": "4no6av",
      "granularity": "HOUR",
      "entity": "LINE_ITEM",
      "metric_groups": [
        "BILLING"
      ]
    }
  }
}

#2

I want this too!!!


#3

@lindgren @hector_borras This is related: Ads API analytics V 1.0


#4

Just adding an update here, we have discussed this internally and are trying to negotiate some changes…please keep a look out for further updates!


#5

Sounds good! Thanks for the update @JBabichJapan


#6

We believe the issue with not being able to specify end dates in the future has been fixed, please give this a try and let us know if it addresses the concerns here:

twurl -H ads-api.twitter.com “/1/stats/accounts/4no6av/?metric_groups=BILLING&placement=ALL_ON_TWITTER&granularity=HOUR&start_time=2016-04-11T00:00:00-0700&end_time=2016-04-12T00:00:00-0700&entity=LINE_ITEM&entity_ids=4s8by”


#7

Hi @JBabichJapan !

Thanks a lot for this fix, and thank it also to all the dev team.

Is working now perfectly!

Thanks again!


#8

Hi @JBabichJapan

Thank you so much for fixing this and for fixing it so fast. I really appreciate the quick turnaround. I’ve only had time to do some initial testing, but so far everything looks good. This really makes moving forward with the migration a lot easier.

Thank you once again!


#9

Hey @JBabichJapan

I’ve been doing some more extensive testing of the recent end_time fix and I’ve actually stumbled upon a corner case that, in my mind, is not properly handled. The corner case is when requesting stats for a midnight aligned 7 day period where the start and end date are on opposite sides of a switch from day light saving DST (summer time) to standard time (winter time).

For example, fetching stats for 2015-11-01T00:00:00-0700 to 2015-11-08T00:00:00-0800 (Pacific) will fail because I guess the validator sees the time period as 7 days + 1 hour because of the added hour when turning back clocks on 2015-11-01 at 2am. Specifying 2015-11-08T00:00:00-0700 as an end date will work fine - only problem is that it has the wrong offset…

Here are a couple of twurl requests to demonstrate the issue:

$ date && twurl -H ads-api.twitter.com "/1/stats/accounts/4no6av?placement=ALL_ON_TWITTER&metric_groups=BILLING&start_time=2015-11-01T00:00:00-0700&end_time=2015-11-08T00:00:00-0800&granularity=TOTAL&entity_ids=whe1&entity=LINE_ITEM"|jsonpretty
Thu Apr 14 23:00:21 CDT 2016
{
  "errors": [
    {
      "code": "INVALID_TIME_WINDOW",
      "message": "The end_time (2015-11-08 08:00:00 +0000) can be a maximum of 7.days after the start_time (2015-11-01 07:00:00 +0000)",
      "parameter": ""
    }
  ],
  "request": {
    "params": {
      "start_time": "2015-11-01T07:00:00Z",
      "entity_ids": [
        "whe1"
      ],
      "end_time": "2015-11-08T08:00:00Z",
      "placement": "ALL_ON_TWITTER",
      "account_id": "4no6av",
      "granularity": "TOTAL",
      "entity": "LINE_ITEM",
      "metric_groups": [
        "BILLING"
      ]
    }
  }
}
$ date && twurl -H ads-api.twitter.com "/1/stats/accounts/4no6av?placement=ALL_ON_TWITTER&metric_groups=BILLING&start_time=2015-11-01T00:00:00-0700&end_time=2015-11-08T00:00:00-0700&granularity=TOTAL&entity_ids=whe1&entity=LINE_ITEM"|jsonpretty
Thu Apr 14 23:00:26 CDT 2016
{
  "data_type": "stats",
  "time_series_length": 1,
  "data": [
    {
      "id": "whe1",
      "id_data": [
        {
          "segment": null,
          "metrics": {
            "billed_charge_local_micro": null,
            "billed_engagements": null
          }
        }
      ]
    }
  ],
  "request": {
    "params": {
      "start_time": "2015-11-01T07:00:00Z",
      "segmentation_type": null,
      "entity_ids": [
        "whe1"
      ],
      "end_time": "2015-11-08T07:00:00Z",
      "country": null,
      "placement": "ALL_ON_TWITTER",
      "granularity": "TOTAL",
      "entity": "LINE_ITEM",
      "platform": null,
      "metric_groups": [
        "BILLING"
      ]
    }
  }
}

Fetching stats for a 7 day midnight aligned period during a winter time to summer time switch do not cause any issues since it will actually return stats for 6 days and 23 hours since clocks are moved forward one hour (2016-03-13T00:00:00-0800 - 2016-03-20T00:00:00-0700).

So it is only the corner case when switching from summer time to winter time that is not properly handled and needs some attention and to be resolved.


Summer Time VS Winter Time in the same timezone