Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(web-analytics): Allow customers to compare against a different period #26820

Merged
merged 13 commits into from
Dec 17, 2024

Conversation

rafaeelaudibert
Copy link
Member

@rafaeelaudibert rafaeelaudibert commented Dec 11, 2024

Changes

Right now, we'd always compare our data against the last period, i.e. if we're looking at the data from the last 14 days, then you'd always compare it against the previous 14 days.

This is not always ideal, as someone might want to compare against numbers from the same time last year.

We've added the comparator component in a previous commit (hidden behind a FF) and we're now actually using that data in the backend.

image

Does this work well for both Cloud and self-hosted?

Yep

How did you test this code?

  • Manual UI tests
  • Backend tests

Copy link
Contributor

github-actions bot commented Dec 11, 2024

Size Change: 0 B

Total Size: 1.11 MB

ℹ️ View Unchanged
Filename Size
frontend/dist/toolbar.js 1.11 MB

compressed-size-action

Base automatically changed from display-stats-from-conversion-goals-only-2 to master December 11, 2024 16:08
@rafaeelaudibert rafaeelaudibert force-pushed the implement-comparison-to-complex-past-period branch from 7164e68 to fd09fea Compare December 12, 2024 19:29
@posthog-bot
Copy link
Contributor

📸 UI snapshots have been updated

1 snapshot changes in total. 0 added, 1 modified, 0 deleted:

  • chromium: 0 added, 1 modified, 0 deleted (diff for shard 1)
  • webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.

@posthog-bot
Copy link
Contributor

📸 UI snapshots have been updated

1 snapshot changes in total. 0 added, 1 modified, 0 deleted:

  • chromium: 0 added, 1 modified, 0 deleted (diff for shard 1)
  • webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.

@rafaeelaudibert rafaeelaudibert force-pushed the implement-comparison-to-complex-past-period branch from 3413f94 to 18ca9a9 Compare December 12, 2024 21:19
@rafaeelaudibert rafaeelaudibert marked this pull request as ready for review December 12, 2024 21:23
rafaeelaudibert and others added 8 commits December 13, 2024 12:40
…eriod

Right now, we'd always compare our data against the last period, i.e. if we're looking at the data from the last 14 days, then you'd always compare it against the previous 14 days.

This is not always ideal, as someone might want to compare against numbers from the same time last year.

We've added the comparator component in a previous commit (hidden behind a FF) and we're now actually using that data in the backend.
Use same methods as we're using on `stats_table` to calculate previous metrics. We've extracted this up to `web_analytics_query_runner`
This is breaking some of our code and it's also a bad default
@rafaeelaudibert rafaeelaudibert force-pushed the implement-comparison-to-complex-past-period branch from 1ebdc47 to 346e3ed Compare December 13, 2024 17:01
@rafaeelaudibert rafaeelaudibert enabled auto-merge (squash) December 13, 2024 18:29
Copy link
Member

@robbie-c robbie-c left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot 2024-12-14 at 15 56 07

I got this error on the paths insight when I went from "no comparison" to "compare to previous period"

@@ -1,67 +1,4 @@
posthog/warehouse/models/ssh_tunnel.py:0: error: Incompatible types in assignment (expression has type "NoEncryption", variable has type "BestAvailableEncryption") [assignment]
posthog/temporal/data_imports/pipelines/sql_database_v2/schema_types.py:0: error: Statement is unreachable [unreachable]
Copy link
Member

@robbie-c robbie-c Dec 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a huge diff! I couldn't spot a difference, but I guess there probably was one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a single difference. I really don't know why everything was reordered 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah fair enough - don't worry too much about it. In general we should try to reduce this list but IMO we don't need to be too strict

@@ -15,13 +15,13 @@ class QueryPreviousPeriodDateRange(QueryDateRange):
"""Translation of the raw `date_from` and `date_to` filter values to datetimes."""

_team: Team
_date_range: Optional[InsightDateRange]
_date_range: Optional[InsightDateRange | DateRange]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: Why are these different?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A: They look the same except for defaults

class InsightDateRange(BaseModel):
    model_config = ConfigDict(
        extra="forbid",
    )
    date_from: Optional[str] = "-7d"
    date_to: Optional[str] = None
    explicitDate: Optional[bool] = Field(
        default=False,
        description=(
            "Whether the date_from and date_to should be used verbatim. Disables rounding to the start and end of"
            " period."
        ),
    )

class DateRange(BaseModel):
    model_config = ConfigDict(
        extra="forbid",
    )
    date_from: Optional[str] = None
    date_to: Optional[str] = None
    explicitDate: Optional[bool] = Field(
        default=False,
        description=(
            "Whether the date_from and date_to should be used verbatim. Disables rounding to the start and end of"
            " period."
        ),
    )

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason not to use InsightDateRange?

Copy link
Member Author

@rafaeelaudibert rafaeelaudibert Dec 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically because of the default. Insights want to set 7 days as default, we need it to be empty by default - there are a lot of assumptions behind that. I'll change it to have no default to improve the code readability, we can always revert it

posthog/hogql_queries/web_analytics/external_clicks.py Outdated Show resolved Hide resolved
@rafaeelaudibert
Copy link
Member Author

I got this error on the paths insight when I went from "no comparison" to "compare to previous period"

@robbie-c I think this is happening because you have some cached data, I can't reproduce it 🤔.

I've added a failsafe to guarantee that doesn't happen, though.

These are basically the same, the only difference is the default. Let's use `DateRange` without the default everywhere. If this proves to be a problem (too many broken tests) we can either:?
1. revert this
2. try to use it with the default on the places where we were not using a default before

fix: Remove last references to `InsightDateRange`
@rafaeelaudibert rafaeelaudibert force-pushed the implement-comparison-to-complex-past-period branch from cba8a94 to a424b59 Compare December 16, 2024 18:43
Copy link
Member

@robbie-c robbie-c left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@rafaeelaudibert rafaeelaudibert merged commit 22cd345 into master Dec 17, 2024
96 checks passed
@rafaeelaudibert rafaeelaudibert deleted the implement-comparison-to-complex-past-period branch December 17, 2024 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants