--- title: "Explain Cohort" method: POST path: "/analytics/sales-report/cohort/explain" tags: ["Analytics"] --- # Explain Cohort `POST /analytics/sales-report/cohort/explain` ## Request - Base URL: `https://be.graph8.com/api/v1` - URL: `https://be.graph8.com/api/v1/analytics/sales-report/cohort/explain` - Auth: HTTP bearer Which clause emptied the view. Takes the SAME body as `/cohort` and answers one `{label, lead_count, deal_count, measured}` row per progressively-built prefix of the filter - baseline, then +rep, then +lifecycle, and so on. Read the drop (`290 -> 57 -> 11 -> 0`) and the last step that moved is the clause that did it. COUNTS ONLY, never rows - which is both what makes it affordable (about 26 count queries against `/cohort`'s full section fan-out) and why it is safe to call when `/cohort` itself would withhold person rows. ## Query parameters - `tz` string: IANA timezone the local-day window bounds are computed in, e.g. `Asia/Tokyo`. Changes which deals fall inside the date range. ## Headers - `Authorization` string, nullable - `X-Target-Org-Id` string, nullable ## Request body - FilterQueryDto: JSON shape consumed by POST /api/sales-report/cohort. Empty groups are omitted by callers; absent groups treated as empty. - `date` DateRangeDto, required - `from` string, date, required - `to` string, date, required - `rep` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `pipeline` UuidFilterGroupDto: `pipeline` / `stage` — `CBDeal.pipeline_id` and `.stage_id` are real `PostgresUUID` columns, so a non-UUID can only ever fail open. - `in` string[] - `not` boolean - `stage` UuidFilterGroupDto: `pipeline` / `stage` — `CBDeal.pipeline_id` and `.stage_id` are real `PostgresUUID` columns, so a non-UUID can only ever fail open. - `in` string[] - `not` boolean - `lifecycle` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `audiences` IntIdFilterGroupDto: `rec_type` / `audiences` — `Lead.rec_type` is `SmallInteger` and `audience_id` is `Integer`; both appliers coerce and skip what will not parse. - `in` string[] - `not` boolean - `rec_type` IntIdFilterGroupDto: `rec_type` / `audiences` — `Lead.rec_type` is `SmallInteger` and `audience_id` is `Integer`; both appliers coerce and skip what will not parse. - `in` string[] - `not` boolean - `signals_email` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_voice` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_linkedin` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_sms` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_forms` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_website` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_calendar` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_chat` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_intent` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_crm` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_sequence` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `signals_enrichment` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `channel` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `campaign` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `country` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `industry` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `headcount` HeadcountFilterGroupDto: `headcount` — a CLOSED vocabulary (`HEADCOUNT_BANDS`), and the exact list `/filter-options` hands the client. - `in` string[] - `not` boolean - `grading_bucket` GradingBucketFilterGroupDto: `grading_bucket` — a CLOSED vocabulary (`GRADING_BUCKETS`). An unknown bucket produces no band clause and widens to the full book. - `in` string[] - `not` boolean - `objections` ObjectionCodeFilterGroupDto: `objections` — codes live in the PER-ORG `cb_objection_codes` catalog, so only the SHAPE can be checked here. Blank is the one thing the applier provably cannot use. - `in` string[] - `not` boolean - `tier` FilterGroupDto: One filter group — list of values + optional NOT toggle. ``in_`` is capped at ``MAX_FILTER_VALUES_PER_GROUP`` items of ``MAX_FILTER_VALUE_LENGTH`` characters each. Over-cap input raises during body parsing, so FastAPI answers 422 with the offending group named in ``detail[].loc`` (``["body", "", "in"]``) and the cap in ``detail[].msg`` — no handler code, and therefore no SQL, runs. THIS SHAPE DOES NOT NEST. ``in_`` holds scalars and there is no group-of-groups member, so a caller cannot vary the tree depth: it is fixed at 2 (query -> group -> values) by construction, and ``extra="forbid"`` on both models keeps it that way. A depth check here would be validation that can never fire. Add one WITH the member that introduces nesting, not before it. Do not confuse this with ``SegmentFilterGroup`` (``contacts/domain/value_objects/ag_grid_models.py:111``), which IS recursive and is where AC-3's "tree depth" belongs. Different model, different route, still unbounded — see the scope note above the constants. - `in` string[] - `not` boolean - `pipeline_target` 'prospects_meeting' | 'prospects_revenue' | 'customers_revenue', nullable - `granularity` 'day' | 'week' | 'month', nullable ## Response `200` Successful Response - ApiResponseReportPayload - `data` ReportPayload, required: An OPEN envelope around one report's answer. The app wraps every one of these reports in `{success, data, meta}`, where `meta` carries the cache state, the window and - on the agency reports - `failed_org_ids`, the orgs that contributed NOTHING to the totals above. That field is the difference between "this client sent no email" and "we could not query this client", so it is forwarded rather than flattened away. Open on purpose: `data` is `dict | list` in the app and its contents grow with the product. A closed model would turn every new metric into a silently dropped one. - `pagination` PaginationMeta - `page` integer, required: Current page number (1-indexed) - `limit` integer, required: Items per page - `total` integer, required: Total number of items - `has_next` boolean, required: Whether there are more pages - `next_cursor` string, nullable: Opaque cursor for the next page; null when there are no more items. Pass it back as the `cursor` query param to fetch the following page without computing page numbers. - `total_available` integer, nullable: Search endpoints only: how many records really match, when known. Can be larger than `total`, which is capped at the 10,000 results that can be paged. For company search this is a distinct-company estimate. Null when unknown; absent outside search. - `total_is_lower_bound` boolean, nullable: Search endpoints only: true when more records match than `total` shows (the result set is larger than the 10,000 results that can be paged). Absent outside search. - `notes` string[], nullable: Search endpoints only: plain-language notes about the result, e.g. that more records match than can be paged, or that a reversed `between` range was put in order. ## Other responses - `422`: Validation Error --- [API](https://skmtc.dev/graph8/apis/graph8-developer-api.md) · [All operations](https://skmtc.dev/graph8/apis/graph8-developer-api/llms.txt) · [OpenAPI document](https://skmtc.dev/graph8/apis/graph8-developer-api/revisions/2e7cfa0ca921?raw)