-
Notifications
You must be signed in to change notification settings - Fork 128
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: swap the default to identified_only #1468
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Hey @raquelmsmith! 👋 |
src/__tests__/posthog-core.ts
Outdated
@@ -387,6 +401,7 @@ describe('posthog core', () => { | |||
properties: () => ({ distinct_id: 'abc', persistent: 'prop', $is_identified: false }), | |||
remove_event_timer: jest.fn(), | |||
get_property: () => 'anonymous', | |||
props: { $groups: {} }, |
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.
adding this made most the tests pass with the new identified_only
default config. Does this indicate that something else needs to happen somewhere to make sure real users always have this in their props? Or is it just a test fixture thing? (I imagine the latter because people can use identifed_only
with no problem, but want to be certain)
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.
It feels like the latter, but I'll stare at this code a little to convince myself a bit more
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.
Ok, it was the absence of props
in the mock that made the test fail, it didn't actually need $groups: {}
, so I've slightly changed this line to have a more minimal mock
@@ -179,7 +179,7 @@ export const defaultConfig = (): PostHogConfig => ({ | |||
bootstrap: {}, | |||
disable_compression: false, | |||
session_idle_timeout_seconds: 30 * 60, // 30 minutes | |||
person_profiles: 'always', | |||
person_profiles: 'identified_only', |
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.
the main change for swapping the default
if (config.person_profiles) { | ||
this._initialPersonProfilesConfig = config.person_profiles | ||
} |
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.
in order to roll this out slowly, we need to know if the person has already set their config - that it's not just using the default. So we need to store the initial config somewhere.
@@ -408,6 +414,8 @@ export class PostHog { | |||
this.config.persistence === 'sessionStorage' | |||
? this.persistence | |||
: new PostHogPersistence({ ...this.config, persistence: 'sessionStorage' }) | |||
|
|||
// should I store the initial person profiles config in persistence? |
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.
question
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.
The way I've handled this so far is to save whether or not they've sent an event with person processing. If they have then we persist ENABLE_PERSON_PROCESSING
to true.
I'm just wondering whether saving their config gives us anything beyond this.
Here's a couple of cases:
Case 1
- posthog-js starts up with the user setting 'always'
- some events are sent, with person profiles, so
ENABLE_PERSON_PROCESSING
is set - user closes the browser
- new visit, posthog-js starts up with no setting so uses the default
identified_only
- some events are sent, as
ENABLE_PERSON_PROCESSING
was set then these have person profiles
Case 2
- posthog-js starts up with the user setting 'always'
- no events are sent, so
ENABLE_PERSON_PROCESSING
is not set - user closes the browser
- new visit, posthog-js starts up with no setting so uses the default
identified_only
- some events are sent, these are anonymous (if we'd persisted the setting from before, they'd have person profiles)
In case 2 there's a difference, but I'd argue that those events should be sent as anonymous. Wdyt?
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.
TLDR no I don't think so :D
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.
Ooooook so it turns out we don't actually handle this case correctly. I added a fix and some tests to this PR. I hope you don't mind me piggybacking like this, I can very much move it to its own PR if you prefer.
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.
No this is great, thanks!
@@ -398,6 +398,7 @@ export interface DecideResponse { | |||
isAuthenticated: boolean | |||
siteApps: { id: number; url: string }[] | |||
heatmaps?: boolean | |||
defaultIdentifiedOnly?: boolean |
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 will be returned with /decide
Size Change: +3.12 kB (+0.11%) Total Size: 2.83 MB
ℹ️ View Unchanged
|
Woohoo! A caveat I just wanted to flag - this PR does the right thing but if we did things the other way round (set Either way, this PR does the right thing, so maybe you already knew all of this :D Edit: I found a bug in how we were handling the logic above, so I've added a fix and some tests to this PR |
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.
LGTM! I added some stuff, so please make sure those changes LGTY
Looks good to me! Thanks for the help @robbie-c!! I'll wait to merge this until I get the |
Oh @robbie-c I forgot to specify what type of version bump this is.... will it bump automatically? Or just with the next one? |
Warning
This should only be merged after we support the field response from /decide.
Changes
We want to make the
person_profiles: identified_only
config the default for everyone. It will save everyone money - even if they don't change their config - and is better for our customers and our pipeline.Instead of just pushing out a change to posthog-js for this, we want to be able to control the behavior and roll it out slowly, just in case there are any problems.
So, this PR changes the default, but also listens to a field from decide that will say if we should be defaulting people into
identified_only
, or using the old defaultalways
. If someone has set their config manually, then we will continue using that setting.Checklist