Fixed kpi pageview stats when filtering by pathname

[9larsons]

ref https://linear.app/ghost/issue/ANAL-162/

When filtering by path, the KPIs Pageviews metric is a bit odd. We effectively need to introduce a new 'context' - in general, the KPIs component shows the session metrics, but this is unintuitive when filtering by path, because you don't care how many pageviews all the sessions had that looked at the one particular path. Instead, you want to see the # of pageviews for that path only.

We should also update this to handle time on page instead of the entire session time in a separate change. Ideally, we end up reworking this entirely and use a different MV for page-based metrics, and we'll need to adjust the frontend to query a different endpoint.

[coderabbitai]

Walkthrough

The changes update the SQL logic in the web analytics API pipeline to improve date range handling and pageview calculations. The modified logic introduces a variable to detect single-day ranges and clarifies the handling of the end date by defaulting to the current day when needed. In the session metrics section, a subquery now conditionally counts pageviews only for hits matching a specific pathname. The node previously named finished_data has been renamed to pathname_pageviews with an updated description to reflect its focus on pageviews and time granularity. Additionally, new test cases and corresponding result files have been added to verify the updated functionality, including tests for a single day and a weekly date range with specified pathnames.

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d08b932 and d277ffa.

📒 Files selected for processing (5)

• ghost/web-analytics/pipes/api_kpis.pipe (4 hunks)
• ghost/web-analytics/tests/date_range_one_day_filter_pathname_about_kpis.test (1 hunks)
• ghost/web-analytics/tests/date_range_one_day_filter_pathname_about_kpis.test.result (1 hunks)
• ghost/web-analytics/tests/filter_pathname_about_kpis.test (1 hunks)
• ghost/web-analytics/tests/filter_pathname_about_kpis.test.result (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (5)

• GitHub Check: Tinybird Tests (Web Analytics)
• GitHub Check: Unit tests (Node 22.13.1)
• GitHub Check: Unit tests (Node 20.11.1)
• GitHub Check: Unit tests (Node 18.12.1)
• GitHub Check: Lint

🔇 Additional comments (11)

ghost/web-analytics/tests/filter_pathname_about_kpis.test.result (1)

1-8: Test result data looks well-structured and appropriate.

This test result file provides expected KPI metrics when filtering by the /about/ pathname for a 7-day date range (2100-01-01 to 2100-01-07). The data includes daily metrics for visits, pageviews, bounce rate, and average session duration in seconds. The pattern of data looks reasonable with varying metrics across different days.

ghost/web-analytics/tests/date_range_one_day_filter_pathname_about_kpis.test (1)

1-1: Test case effectively validates single-day filtering behavior.

This test case appropriately tests KPI metrics for a single day (2100-01-03) while filtering by the /about/ pathname. This is particularly important as single-day ranges require special handling in the underlying implementation, which this test validates.

ghost/web-analytics/tests/date_range_one_day_filter_pathname_about_kpis.test.result (2)

1-25: Hourly breakdown of metrics is correctly structured.

This test result provides expected hourly KPI metrics for a single day (2100-01-03) when filtered by the /about/ pathname. The hourly granularity is correctly implemented with 24 entries representing each hour of the day.

---

3-4: Interesting data pattern noted.

I notice that at 01:00:00 there's 1 visit and 1 pageview, while at 02:00:00 there are 0 visits but 1 pageview. This appears to be a valid test case that demonstrates how visits and pageviews can be counted differently (likely a visit that started in the previous hour generated a pageview in the 02:00:00 hour).

ghost/web-analytics/tests/filter_pathname_about_kpis.test (1)

1-1: Test case effectively validates multi-day filtering behavior.

This test case appropriately tests KPI metrics for a date range spanning multiple days (2100-01-01 to 2100-01-07) while filtering by the /about/ pathname. This complements the single-day test and ensures comprehensive coverage of the pathname filtering functionality.

ghost/web-analytics/pipes/api_kpis.pipe (6)

8-24: Improved date range handling with single day detection

The addition of _single_day variable provides a cleaner way to detect if the query is for a single day. This allows for more specific handling of time granularity, with appropriate defaults when date parameters aren't provided.

---

38-56: Enhanced time resolution for single-day queries

Good implementation of conditional time series generation. For single-day queries, the code now generates hourly data points in the site's timezone, while multi-day queries maintain daily granularity. This provides better insight into intraday patterns when needed.

---

66-78: Well-structured session filtering logic

The session filtering implementation is clean and consistent, properly handling all filter parameters including the pathname filter which is key to this PR's fix.

---

89-119: Critical fix for pathname-specific pageview counting

The changes here address the core issue in the PR by conditionally counting only pageviews that match the specified pathname, rather than all pageviews from sessions that visited that pathname. This is accomplished through a well-structured subquery that properly joins with the filtered sessions.

---

142-179: Well-implemented pathname-specific pageview calculation

The renamed node with updated description clearly indicates its purpose. The implementation correctly handles time granularity based on whether it's a single day query, and includes all the necessary filtering conditions to ensure accurate pathname-specific pageview metrics.

---

182-193: Properly integrated conditional pageview source selection

The final data node now correctly selects the appropriate source for pageview metrics based on whether pathname filtering is applied, ensuring consistent behavior across different query scenarios.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.