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

Update person-properties.mdx to reference new default #10023

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion contents/docs/getting-started/person-properties.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,9 @@ import UserPropertiesSetVsSetOnce from "./\_snippets/user-properties-set-vs-set-

For example, you can create [filters](/docs/product-analytics/trends#filtering-events-based-on-properties) or [cohorts](/docs/data/cohorts) based on person properties, which can then be used to [create insights](/docs/product-analytics/insights), [feature flags](/docs/feature-flags), and more.

For backward compatibility, PostHog captures [identified events](/docs/data/anonymous-vs-identified-events) that create a [person profile](/docs/data/persons) by default. You can change this by setting your snippet or frontend SDK initialization's `person_profiles` value to `identified_only` or a server-side SDK or API event's `$process_person_profile` property to `false`.
By default, PostHog's client-side SDKs will send [anonymous events](/docs/data/anonymous-vs-identified-events), meaning that your users will not have a [person profile](/docs/data/persons), unless you call `.identify()`, `.set()`, or another method that uses person profiles. You can change this by setting your snippet or frontend SDK initialization's `person_profiles` value to `always`
Copy link
Contributor

Choose a reason for hiding this comment

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

I've been dragging my feet on updating all of these because the default hasn't changed. We are inconsistent here.

Source: https://posthog.slack.com/archives/C06R39WNY5B/p1732255387985419

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, that one is newer so we can merge this then.

Copy link
Member Author

Choose a reason for hiding this comment

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

Tbh I'd rather leave it at this point, we can get clarity on monday when people are back from thanksgiving


For backwards compatibility, PostHog's server-side SDKs will send [identified events](/docs/data/anonymous-vs-identified-events), meaning that your users *will* have a [person profile](/docs/data/persons). You can override this by changing a server-side SDK or API event's `$process_person_profile` property to `false`.

> **Note:** Capturing identified events and setting person properties creates a person profile. Under our current [pricing](/pricing), anonymous events can be up to 4x cheaper than identified events (due to the cost of processing them), so it's recommended only to capture identified events when needed.

Expand Down