feat: copy posthog js processing #4
Conversation
pauldambra
changed the title
pauldambra
changed the base branch from
chore/always-include-latest-built-version
to
main
|
|
||
| const vendor = event.properties['$navigator_vendor'] | ||
|
|
||
| event.properties['$device'] = detectDevice(userAgent) |
There was a problem hiding this comment.
I think we use $device_name and/or $device_name on Mobile, I wonder if we should unify that? otherwise the filtering experience isn't ideal unless the filtering considers all those variations?
There was a problem hiding this comment.
I think for this I want to keep it the same as posthog-js so that we can validate the switchover
But then once we've got this in place it'll be "easy" to start adding other platforms/sdks
| event.properties['$browser'] = detectBrowser(userAgent, vendor) | ||
| event.properties['$browser_version'] = detectBrowserVersion(userAgent, vendor) | ||
| const [osName, osVersion] = detectOS(userAgent) | ||
| event.properties['$os'] = osName |
There was a problem hiding this comment.
Same as https://github.com/PostHog/user-agent-plugin/pull/4/files#r1522710965
We use $os_name on Mobile, and $os_version
|
Apologies for the scope creep suggestions: it looks like there's a new spec for user agents https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgentData. It's experimental, but we might want to start getting the sdk sending it, so that we can use it in the future without waiting for people to update their sdk. Scope creep 2: bot detection. We also parse the user agent for bot detection - this is a long list of strings that we maintain. There are a few other sources of this data which are likely more complete than ours, e.g. https://github.com/monperrus/crawler-user-agents, https://github.com/omrilotan/isbot, https://user-agents.net/bots, but if we added all of these to posthog-js it would increase our bundle size by quite a bit. We could do filtering of the largest bots in posthog-js (to keep our costs low) but do a more thorough filtering server-side (to keep our customer's costs low and their data accurate). |
totally... this area feels pretty unlooked after some times. so makes sense to grab data when it's available (even if we ignore it for now) - so will punt this to posthog-js follow up? |
Yeah, would be cool to keep some limited/obvious bot detection in posthog-js and then do more thorough detection in the plugin server (although we did have a customer request to be able to skip bot detection so we'd need to figure out how to honour that too) |
|
and I think the user agent detection change recently in PostHog/posthog-js#1359 so we'd need to update this |
|
this plugin won't. be the way forward here. see: https://posthog.slack.com/archives/C05LJK1N3CP/p1724753326948729 |
was originally stacked on top of #2
see PostHog/meta#182
copies the user agent parsing behavior from posthog-js unchanged and adds config to let us deploy the plugin allowing that processing (for events that aren't expecting the original behavior)
confirmed locally with v3 processing enabled