You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expose PerSubscriberAggregate through the API, and add a corresponding flowclient query spec. This query should be exposed as a subscriber metric that can be used in 'joined_spatial_aggregate' and 'histogram_aggregation'.
The 'subscriber_query' parameter should accept any subscriber metric query, or a union of subscriber metric queries. Given that Union is not exposed through the API, and a general Union would not be suitable here (only a Union of the accepted subscriber metric queries), I'd suggest we could allow a list of subscriber metric queries as input for this parameter (similar to modal_location taking a list of daily locations), and construct the union internally.
I'd also suggest that we don't expose the 'agg_column' parameter, and instead hard-code it to 'value'.
The text was updated successfully, but these errors were encountered:
Expose
PerSubscriberAggregate
through the API, and add a corresponding flowclient query spec. This query should be exposed as a subscriber metric that can be used in 'joined_spatial_aggregate' and 'histogram_aggregation'.The 'subscriber_query' parameter should accept any subscriber metric query, or a union of subscriber metric queries. Given that
Union
is not exposed through the API, and a general Union would not be suitable here (only a Union of the accepted subscriber metric queries), I'd suggest we could allow a list of subscriber metric queries as input for this parameter (similar to modal_location taking a list of daily locations), and construct the union internally.I'd also suggest that we don't expose the 'agg_column' parameter, and instead hard-code it to 'value'.
The text was updated successfully, but these errors were encountered: