We attached a NULL_COUNT DMF to customers.email and watched the dashboard for a fortnight. It read 11 % null — 44 nulls across 400 rows on the test bed, scheduled nightly. Then we added WITHIN GROUP (signup_region). The next run wrote four rows to DATA_QUALITY_MONITORING_RESULTS instead of one. DE was 40 %. The dashboard tile had been correct for weeks. The unit was wrong.

The reason the table-level reading was not pageable is structural. A column-level null count on a table that mixes four regions answers exactly one question: how many nulls are in this column across the whole table? A single segment can run at 100 % failure without the table-level number doing anything dramatic. Forty rows from one country dilute into four hundred across four — the average comes back at 11 %, the on-call rule reads 11 %, nobody wakes up. The page-worthy unit is the worst segment, and a flat NULL_COUNT cannot emit it.

The table average is the wrong unit. The page-worthy unit is the worst segment. An ungrouped DMF cannot emit it; a grouped DMF will not let you miss it.

Back to the 11 % tile from §1. The DDL change that flipped it to a regional breakdown is one clause on the same ALTER TABLE … ADD DATA METRIC FUNCTION statement that attached the ungrouped DMF in the first place. Snowflake takes the existing DMF body, applies an implicit GROUP BY over the column(s) you name, and stores one row per group per scheduled measurement in SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_RESULTS. The DDL we ran on the test bed was this:

ALTER TABLE <your_table>
  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT
    ON (email)
    WITHIN GROUP (signup_region)
    GROUP LIMIT 1000;

On the test bed this returned Statement executed successfully and the next scheduled measurement wrote four rows to DATA_QUALITY_MONITORING_RESULTS instead of one — one per region, with the segment key in the new GROUP_BY_INFO column §3 unpacks.

Three things to notice. One. The grouping columns are part of the DMF’s attached identity. Snowflake will not let you change them in place — you drop the DMF and re-add it with the new WITHIN GROUP list. The constraint is deliberate: a grouped DMF’s history is only coherent if the grouping does not silently shift under it.

Two. GROUP LIMIT is a hard cap, default 1,000, minimum 1, maximum 1,000 — and the failure mode is loud, not silent. If the column you grouped by has more distinct values than the limit at evaluation time, Snowflake does not write a partial result; the entire evaluation fails with an error, no row is written for that run. On a customer_id column with 50,000 distinct values, attaching a grouped DMF with the default cap produces this:

SQL execution error: The number of groups exceeds the
configured GROUP LIMIT of 1000 for this association.
No measurement row was written for this run.

That is the Unknown function of grouped DMFs: the error the team learns the day they group on the wrong column. It is also the reason this is a wall-reminder, not a footnote — you only group on columns whose cardinality you can state out loud. For signup_region on the test bed, that number is four. For customer_id, it is in the tens of thousands and the answer is “don’t.”

Three. Setting WITHIN GROUP on a DMF automatically disables Snowflake’s anomaly-detection scoring for that metric. The per-segment series has its own seasonality and noise floor; running the platform’s built-in anomaly model on a noisy per-group time series would generate more false pages than the grouped DMF was attached to prevent.

The grouping is part of the DMF’s identity. Change the keys, drop and re-add — you do not edit a grouped DMF in place. The history would otherwise be a lie. — Field report, §2

The DE row from §1 has a shape. It lives in SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_RESULTS with one new column that did not exist on the ungrouped runs: GROUP_BY_INFO. It is an ARRAY of OBJECT entries — one per grouping column, in declaration order. For an ungrouped DMF the column is an empty array, so a single ARRAY_SIZE(group_by_info) > 0 predicate is enough to split grouped from ungrouped history on the same metric.

[
  { "id": "1", "name": "SIGNUP_REGION", "value": "DE" }
]

That is the DE row, in its committed form — the segment key Snowflake records alongside the VALUE column carrying the per-region null count. The read query is a plain projection. VALUE on a grouped row is the metric for that group only; the table-level roll-up sits on the same metric’s ungrouped rows (the ones with ARRAY_SIZE(group_by_info) = 0), so a single WHERE separates the two.

SELECT
  measurement_time,
  group_by_info[0]:value::STRING AS signup_region,
  value::NUMBER                  AS null_count
FROM   SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_RESULTS
WHERE  table_name = '<your_table>'
  AND  ARRAY_SIZE(group_by_info) > 0
ORDER BY measurement_time DESC;

Four rows came back, ordered by measurement_time desc, one per region. DE first on rate, the other three close enough to the floor that nothing past the first row mattered for the next page-or-don’t-page decision:

For a multi-key grouping (say, WITHIN GROUP (signup_region, plan_tier)), the array carries one entry per key in the order they were declared. Reach into them by index: group_by_info[0]:value for the region, group_by_info[1]:value for the tier. The order is the order on the ALTER TABLE; renaming a column does not reshuffle it.

The DE row is one query away from a page. The alerting SQL collapses to one filter on VALUE: a threshold of 10 nulls per region per night fires exactly one row on the test bed — DE — and leaves the other three regions silent. That is the behaviour the table-level metric cannot produce no matter how the threshold is tuned: the average will either be too low to page or too high to be useful.

SELECT
  group_by_info[0]:value::STRING AS signup_region,
  value::NUMBER                  AS null_count
FROM   SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_RESULTS
WHERE  table_name = '<your_table>'
  AND  ARRAY_SIZE(group_by_info) > 0
  AND  value::NUMBER > <your_threshold>
ORDER BY measurement_time DESC;

On the test bed with a threshold of 10: one row returned — signup_region = DE, null_count = 40. Wired to a Snowflake Alert (CREATE ALERT + EXECUTE TASK), this becomes the contents of the email that lands on the DE on-call, not the global data on-call. The metric stops being a number in a dashboard and starts being a routing decision.

Ungrouped, this same column was an 11 % reading nobody woke up for. Grouped, it is a single row that names the bucket, names the rate, and routes to the only person who can fix it. That is the whole feature, in one query. — Field report, §4

The DE row arrived because the test bed had four regions. On a customer_id column with 50,000 distinct values, the same query produces no row at all — the run errors loud with the GROUP LIMIT message from §2. None of the limits below are deal-breakers; all of them are the kind of thing a team discovers the hard way three weeks after a successful rollout. The four to bake into the runbook before that happens:

The rollout pattern that survives these is uneventful. Inventory the columns you would actually want a per-segment reading on (region, tenant, plan tier — not user id, not order id). State each one’s cardinality. Add the WITHIN GROUP DMF, run it once, read GROUP_BY_INFO the way §3 shows. Wire the §4 alert before you switch off the old ungrouped one. The whole loop fits inside a single change window.