-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat(web-analytics): Allow customers to compare against a different period #26820
Conversation
Size Change: 0 B Total Size: 1.11 MB ℹ️ View Unchanged
|
7164e68
to
fd09fea
Compare
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
frontend/__snapshots__/scenes-other-onboarding--onboarding-billing--light.png
Outdated
Show resolved
Hide resolved
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
3413f94
to
18ca9a9
Compare
…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
1ebdc47
to
346e3ed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -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] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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."
),
)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
@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`
cba8a94
to
a424b59
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Does this work well for both Cloud and self-hosted?
Yep
How did you test this code?