Problem/Motivation

Currently, if a user logs in, we identify them server-side if the setting is enabled in posthog_php. We do the same for posthog_js, but we also only if the user is not anonymous.

We need to think of a way on how we would identify anonymous users in sync with the front and backend.
Currently for logged-in users, the admin can decide on the settings page, what user data should be used for the distinct id for user identification (e.g. uid, mail, etc.). This is not possible with anonymous users.

It's not even that important to identify these users, since we could also use the anonymous id generated by posthog, but we want to have the same anonymous id for front and backend events. Maybe we could use that id for logged out users, but caching could be a problem.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork posthog-3500561

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

grevil created an issue. See original summary.

grevil’s picture

grevil commented
Assigned: Unassigned » anybody
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Yes we need to think about how to solve this and see if anyone already solved this for posthog in PHP or other languages!

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Assigned: anybody » grevil

@grevil please contact Posthog support and ask for best practices. Also ask how to identify an anonymous user server-side (null value) - if it's not possible to identify them. Frontend JS allows that, which is a bit strange.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Related issues: +#3481011: Identify logged in users client / server-side
grevil’s picture

grevil commented
Assigned: grevil » Unassigned

Besides the frontend and backend capture calls, we also have the autocapture calls.

I already contacted the support regarding this on Thursday last week, but since we have the free plan, I don't think we'll get an answer.

Now I also contacted the support with a paid account (although the message is not as thought out). I wrote the following:

Hello,

I was wondering whether there is a way to programmatically sync the posthog distinct ID, in the front- (JS-SDK) and backend (PHP-SDK) for logged-out users (which optimally supports caching).

Basically, I would like to somehow generate a distinct ID for users with no unique information and use that distinct ID for the backend capture method calls, frontend capture method calls, and frontend auto capture calls.

Furthermore, I was wondering why the "distinctId" is optional for frontend "capture" method calls (uses auto generated UID as a fallback) but not for PHP-SDK "capture" method calls.

Thanks in advance!

Let's wait for their feedback!

grevil’s picture

grevil commented

This is the support answer:

We recommend passing any data you need to sync along to the backend. In the case of a logged out user, the easiest thing tends to be to add PostHog info to request headers and read those in the backend.

You can see for example we do this here for PostHog session ids. https://github.com/PostHog/posthog/blob/968ddb2a22109e82742a4954feb9a051...

I was wondering whether there is a way to programmatically sync the posthog distinct ID, in the front- (JS-SDK) and backend (PHP-SDK) for logged-out users (which optimally supports caching).

Nothing automatic, but as above at least one way to do it - but the best way varies by framework and application

Furthermore, I was wondering why the "distinctId" is optional for frontend "capture" method calls (uses auto generated UID as a fallback) but not for PHP-SDK "capture" method calls.

The front end is a controlled environment with a concrete lifecycle and storage the SDK can be (almost) guaranteed to have access to. That's not true on the backend. So, these front/back end overlaps tend to need manual sync

Thanks

P

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Okay let's leave this open for further discussions and possible implementations in the future. Thank you @Grevil!

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Further information: https://posthog.com/docs/data/sessions#passing-session-ids-from-client-s...

But I think it's just wrong to pass the ID from the client to the server. Server is always "first", as it builds the client... Guess we should wait for a posthog-side solution to create the ID server-side and then pass it to the client. Or we simply create one ourselves, which would mean the anonymous user needs a cookie / session...

Before proceeding here, let's discuss this. It's currently not important enough to spent a lot of time (which you can here ;))

grevil’s picture

grevil commented
Related issues: +#3554839: How to get gclid into Posthog PHP conversion?

This now got a bit more important, because of #3554839: How to get gclid into Posthog PHP conversion?.

grevil opened merge request !31

grevil’s picture

grevil commented
Status: Active » Needs work

Ok, there is still an update hook needed and the functionality needs to be tested.

Otherwise this is good to go.

grevil’s picture

grevil commented
Status: Needs work » Needs review

All green again! There was a little bug, but all good again :)

I'll do some final testing and then we should be good to go!

grevil’s picture

grevil commented
Status: Needs review » Reviewed & tested by the community

All done! Works great!

grevil’s picture

grevil commented
Version: 1.x-dev » 2.x-dev

  • grevil committed cb8956da on 2.x 
    feat: #3500561 Identify / Synchronize anonymous users client / server...
grevil’s picture

grevil commented
Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • grevil committed 5111cd09 on 2.x 
    Related to issue #3500561: Remove non existing config schema

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.