You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is managing implementation work around person-on-events.
Broad things to keep in mind:
We use an instance setting to decide when to use person-on-event queries.
We're going piecemeal: Get a vertical slice on prod, then continue on the rest. Trends is first.
All tests using journeys_for, or flush_person_and_events() now automatically get person properties on events. But, this doesn't matter unless we override config to use the new queries we write.
Also note: The automated CI for person-on-events disregards snapshots, since these would obviously be different. Make sure there's at least one new test to confirm that the new snapshots are correct.
Aliasing can be tricky, since there's no pdi.person_id anymore, but e.person_id instead. Remember to handle these.
... and the relevant tasks to attack: (Put an @ next to the task you pick up - they're in priority order :) )
Team ingestion set up a test team (team_id 7964) with only person-on-events. We use this for all initial testing, ensuring things work, and then move on to enabling it for team 2 when the backfill is done, which will take a bit longer.
Each piece of work should be self-contained, such that enabling this setting doesn't bork other things which haven't yet been switched on. The new CI tests should automatically ensure this.
Clean up
Once this migration is over, there's a lot of things in flux that we should clean up (and think about self-hosted users upgrade path & ramifications). List of things to remove:
Aggregation by distinct IDs
Person property pushdowns
Person and distinctID joins
Group joins
Remove tests marked with TODO: Delete after
Switch the default CI tests over to person-on-events
(maybe?) remove using_person_on_events parameter
Problems to address
This section is for things that came up during implementation that we need a broader discussion for
Funnel Property Filters and Breakdowns can get borked when using point-in-time person properties for funnels where the first (or last) event doesn't have that property (ex: pre signup)
Lifecycle query depends on person.created_at column, which isn't yet exposed on the events table. If this query ever supports groups, the same would apply to $group_X.created_at
The text was updated successfully, but these errors were encountered:
This issue is managing implementation work around person-on-events.
Broad things to keep in mind:
journeys_for
, orflush_person_and_events()
now automatically get person properties on events. But, this doesn't matter unless we override config to use the new queries we write.pdi.person_id
anymore, bute.person_id
instead. Remember to handle these.... and the relevant tasks to attack: (Put an @ next to the task you pick up - they're in priority order :) )
Cohorts queryingThe migration plan
Team ingestion set up a test team (team_id 7964) with only person-on-events. We use this for all initial testing, ensuring things work, and then move on to enabling it for team 2 when the backfill is done, which will take a bit longer.
Each piece of work should be self-contained, such that enabling this setting doesn't bork other things which haven't yet been switched on. The new CI tests should automatically ensure this.
Clean up
Once this migration is over, there's a lot of things in flux that we should clean up (and think about self-hosted users upgrade path & ramifications). List of things to remove:
TODO: Delete after
(maybe?)remove using_person_on_events parameterProblems to address
This section is for things that came up during implementation that we need a broader discussion for
person.created_at
column, which isn't yet exposed on the events table. If this query ever supports groups, the same would apply to$group_X.created_at
The text was updated successfully, but these errors were encountered: