-
Notifications
You must be signed in to change notification settings - Fork 799
chore(flags): docs on the new sendFeatureFlags (or send_feature_flags) behavior
#12187
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
Merged
Merged
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
363abab
improve docs on sending feature flags, now that I have the new behavior
dmarticus 792a88f
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus dec39b9
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus c57e3a0
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus 5c08193
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus a6bae41
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus b905975
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus 7d532a6
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus c6d9999
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus ab1f742
Update contents/docs/integrate/feature-flags-code/_snippets/feature-f…
dmarticus 19dc79d
Merge branch 'master' into chore/docs-on-send-feature-flags
dmarticus 6444be3
Merge branch 'chore/docs-on-send-feature-flags' of github.com:PostHog…
dmarticus 9434c21
different version
dmarticus cbd264b
fix version
dmarticus File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
36 changes: 33 additions & 3 deletions
36
...flags-code/_snippets/feature-flags-code-node-set-send-feature-flags-to-true.mdx
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,41 @@ | ||
| The `capture()` method has an optional argument `sendFeatureFlags`, which is set to `false` by default. By setting this to `true`, feature flag information will automatically be sent with the event. | ||
| The `capture()` method has an optional argument `sendFeatureFlags`, which is set to `false` by default. This parameter controls whether feature flag information is sent with the event. | ||
|
|
||
| Note that by doing this, PostHog will make an additional request to fetch feature flag information before capturing the event. So this method is only recommended if you don't mind the extra API call and delay. | ||
| #### Basic usage | ||
|
|
||
| Setting `sendFeatureFlags` to `true` will include feature flag information with the event: | ||
|
|
||
| ```node | ||
| client.capture({ | ||
| distinctId: 'distinct_id_of_your_user', | ||
| event: 'event_name', | ||
| sendFeatureFlags: true, | ||
| }) | ||
| ``` | ||
| ``` | ||
|
|
||
| #### Advanced usage (v5.5.0+) | ||
|
|
||
| As of version 5.5.0, `sendFeatureFlags` can also accept an options object for more granular control: | ||
|
|
||
| ```node | ||
| client.capture({ | ||
| distinctId: 'distinct_id_of_your_user', | ||
| event: 'event_name', | ||
| sendFeatureFlags: { | ||
| onlyEvaluateLocally: true, | ||
| personProperties: { plan: 'premium' }, | ||
| groupProperties: { org: { tier: 'enterprise' } } | ||
| } | ||
| }) | ||
| ``` | ||
|
|
||
| #### Performance considerations | ||
|
|
||
| - **With local evaluation**: When [local evaluation](/docs/feature-flags/local-evaluation) is configured, setting `sendFeatureFlags: true` will **not** make additional server requests. Instead, it uses the locally cached feature flags, and it provides an interface for including person and/or group properties needed to evaluate the flags in the context of the event, if required. | ||
|
|
||
| - **Without local evaluation**: PostHog will make an additional request to fetch feature flag information before capturing the event, which adds delay. | ||
|
|
||
| #### Breaking change in v5.5.0 | ||
|
|
||
| Prior to version 5.5.0, feature flags were automatically sent with events when using local evaluation, even when `sendFeatureFlags` was not explicitly set. This behavior has been **removed** in v5.5.0 to be more predictable and explicit. | ||
|
|
||
| If you were relying on this automatic behavior, you must now explicitly set `sendFeatureFlags: true` to continue sending feature flags with your events. | ||
38 changes: 34 additions & 4 deletions
38
...ags-code/_snippets/feature-flags-code-python-set-send-feature-flags-to-true.mdx
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,41 @@ | ||
| The `capture()` method has an optional argument `send_feature_flags`, which is set to `false` by default. By setting this to `true`, feature flag information will automatically be sent with the event. | ||
| The `capture()` method has an optional argument `send_feature_flags`, which is set to `false` by default. This parameter controls whether feature flag information is sent with the event. | ||
|
|
||
| Note that by doing this, PostHog will make an additional request to fetch feature flag information before capturing the event. So this method is only recommended if you don't mind the extra API call and delay. | ||
| #### Basic usage | ||
|
|
||
| Setting `send_feature_flags` to `True` will include feature flag information with the event: | ||
|
|
||
| ```python | ||
| posthog.capture( | ||
| distinct_id="distinct_id_of_the_user" | ||
| 'event_name', | ||
| distinct_id="distinct_id_of_the_user", | ||
| event='event_name', | ||
| send_feature_flags=True | ||
| ) | ||
| ``` | ||
|
|
||
| ## Advanced usage (v6.3.0+) | ||
|
|
||
| As of version 6.3.0, `send_feature_flags` can also accept a dictionary for more granular control: | ||
|
|
||
| ```python | ||
| posthog.capture( | ||
| distinct_id="distinct_id_of_the_user", | ||
| event='event_name', | ||
| send_feature_flags={ | ||
| 'only_evaluate_locally': True, | ||
| 'person_properties': {'plan': 'premium'}, | ||
| 'group_properties': {'org': {'tier': 'enterprise'}} | ||
| } | ||
| ) | ||
| ``` | ||
|
|
||
| #### Performance considerations | ||
|
|
||
| - **With local evaluation**: When [local evaluation](/docs/feature-flags/local-evaluation) is configured, setting `send_feature_flags: True` will **not** make additional server requests. Instead, it uses the locally cached feature flags, and it provides an interface for including person and/or group properties needed to evaluate the flags in the context of the event, if required. | ||
|
|
||
| - **Without local evaluation**: PostHog will make an additional request to fetch feature flag information before capturing the event, which adds delay. | ||
|
|
||
| #### Breaking change in v6.3.0 | ||
|
|
||
| Prior to version 6.3.0, feature flags were automatically sent with events when using local evaluation, even when `send_feature_flags` was not explicitly set. This behavior has been **removed** in v6.3.0 to be more predictable and explicit. | ||
|
|
||
| If you were relying on this automatic behavior, you must now explicitly set `send_feature_flags=True` to continue sending feature flags with your events. |
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.
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.
I'm a bit confused here.
If you are using local evaluation, you also need to set
onlyEvaluateLocally: truewhen calling capture withsendFeatureFlags? Person and group properties forsendFeatureFlagsare only relevant if locally evaluating?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.
Ahh, I guess if you want
sendFeatureFlagsto evaluate locally too you use it, otherwise it will make a server-call?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.
Not true, we still support property overrides even when we use the server call (e.g. they want to pass a person property that hasn't been ingested yet)
yeah, the idea is you have to specify that you're sending feature flags locally, otherwise we will hit the servers for the most up-to-date evaluation.