posthog-destination: fix an issue with the tracking of anonymous users

[jspizziri]

Currently, it seems to us that there are a few issues with the tracking of anonymous users. First I want to specify that the term "anonymous" is overloaded here. There are 3 categories of events, and I'll specify some terms I'll refer to them by to keep them straight:

1. Anonymous/Unidentified - Events that occur before a user has identified themselves, which should have some sort of anonymousId associated with them. Importantly, we do intend to merge these events into an identified user/"Person" at some point.
2. Identified - Events that occur after a user has identified themselves.
3. Anonymous/Anonymous - Posthog "anonymous" events which are intended never to have identifiable information associated with them. Importantly, these events should never be merged into a "Person" record.

When Enable Anonymous User Profiles Is Enabled

When this setting is enabled, over multiple sessions where the user starts as Anonymous/Unidentified and then becomes Identified, currently, you'll end up with duplicate "person" records in Posthog for that user. While there is an alias event that connects the two of them together, they don't get merged into a single record as they should properly be. Therefore, overtime you accumulate a large set of distinct "Person" records in Posthog all containing the Anonymous/Unidentified event history of a user prior to identification, with aliases back to the true identity with the actual Identified events.

By default, all Posthog events are associated with a person profile. Therefore, identify should not be called for a Anonymous/Unidentified user, but rather only called for the actual Identified user and then immediately aliased to the Anonymous/Unidentified users' previous distinctId. This merges all the users' data (both Anonymous/Unidentified & Identified) into a single record.

When Enable Anonymous User Profiles Is Disabled

If you disable this setting, no events are sent to posthog at all, whereas what I would expect would happen is to have Anonymous/Anonymous events sent to Posthog.

[jspizziri]

This documentation video also is a good source of information on this:

https://www.youtube.com/watch?v=3afzkLS-zQA

[absorbb]

@jspizziri

Thank you!

this PR will enable anonymous events capture for clients that have enableAnonymousUserProfiles disabled.
That may be unwanted or unexpected.
I assume that we need the extra boolean flag e.g. sendAnonymousEvents which when not present will take value of enableAnonymousUserProfiles flag

And also improve description of enableAnonymousUserProfiles flag in UI.

We need some time to make sure that no other unwanted side effect will occur for existing clients.

[jspizziri]

@absorbb

Thanks for taking a look. Yeah, I assumed there might be a need for additional user config options. I've never put in the work to get the stack running locally :), nor did I actually run the code in the PR locally (although I tested my research via direct REST calls to the Posthog API). LMK if there's anything I can do to help get this over the line.

[jspizziri]

Hey @absorbb just wanted to check in and see if there's anything else I can do to get this over the finish line.

Thanks!

[absorbb]

@jspizziri
Apologies for the delay—I had a busy week.

We still need to restore compatibility with the current state of config and introduce an additional configuration option. I’ll be able to work on that next week. If you’re able to handle this part in the meantime, that would be helpful.

Also, do you need this on Cloud only, or for self-hosted as well?

[absorbb]

@jspizziri could you please allow me to push to your branch?

[jspizziri]

@absorbb just sent you R/W to our repo.

[absorbb]

I introduced the sendAnonymousEvents toggle.

Please make sure that i haven't broke your intended changes.
And that UI descriptions properly reflect what these config properties are doing.

I also performed testing on our test system with all config combinations. From my point of view - everything is ok and that one also is ready to be on the cloud tomorrow.

[jspizziri]

@absorbb it looks like it will still function the way I'd expect if the sendAnonymousEvents value is true. 👍

[absorbb]

on the cloud and in beta image