Add FAQ on handling historical data in Journey entry conditions #6655
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pwseg
changed the title
pwseg
approved these changes
Jan 30, 2025
|
Thank you for your contribution! Your pull request is merged, but may take a day or two to appear on the site. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed changes
Added a FAQ/Known behavior when 'Historical Data' is enabled in Journey entry condition, and Engineering's suggested approach:
How to ensure consistent user evaluation in Journey entry conditions that use Historical Data?
When a Journey is published, the computation of the entry step begins immediately in real-time, while the backfill process of historical data runs concurrently. It is important to note that if a user's events or traits evaluated in the entry condition span both real-time and historical data, unintended behavior may occur. This discrepancy could result in users qualifying in real-time, but should not have when their historical data is taken into account.
To prevent this, consider manually creating an audience that incorporates these conditions, including historical data. This pre-built audience can then be referenced in your Journey entry condition. This approach ensures a consistent evaluation of users based on both their real-time and historical data.
Merge timing
Related issues (optional)