Hi there,
We collecting Klaviyo events performance and we going to migrate to the new date-versioned API.
To be sure that we’ll not face the data discrepancy after migration, I’ve compared data from endpoints in both API versions: v1 and 2023-02-22.
- In the v1 API we used endpoint metric/{metric_id}/export , filtering data with $attributed_message value (aka campaign ID).
E.g., I’ve sent the following request for metric NjaHUp "Placed Order" and $attributed_message 01GW284VK0V70JNJY8ZC5WMEPN:
curl -L -g -X GET 'https://a.klaviyo.com/api/v1/metric/NjaHUp/export?start_date=2023-03-21&end_date=2023-03-25&where=[["$attributed_message","=","01GW284VK0V70JNJY8ZC5WMEPN"]]&api_key={api_key}'
and got these data:
{"date": "2023-03-21 00:00:00",
"values": [2.0]},
{"date": "2023-03-22 00:00:00",
"values": [4.0]},
{"date": "2023-03-23 00:00:00",
"values": [5.0]},
{"date": "2023-03-24 00:00:00",
"values": [2.0]},
{"date": "2023-03-25 00:00:00",
"values": [3.0]}
- In the date-versioned API I’ve found the endpoint metric-aggregates/. It allows to define breakdowns in the “by” parameter, and it’s a cool feature in fact!
However, sending request for the same metric:
curl -L -X POST 'https://a.klaviyo.com/api/metric-aggregates/' \
-H 'Authorization: Klaviyo-API-Key {api_key}' \
-H 'revision: 2023-02-22' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
--data-raw '{
"data": {
"type": "metric-aggregate",
"attributes": {
"metric_id": "NjaHUp",
"interval": "day",
"measurements": [
"count",
"unique",
"sum_value"
],
"filter": [
"greater-or-equal(datetime,2023-03-21T00:00:00)",
"less-than(datetime,2023-03-26T00:00:00)"
],
"by": [
"$attributed_message"
],
"page_size": 500,
"timezone": "UTC"
}
}
}'
I’ve got slightly others values for "dimensions": ["01GW284VK0V70JNJY8ZC5WMEPN"]:
"measurements": {
"count": [
1.0,
5.0,
3.0,
4.0,
3.0
],
I’ve compared these values day-by-day and found that total metrics count for requested period is the same but for single date most values differs:
| date | v1 | 2023-02-22 |
| 2023-03-21 | 2 | 1 |
| 2023-03-22 | 4 | 5 |
| 2023-03-23 | 5 | 3 |
| 2023-03-24 | 2 | 4 |
| 2023-03-25 | 3 | 3 |
| total | 16 | 16 |
AFAIK, v1 API uses UTC both in request parameters and response data.
And for revision 2023-02-22 I used "timezone": "UTC" too (however, the response datetimes returned will be in UTC as described in API doc).
Could you please clarify what’s a reason for this discrepancy? And how I can fix it and got the same data as for v1 API?
Regards and thanks,
Evgeniy
