Advanced Analytics Filters

[pepeladeira]

Adds support for advanced filter operators in analytics: IS, IS NOT.

Changes

Frontend:

• Multi-select filter UI with checkboxes
• Live filtering (applies immediately)
• Operator toggle between "is" and "is not"
• Smart display: shows individual values or count ("2 countries")
• URL format: ?country=US,BR or ?country=-US for negation

Backend:

• Shared parse function in @dub/utils for frontend/backend consistency
• Zod schema transforms for filter parameters
• Generic SQL builder for all filter types
• Backward compatible with existing single-value filters

Tinybird:

• Updated 5 pipes (count, timeseries, group_by, group_by_link_metadata, events)
• Advanced filter SQL for 11 filter types (country, city, device, browser, etc.)
• JSON-based filter system for scalability

Summary by CodeRabbit

• New Features

  • Advanced analytics filters: operator-aware (is / is not / is one of / is not one of), multi-value/exclusion support across domains, tags, folders, UTMs, partner/group/tenant, and metadata.
  • UI: per-filter removal, operator toggling, multi-value selection, and loader-aware active-filters display; filter components and hooks expose new handlers.

• Improvements

  • Unified parsing and normalization for legacy filter formats; richer query parsing and Tinybird pipe-driven filtering; public types expanded for flexible filter shapes.

• Tests

  • Large additions of unit and integration tests for filter parsing, normalization, and analytics endpoints.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/web/ui/analytics/use-analytics-filters.tsx`:
- Around line 1004-1018: The loader placeholders in activeFiltersWithStreaming
produce numeric values (values: [i]) which mismatches the string[] shape used
elsewhere; update the streaming branch that creates loader filter entries (the
Array.from(...).map callback) to emit string values (e.g., String(i) or `${i}`)
so the resulting loader filter has values: string[] and matches the
type/behavior expected by consumers of activeFiltersWithStreaming, leaving
activeFilters and streaming logic unchanged.

🧹 Nitpick comments (3)

apps/web/ui/analytics/use-analytics-filters.tsx (3)

121-123: Unnecessary indirection — parseFilterParam is a trivial wrapper.

parseFilterParam just delegates to parseFilterValue with no additional logic or closure state. You can call parseFilterValue directly at every call site and remove this useCallback.

---

165-165: Deeply nested ternary chain harms readability.

This single line chains four ternary operators to resolve the param value for destructured keys. A lookup map would be clearer and easier to extend.

♻️ Suggested refactor

-      const value = params[filter] || (filter === "domain" ? domain : filter === "tagIds" ? tagIds : filter === "root" ? root : filter === "folderId" ? folderId : undefined);
+      const destructuredParams: Record<string, string | undefined> = {
+        domain,
+        tagIds,
+        root,
+        folderId,
+      };
+      const value = params[filter] || destructuredParams[filter];

---

879-887: URL construction for link filter assumes no protocol in value.

new URL(\https://${value}`)will produce an invalid URL likehttps://https://example.com/...` if value ever contains a protocol prefix. Currently, linkConstructor({ pretty: true }) strips the protocol, so this works — but it's an implicit coupling. A guard or comment would prevent a subtle breakage if linkConstructor's behavior changes.

🛡️ Defensive guard

     } else if (key === "link") {
+      const linkUrl = value.startsWith("http") ? value : `https://${value}`;
       queryParams({
         set: {
-          domain: new URL(`https://${value}`).hostname,
-          key: new URL(`https://${value}`).pathname.slice(1) || "_root",
+          domain: new URL(linkUrl).hostname,
+          key: new URL(linkUrl).pathname.slice(1) || "_root",
         },
         del: "page",
         scroll: false,
       });

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Loader placeholder uses numeric values while all other filters use string arrays.

The loader entries use values: [i] where i is a number (0 or 1), while every other filter builds values as string[]. If any downstream consumer iterates activeFiltersWithStreaming and calls string methods on values, this will throw at runtime. Consider using string values for consistency.

Proposed fix

-          ? Array.from({ length: 2 }, (_, i) => i).map((i) => ({
+          ? Array.from({ length: 2 }, (_, i) => i).map((i) => ({
             key: "loader",
-            values: [i],
+            values: [String(i)],
             operator: "IS" as const,
           }))

🤖 Prompt for AI Agents

In `@apps/web/ui/analytics/use-analytics-filters.tsx` around lines 1004 - 1018,
The loader placeholders in activeFiltersWithStreaming produce numeric values
(values: [i]) which mismatches the string[] shape used elsewhere; update the
streaming branch that creates loader filter entries (the Array.from(...).map
callback) to emit string values (e.g., String(i) or `${i}`) so the resulting
loader filter has values: string[] and matches the type/behavior expected by
consumers of activeFiltersWithStreaming, leaving activeFilters and streaming
logic unchanged.