Why is data on website different from HTTP V2 API result?

Hi @Ed Landau 

Looks like you are referring to the results from Dashboard REST API.

Can you post screenshots of your chart definitions and chart results + the API response JSON?

cURL: cURL command: curl -X GET 'https://amplitude.com/api/2/events/segmentation' -H 'Content-Type: application/json' -d 'e={"event_type": "BLE-SYNC"}' -d 'f=[[{"prop": "user_id", "op": "is", "values": ["86b2d89e-c038-40ec-a2b6-08af950af146"]}]]' -d 'start=20240126' -d 'end=20240130' -d 'm=totals' -u 'XXX:YYY'

And the Dashboard screenshot:

API JSON output:

JSON Response:
 {
    "data": {
        "series": [
            [
                5768,
                5468,
                5310,
                8506,
                10589
            ]
        ],
        "seriesCollapsed": [
            [
                {
                    "setId": "",
                    "value": 35641
                }
            ]
        ],
        "seriesLabels": [
            0
        ],
        "xValues": [
            "2024-01-26",
            "2024-01-27",
            "2024-01-28",
            "2024-01-29",
            "2024-01-30"
        ]
    },
    "timeComputed": 1706658067036,
    "wasCached": true,
    "cacheFreshness": "FRESH",
    "novaRuntime": 15,
    "novaRequestDuration": 41,
    "novaCost": 0,
    "throttleTime": 0,
    "minSampleRate": 1.0,
    "transformationIds": [],
    "backend": "novaV2",
    "realtimeDataMissing": false,
    "timedOutRealtimeData": false,
    "missedCacheAndNotComputed": false,
    "partialMergedAndNewUserInformation": false,
    "prunedResult": false,
    "hitChunkGroupByLimit": false,
    "subcluster": 9,
    "millisSinceComputed": 400310,
    "earliestServerReceivedTime": 9223372036854775807,
    "queryIds": [
        "VVW1FKetST"
    ],
    "novaRequestStartAndEndTimes": [
        [
            1706658467201,
            1706658467242
        ]
    ],
    "perQueryMetadata": [
        {
            "queryId": "VVW1FKetST",
            "queryType": "MULTI_SEGMENTATION",
            "cached": true,
            "cacheFreshness": "FRESH",
            "throttleTime": 0,
            "novaCost": 0,
            "minSampleRate": 1,
            "realtimeDataMissing": false,
            "externalDataMissing": false,
            "timedOutRealtime": false,
            "missedCacheAndNotComputed": false,
            "prunedResult": false,
            "hitChunkGroupByLimit": false
        }
    ],
    "prunedAmpIds": []
}

@Saish Redkar New here… sorry it took me a while to respond :). I hope this helps?

👀 👀

It seems my filter is not working.  If I remove the user_id filter from the website, I get similar results.

So:  'f=[[{"prop": "user_id", "op": "is", "values": ["86b2d89e-c038-40ec-a2b6-08af950af146"]}]]' seems to be malformed?

Hi @Ed Landau thank you for reaching out! I took a look at your project in case there were other event_types under a similar naming convention, but everything looked correct, and to your point your org only has 1 project, so the API key is correct. 

I reran the GET command in postman and outputted the following response. I also invited your info@movano.com email to the workspace if you’d like to inspect further. Here’s the postman link. 

As you can see, the total event counts for that 1 user sum up to 557 events, which aligns to the total event count between 1/26 - 1/30 in the amplitude chart.

I’m not clear yet what’s causing your cURL command to yield such drastic count differences, but I was having issues running the cURL on my end, so I defaulted to Postman for now. I hope this helps!

Postman screenshot:

Response output below:

{
    "data": {
        "series": [
            [
                2,
                151,
                43,
                345,
                16
            ]
        ],
        "seriesCollapsed": [
            [
                {
                    "setId": "",
                    "value": 557
                }
            ]
        ],
        "seriesLabels": [
            0
        ],
        "xValues": [
            "2024-01-26",
            "2024-01-27",
            "2024-01-28",
            "2024-01-29",
            "2024-01-30"
        ]
    },
    "timeComputed": 1706814493818,
    "wasCached": true,
    "cacheFreshness": "FRESH",
    "novaRuntime": 10,
    "novaRequestDuration": 34,
    "novaCost": 0,
    "throttleTime": 0,
    "minSampleRate": 1.0,
    "transformationIds": [],
    "backend": "novaV2",
    "realtimeDataMissing": false,
    "timedOutRealtimeData": false,
    "missedCacheAndNotComputed": false,
    "partialMergedAndNewUserInformation": false,
    "prunedResult": false,
    "hitChunkGroupByLimit": false,
    "subcluster": 9,
    "millisSinceComputed": 775670,
    "earliestServerReceivedTime": 9223372036854775807,
    "queryIds": [
        "ZgGPqyGexo"
    ],
    "novaRequestStartAndEndTimes": [
        [
            1706815269453,
            1706815269487
        ]
    ],
    "perQueryMetadata": [
        {
            "queryId": "ZgGPqyGexo",
            "queryType": "MULTI_SEGMENTATION",
            "cached": true,
            "cacheFreshness": "FRESH",
            "throttleTime": 0,
            "novaCost": 0,
            "minSampleRate": 1,
            "realtimeDataMissing": false,
            "externalDataMissing": false,
            "timedOutRealtime": false,
            "missedCacheAndNotComputed": false,
            "prunedResult": false,
            "hitChunkGroupByLimit": false
        }
    ],
    "prunedAmpIds": []
}

Ah great catch, yes I see now I used s on the user ID filter in postman, vs your original cURL used f for the user ID filter. I’ll share your feedback with the team. 

For additional folks following this thread, these are some of the query parameters in the dashboard rest api dev docs.  

@Ed Landau Nice catch!
Thanks for jumping in @JennRu!

Thank you both!

Now I just have to live with the “12 requests per hour max” 😀

I’d still like to understand why the website shows it as “filtering” with no segmentation but the API requires a segmentation without filtering.   They should reflect one-another. no?

Hi @Ed Landau I believe “s” for segmentation should only ever apply for user properties (and possibly group properties too, as both these property types can be filtered on in the segmentation modal within a chart). 

Whereas event property filters must always be applied to an event performed, and therefore need to specify the property type = event [link to event format].

I recognize there are no clear example cURL requests that query an event where a specific event property value is set in the Dashboard Rest API docs, so I shared this feedback with the dev docs team at Amplitude and they’re looking into some additional examples to document. 

But I did not see an “f” query parameter explicitly documented in the doc so I believe any event property filter would be applied inside the “e” param value. Which could be an event property where type = event or also a user property where type = user (as opposed to just setting the user prop in “s” segmentation