Skip to main content

We are a startup… still on free tier. Hoping to move up soon 🙂.

I’m new to Amplitude so hoping this is not a silly question:

On the https://app.amplitude.com/, I can create a new segmentation chart and just one event “EVENT-A” and apply one filter (User ID = ABD).  I then view both “event totals” and “Uniques”.  For Event totals, I get number such as 151, 43, 200 for the past 3 days.

When using HTTP V2, and querying with the same event with the same filter, I get values such as 5768.  Why are these so different?   I made sure to use the “m” : “totals”.   Below is my curl.  I’m hoping there is something obvious I missed?   

Looking at other similar posts:  I only have one project so the API key I’m using is by definition the only project I have access to. 

curl -X GET 'https://amplitude.com/api/2/events/segmentation' -H 'Content-Type: application/json' -d 'e={"event_type": "EVENT-A"}' -d 'f=on{"prop": "user_id", "op": "is", "values": ["ABCD"]}]]' -d 'start=20240126' -d 'end=20240130' -d 'm=totals' -u 'XXX:YYY'

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": e
           
                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": d
        "VVW1FKetST"
    ],
    "novaRequestStartAndEndTimes": r
       
            1706658467201,
            1706658467242
        ]
    ],
    "perQueryMetadata": b
        {
            "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": s]
}

@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": s"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":  
            r
                2,
                151,
                43,
                345,
                16
            ]
        ],
        "seriesCollapsed": r
            r
                {
                    "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": s],
    "backend": "novaV2",
    "realtimeDataMissing": false,
    "timedOutRealtimeData": false,
    "missedCacheAndNotComputed": false,
    "partialMergedAndNewUserInformation": false,
    "prunedResult": false,
    "hitChunkGroupByLimit": false,
    "subcluster": 9,
    "millisSinceComputed": 775670,
    "earliestServerReceivedTime": 9223372036854775807,
    "queryIds":  
        "ZgGPqyGexo"
    ],
    "novaRequestStartAndEndTimes": r
         
            1706815269453,
            1706815269487
        ]
    ],
    "perQueryMetadata": Q
        {
            "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": "]
}

 

I was able to get it work.

I removed ‘f’ with ‘s’.  So instead of filtering, I am segmenting.  Not intuitive at all.

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

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 glink 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

Reply


Terms & ConditionsCookie settings