feat(analytics): enhance DotAnalyticsService

[nicobytes]

This pull request refactors the DotAnalyticsService API and its consumers to use unified parameter objects for analytics queries, improving flexibility and maintainability. The service methods now accept a single options object (including optional fields like granularity, eventType, and siteId), and the store feature is updated accordingly. Additional tests are added for new query combinations, and utility functions are introduced to build query parameters consistently.

DotAnalyticsService API refactor and enhancements:

• Refactored all analytics service methods (getTotalEvents, getUniqueVisitors, getTopContent, getPageviewsByDeviceBrowser) to accept a single parameter object with optional fields (granularity, eventType, siteId), replacing multiple parameters and overloads. Added private utility methods to build HTTP query parameters for each API call. [1] [2] [3]

• Updated the store feature (withPageview) to use the new parameter object format for all analytics queries, ensuring correct passing of eventType and siteId, and added type guards for array vs. object responses. [1] [2] [3] [4] [5] [6] [7]

Testing improvements:

• Added comprehensive tests for getTotalEvents in dot-analytics.service.spec.ts, covering various combinations of query parameters and validating request construction. Introduced a helper function to match requests by URL and method. [1] [2]

Minor improvements:

• Fixed strict typing for test variables in the service spec file. [1] [2]

This PR fixes: #34849

This PR fixes: #34849

[claude]

Claude finished @nicobytes's task in 2m 14s —— View job

---

PR Review

• Gather context
• Read changed files
• Analyze and post review

---

5 issues worth a second look:

---

1. healthCheck returns AVAILABLE on network failure — dot-analytics.service.ts:70

catchError(() => of(HealthStatusTypes.AVAILABLE))

If the health endpoint is unreachable or returns a 5xx, this silently reports the service as available. It should return NOT_AVAILABLE. Pre-existing, but now that the service is more central to the feature, this is worth fixing. Fix this →

---

2. Double getTopContent call per page load — with-pageview.feature.ts

_loadTopPagePerformance (line 233) and _loadTopPagesTable (line 428) call the same endpoint with identical params on every loadAllPageviewData(). That's two identical HTTP requests. _loadTopPagePerformance only needs items[0] from the same data _loadTopPagesTable already fetches. These could share one request via shareReplay or be consolidated into a single rxMethod that fans out to both state slices.

---

3. No store-level tests for withPageview — with-pageview.feature.ts

The new tests only cover DotAnalyticsService. The withPageview feature has six rxMethod pipelines with switchMap, tapResponse, error handling, and fillMissingApiDates — all refactored in this PR — with zero new unit tests. If the store is already covered in a different spec file, disregard; otherwise this is a meaningful gap.

---

4. Dual type system without a migration path — types/analytics-api.types.ts vs store imports

Store state uses TotalPageViewsEntity, UniqueVisitorsEntity, PageViewDeviceBrowsersEntity (domain entity types), while the service now returns TotalEventsData, UniqueVisitorsData, DeviceBrowserData (new API types). These are structurally compatible today, but the two naming conventions will diverge as both are maintained. Worth deciding now whether the old *Entity types will be deprecated in favor of the new *Data types, or whether they're intentionally separate layers.

---

5. day field name is misleading for monthly granularity — analytics-api.types.ts:96–99

The comment acknowledges this: "for granularity: 'month', values are bucket starts … not necessarily every calendar day." The field is still named day. fillMissingApiDates steps by month when granularity === 'month', so the fill logic is correct, but any code that reads .day and labels it as "day" in the UI will produce misleading labels for monthly views. Low risk now since monthly granularity isn't wired to a chart label, but this will bite when it is.

---

Otherwise the param-builder decomposition is clean, the overload signatures for GetTotalEventsWithoutGranularity / GetTotalEventsWithGranularity are correct TypeScript idiom, and the if (params.siteId) falsy guard correctly suppresses empty-string siteIds.