Allow to use `capture` without passing in `distinctId`

[skoshx]

Is your feature request related to a problem?

It's possible that events happen, where we cannot bind it to a certain authenticated user. This is the reason why in the JS SDK, we have a capture function that optionally allows us to pass in the distinctId

Describe the solution you'd like

Make distinctId optional in the capture function.

Describe alternatives you've considered

I have no alternative as I'm forced to pass in the distinctId

Related sub-libraries

• [ ] All of them
• [ ] posthog-web
• [x] posthog-node
• [ ] posthog-react-native

Additional context

Thank you for your feature request – we love each and every one!

[neilkakkar]

Hey @skoshx , we always need a distinct ID - be it for anonymous or authenticated users.

What posthog-js does is generate a uuid itself when you don't call posthog.identify(). You can & should do the same in posthog-node, if you don't have another way of identifying users.

[skoshx]

@neilkakkar I understand that, but why not abstract away creating that UUID if distinctId isn't passed in, so the library user doesn't need to explicitly know how to do it?

The same way Stripe automatically creates a customer and customerID for you (improving DX massively), I imagine it would also improve DX of using Posthog library to have something similar (plus implementing it would take about 5 minutes?)

[neilkakkar]

Because posthog-js is stateful client side, and there is a concept of anonymous users on the client, for which we autogenerate things.

Posthog-node, in contrast, is stateless, runs only on servers, where it's much rarer to have anonymous tracking, and even when you do, we expect most use cases to use a logical id: like the request correlation id, machine id, etc. etc. depending on the use case.

Curious to hear what's your use case here? - open to making the change if there's a compelling use case here :)

[skoshx]

Actually your explanation has made me realize that like you stated, it actually doesn't make sense to generate a new anaonymous visitor, since server side doesn't have stuff to follow it like localStorage and cookies...

Thank you for your explanation!

[huw]

@neilkakkar I have a use-case here—in stateless environments such as Lambda or Cloudflare Workers, I am only ever really making one request per user, which means I’m only ever really spinning up one client instance per user. So it would save a lot of hassle passing IDs around if I can just identify and be done with it, like in the web.

Sentry behaves this way, for example—I call setUser once when I have enough information to identify my user, and then any events sent with that instance include that user’s ID.

I am not sure if my little inconvenience is worth refactoring the Node client, but I figured I’d bring it up at least ^_^

[neilkakkar]

Hey @huw - I see, this makes some sense. I don't think we'll go this route though I'm afraid, as backend libraries are inherently stateless by design, to make it harder to make mistakes like attaching wrong distinct IDs to events (because in non-serverless environments, every call almost always goes to a different user).