PostHog / posthog

🦔 PostHog provides open-source product analytics, session recording, feature flagging and A/B testing that you can self-host.
https://posthog.com
Other
21.41k stars 1.28k forks source link

Make it easier to separate different websites #18863

Open robbie-c opened 10 months ago

robbie-c commented 10 months ago

Is your feature request related to a problem?

It's currently impossible to separate web and app traffic in some cases.

If they are on different hosts (domain or subdomain), this is relatively simple to do with the Host filter (and https://github.com/PostHog/posthog/pull/18818 will help), but if the structure is something like...

Marketing pages: http://www.example.com/pricing http://www.example.com/features

Product http://www.example.com/account http://www.example.com/:projectId/dashboard

...then this is harder to do. If there were only a few pages one could use a regex, but this approach does not work if there are many pages. In this example, the marketing pages and the product could be completely separate sites, that are combined into the same subdomain using e.g. cloudflare.

We should also consider how the breakdowns should look, e.g. whether Top paths should just be the pathname, or whether we should include the full url.

Describe the solution you'd like

// in the marketing site
posthog.init(
    "SOME_API_KEY",
    {
        site_name: "marketing_site"
   }
)
// in the product site
posthog.init(
    "SOME_API_KEY",
    {
        site_name: "product_site"
   }
)
// in the iOS app
posthog.init(
    "SOME_API_KEY",
    {
        site_name: "ios_app"
   }
)

The API key is the same, as these are in the same project, so funnels etc work.

The site_name would get passed as a property with all events, and appears in in-sights and web analytics as a built-in property.

It could be pretty useful to have this as a built-in property for other reasons too, e.g. this would be useful as a filter in many trends, and it would be potentially useful to show users their quota usage by site_name.

Describe alternatives you've considered

Could use a super property instead, but that wouldn't work in web analytics where we don't support custom properties.

We might want a different name, as I imagine that this would be useful for the mobile sdks as well (i.e. not "site"s).

Additional context

https://posthog.slack.com/archives/C05LJK1N3CP/p1700666063561559

timgl commented 10 months ago

Could use a super property instead, but that wouldn't work in web analytics where we don't support custom properties.

We could just support this as a 'native' property, like we will with $browser etc? For that reason I'd suggest the property gets sent as $site_name too

robbie-c commented 10 months ago

Let's do https://github.com/PostHog/posthog/issues/12181 instead of the approach I suggested