Feature request: multi-dimensional event data queries #4066
Description
Describe the feature or enhancement
Problem
The event-data/values endpoint returns aggregated counts for a single property at a time. Any analysis that combines two dimensions — whether that's two properties, or one property over time — requires either making O(n) API calls with narrow time windows, or fetching individual events and their properties one by one (N+1 pattern). Both approaches are slow, fragile, and put unnecessary load on the API.
This makes it difficult to answer common analytics questions like "how does usage by user segment change week over week" or "which event property values correlate with each other" without significant client-side workarounds.
Potential solutions
Three options, from most targeted to most flexible. They're complementary, each covers different use cases well.
1. Make unit functional on event-data/values
The endpoint already accepts unit and timezone parameters, but the response is always a flat aggregation over the full time range. If unit actually bucketed the results by time period, the most common case (property values over time) would be solved with zero API changes on the client side.
GET /event-data/values?event=my-event&propertyName=user-role&unit=day&...
[
{ "date": "2026-01-05", "value": "admin", "total": 3 },
{ "date": "2026-01-05", "value": "viewer", "total": 7 },
{ "date": "2026-01-06", "value": "admin", "total": 5 }
]2. Support multiple propertyName parameters
This would cover property × property cross-tabulation (e.g. user role × feature used), which currently requires an external join or N+1 fetches.
GET /event-data/values?event=my-event&propertyName=role&propertyName=plan&...
[
{ "values": { "role": "admin", "plan": "pro" }, "total": 12 },
{ "values": { "role": "viewer", "plan": "free" }, "total": 34 }
]3. Flat event data export
A single endpoint that returns individual events with all properties as columns, eliminating the N+1 pattern entirely. This covers any analysis the above two don't, at the cost of pushing aggregation to the client.
GET /event-data/export?event=my-event&startAt=...&endAt=...
[
{ "createdAt": "2026-01-05T10:23:00Z", "role": "admin", "plan": "pro", "query": "test" },
{ "createdAt": "2026-01-05T11:05:00Z", "role": "viewer", "plan": "free", "query": "demo" }
]This would need pagination and possibly a row limit, but it would replace the current pattern of fetching /events and then calling /event-data/:eventId for each result.
Impact
These changes would make Umami's event data API practical for segmented analytics without requiring external tooling or excessive API calls. Option 1 is probably the lowest-effort change since the parameters are already accepted and time-bucketing logic exists in other endpoints.