fix(customer-analytics): Optimize usage metrics query runner with interval grouping

[arthurdedeus]

Problem

The usage metrics query runner generated one SELECT per metric, UNION ALL'd together, each independently scanning the events table. With multiple metrics configured, this meant redundant scans of the same data — all metrics for a given entity (person/group) share the same base filter.

Changes

• Refactored query runner to group metrics by interval and build one query per interval group using countIf/sumIf conditional aggregation
• Daily bucketing with toStartOfDay + gap-filling in Python, replacing per-metric parse_select template queries
• Single events table scan per interval group instead of per-metric UNION ALL

How did you test this code?

Existing test suite passes with updated snapshots confirming the new query structure. hogli test products/customer_analytics/backend/hogql_queries/test/test_usage_metrics_query_runner.py — 25 tests pass.

Publish to changelog?

No

Docs update

🤖 LLM context

Authored by PostHog Code (Claude Code).

---

Created with PostHog Code

[arthurdedeus]

• feat(customer-analytics): Add sparkline visualization for usage metrics #54349
• fix(customer-analytics): Optimize usage metrics query runner with interval grouping #54348 👈 (View in Graphite)
• feat(customer-analytics): add calculation selector and adopt generated API types #54347
• feat(customer-analytics): add sum aggregation to usage metrics #54346
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Hey @arthurdedeus! 👋\nThis pull request seems to contain no description. Please add useful context, rationale, and/or any other information that will help make sense of this change now and in the distant Mars-based future.

[greptile-apps]

Prompt To Fix All With AI

This is a comment left during a code review.
Path: products/customer_analytics/backend/hogql_queries/usage_metrics_query_runner.py
Line: 222-224

Comment:
**`datetime.now()` called independently from query builder**

`_process_group_results` recomputes `date_to`/`date_from`/`prev_date_from` via a fresh `datetime.now()`, but `_build_interval_group_query` already called `datetime.now()` at line 121 to embed timestamps in the SQL. If any time passes between these two calls (including query execution time), the date window used to interpret results won't match the one encoded in the query. At a day boundary this means the wrong days are included in `current_dates`/`previous_dates`, silently producing incorrect totals.

The fix is to compute the reference time once in `_calculate` and pass it to both methods:

```python
# In _calculate, before the for-loop:
date_to = datetime.now(tz=ZoneInfo("UTC"))

# Pass it down:
query = self._build_interval_group_query(interval, group, date_to=date_to)
results = self._process_group_results(response, interval, group, date_to=date_to)
```

Then update both method signatures to accept `date_to: datetime` and remove the internal `datetime.now()` calls.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(customer-analytics): optimize usage ..." | Re-trigger Greptile}

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	View Logs
TestDataWarehouseManagedViewSetModel/test_sync_views_creates_views	View Logs
TestSavedQueryDagSyncIntegration/test_materialize_updates_node_type	View Logs

[tests-posthog]

Query snapshots: Backend query snapshots updated

Changes: 1 snapshots (1 modified, 0 added, 0 deleted)

What this means:

• Query snapshots have been automatically updated to match current output
• These changes reflect modifications to database queries or schema

Next steps:

• Review the query changes to ensure they're intentional
• If unexpected, investigate what caused the query to change

Review snapshot changes →

[greptile-apps]

Prompt To Fix All With AI

This is a comment left during a code review.
Path: products/customer_analytics/backend/hogql_queries/usage_metrics_query_runner.py
Line: 90-102

Comment:
**Repeated DB queries from dropping `@cached_property`**

`_get_usage_metrics()` was previously a `@cached_property` that executed the ORM query once per runner instance. It is now a plain method called independently from `get_cache_payload()`, `to_query()`, and `_calculate()` — each invocation issues a separate `SELECT` against the database. For callers that touch both `get_cache_payload()` (to check/populate the cache) and `_calculate()` (to run the query), the metrics table is read at least twice per request cycle.

Alternatively, keep the method but cache its result as `self._usage_metrics` on first call, or convert the three callers to share a single result computed once in `_calculate`/`to_query`.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: products/customer_analytics/backend/hogql_queries/usage_metrics_query_runner.py
Line: 236

Comment:
**Off-by-one in `previous_dates` upper bound**

The upper bound for the previous period is derived as `(date_from - timedelta(seconds=1)).date()`. The expression works, but it is expressing `date_from.date() - timedelta(days=1)` in a roundabout way that depends on `date_from` never being exactly midnight. The cleaner and more direct form is `(date_from - timedelta(days=1)).date()`, which is explicitly "one day before `date_from`'s date" and is always equivalent for daily bucketing.

```suggestion
        previous_dates = self._date_range(prev_date_from.date(), (date_from - timedelta(days=1)).date())
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (2): Last reviewed commit: "test(backend): update query snapshots" | Re-trigger Greptile}

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-04-22 21:17 UTC	Run
prod-us	✅ Deployed	2026-04-22 21:27 UTC	Run
prod-eu	✅ Deployed	2026-04-22 21:30 UTC	Run