feat: Save app properties and others to Person from events

[benjackwhite]

Problem

Fixes PostHog/posthog-js-lite#102

We already have $intial_X for some properties but it happens that people want to filter or configure flags based on the initial values or also the latest value.

Changes

• Adds $X to the $set properties in addition to the $initial_X
• Traditionally we added some properties via the frontend JS to $set in weird cases ($browser for example) but this changed. Choosing to move forward with a more sensible pattern than try and support the old way. The only exception to this is campaign params which I left as they are.

Not sure if there would be any downstream impact in terms of higher number of properties stored but chatted about it in Slack and we seemed to agree it makes sense as an approach

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

How did you test this code?

Tests

[tiina303]

I'd be consistent with both params (i.e. make campaignParams also do $last_, can't think of a reason why these would be different & as a user I'd find that confusing.

Otherwise this seems good, but we might need to do a few things before we can ship it:

1. make sure we don't break folks's existing insights <- they might be using browser etc (I think there's a way to query that ... Tim did it for something else similar)
2. maybe some user communication that Joe/marketing can help us with 🤷‍♀️

[tiina303]

meant to comment ... test failures

[benjackwhite]

I'd be consistent with both params (i.e. make campaignParams also do $last_, can't think of a reason why these would be different & as a user I'd find that confusing.

Otherwise this seems good, but we might need to do a few things before we can ship it:

1. make sure we don't break folks's existing insights <- they might be using browser etc (I think there's a way to query that ... Tim did it for something else similar)

2. maybe some user communication that Joe/marketing can help us with 🤷‍♀️

Regarding 1 - this change doesn't break that. It has been broken a long time so I don't think we need to be concerned about it.

2 makes sense if we rename the campaign params but couldn't we do that after ?

[pauldambra]

looks good to me

maybe some user communication that Joe/marketing can help us with 🤷‍♀️

As it is I think the changelog is a good place for something additive like this...

I think we could add $last_blah for campaign params rather than renaming and breaking things or needing to migrate them... but then you'd have both which is arguably more confusing for a user.

As a compromise you could not add the $last_ to things here so that the $initial_ is the only qualifier but I don't have strong feelings on what's better there

[tiina303]

No-one has time to revisit things at PostHog & migrating/user communication several times is extremely annoying, so why don't we just make the change and add it to the release notes like we want to have it in the future.
By make the change I mean: event properties that we add to the person will be in the format of $initial_ & $last_ for all of the properties the same way.

If that causes problems for some users with old properties / queries for the last without last etc, then we can just script to update their person properties accordingly ... and do it once & be done with it.

Edit: rethinking this let's go with Paul's idea

As a compromise you could not add the $last_ to things here so that the $initial_ is the only qualifier but I don't have strong feelings on what's better there

[tiina303]

posthog/frontend/src/lib/taxonomy.tsx

Line 63 in bee0b07

$browser_version: {

or somewhere we need to update too for them to show up nicely 🤷‍♀️

[tiina303]

🙇‍♀️ Thanks for making the code more readable too :)