## Why Five DAP Impact v1 Adoption tab panels classify users by activity before counting (https://gitlab.com/groups/gitlab-org/-/work_items/23420#note_3834970807): sessions by tier and capability, share of users per tier, share of sessions per tier, multi-activity users, abandonment. The DuoWorkflows aggregation engine gained a `user_tier` dimension and `flow_types_used` / `active_days` range filters in https://gitlab.com/gitlab-org/gitlab/-/work_items/627697 (shipped in 19.4, final MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254974). This issue wires them up in `src/analyzer/sources/duo_workflows.rs`. ## Engine contract (on `origin/master`) **`userTier` dimension** (`duo_workflows.rb:32-34`, `lib/gitlab/database/aggregation/click_house/tier_dimension.rb`): - GraphQL `userTier(thresholds: [Int!]): String`. The argument is nullable in the schema but **required** by the engine (validated at request time), so GLQL enforces it at compile time - `thresholds`: at most 9 values (`MAX_THRESHOLDS = 9`), strictly ascending, each `>= 1` - Returns labels `tier_0` .. `tier_N` (N thresholds -> N+1 tiers); lexicographic order equals numeric order, so sorting by the dimension works - The tier is computed over the **whole selected period** - the `user_activity` CTE inherits the `created_at` range (`duo_workflows.rb:11-19`) - so `created(weekly), userTier(...)` does not give a per-week tier. Per-week normalisation is a client concern: the dashboard pre-scales the thresholds by the number of weeks in the period (e.g. `[4, 25, 100]` per week) and passes the scaled values **Range filters** (`duo_workflows.rb:79-82`), mounted on the `duoWorkflows(...)` engine field (not on `aggregated`), inclusive `BETWEEN`: - `flowTypesUsedFrom` / `flowTypesUsedTo: Int` - distinct flow types the user ran in the period; multi-activity users = `flowTypesUsed >= 2` - `activeDaysFrom` / `activeDaysTo: Int` - distinct days the user created flows; abandonment = `activeDays = 1` ## What **Filters** (no compiler dependency, can land first): - `flowTypesUsed` and `activeDays` as integer range filters. Same shape as `featuresCount` in `src/analyzer/sources/ai_usage_events.rs` (`NumberLike` with range operators, strict `>` / `<` shifted by one, `FilterKey::DateRange { from: "From", to: "To" }`), with one difference: these two also accept `=` and render it as `From = To`, since the abandonment panel needs `activeDays = 1`. Unlike `featuresCount` they mount on the engine field, so they are not listed in `aggregated_filter_keys()` **Dimension** (blocked by #213): - `userTier` as a dimension and sort field with a required `thresholds` list parameter: `userTier(thresholds=[8, 50, 200])`. Named parameters in GLQL use `=`; list-valued parameters in field functions are #213. GLQL validates required / max 9 / strictly ascending positive integers at compile time, since the engine only rejects at request time - Sort emission carries the parameter (`parameters: { thresholds: [...] }`) ## How - `UserTier`, `FlowTypesUsed`, `ActiveDays` variants in `src/types/field.rs` - `duo_workflows.rs`: filters in `valid_filter_fields()` + `field_type()` + `graphql_filter_key` / `graphql_filter_value`; `userTier` in `valid_dimensions()` / `valid_sort_fields()` with a list `FieldParameterDef` once #213 provides the kind - Regenerate `src/schema/schema.json`; tests in `tests/duo_workflows_tests.rs`; docs table for the source in gitlab-org/gitlab after release + bump ## Example ```yaml mode: analytics query: type = DuoWorkflow and group = "my-group" and created > -28d and flowType in ("developer/v1", "code_review/v1", "fix_pipeline/v1") dimensions: userTier(thresholds=[16, 100, 400]), flowType metrics: totalCount sort: userTier asc, flowType asc ``` ```yaml mode: analytics query: type = DuoWorkflow and group = "my-group" and created > -28d and activeDays = 1 metrics: usersCount ``` ## References - Adoption tab query list and GLQL scan: https://gitlab.com/groups/gitlab-org/-/work_items/23420#note_3834970807 - Engine: https://gitlab.com/gitlab-org/gitlab/-/work_items/627697 - Blocked by #213 (dimension half only) - Tracking: https://gitlab.com/gitlab-org/glql/-/work_items/188 - Sibling DAP Impact GLQL issues: #206, #207, #211, #213, #214