feat(web-analytics): Add site_name in config and $site_name property

[robbie-c]

Changes

Add site_name to config, and $site_name property which is sent with this value. See PostHog/posthog#18863 for context

Checklist

• Tests for new code (see advice on the tests we use)
• Accounted for the impact of any changes across different browsers

[github-actions]

Size Change: +240 B (0%)

Total Size: 744 kB

Filename	Size	Change
dist/array.full.js	176 kB	+60 B (0%)
dist/array.js	117 kB	+60 B (0%)
dist/es.js	117 kB	+60 B (0%)
dist/module.js	118 kB	+60 B (0%)

ℹ️ View Unchanged

Filename	Size
dist/exception-autocapture.js	12 kB
dist/recorder-v2.js	104 kB
dist/recorder.js	58.4 kB
dist/surveys.js	41.5 kB

_{compressed-size-action}

[benjackwhite]

Nothing wrong with the implementation but this feels like the wrong approach...

We already send a lot of data in default properties all of which we could derive the necessary info from server side instead.

Why don't we just have a place in the UI where you can configure certain events to be attributed with certain sites? It's not far off from what we do with actions.

The big pluses are:

1. You can configure it remotely (makes working with PostHog easy)
2. It works retroactively, not just for events that later have that attribute added
3. We could in theory use it for more things - it can be "site" based for now but essentially you are sort of cohorting events which could be useful in a variety of quick filter ways

[mariusandra]

I never get tired of linking to this issue, which might be relevant: PostHog/posthog#12181

[robbie-c]

I never get tired of linking to this issue, which might be relevant: PostHog/posthog#12181

Hmm - this is a bit of a sidequest. I do like the idea though.

• You can configure it remotely (makes working with PostHog easy)
• It works retroactively, not just for events that later have that attribute added

Configuring remotely is nice, it does mean that it's probably more work to configure though.

Will think about this a bit

[benjackwhite]

• You can configure it remotely (makes working with PostHog easy)
• It works retroactively, not just for events that later have that attribute added

Configuring remotely is nice, it does mean that it's probably more work to configure though.

Will think about this a bit

I could be wrong but I think the "more work" part would be on our side but for the user it would actually be "less work" in that they don't need any special client side config (and we don't need to add support for this to all of our SDKs), rather they "only" have to configure something in the app, which we could even auto configure like - "hey we see you have 4 domains, we have automatically created "sites" based on those domains".

Longer term this feels way more powerful than simply adding more and more data to the event payloads.

[robbie-c]

Closing this in favour of doing PostHog/posthog#12181