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.38k stars 1.28k forks source link

Utm properties get set on later visits but likely shouldn't #7710

Open tiina303 opened 2 years ago

tiina303 commented 2 years ago

Description

utm properties are often used to determine how a user discovered the app in the first place, e.g. I want to know if the user came organically or through some ad etc. Currently if the user initially discovered the app organically we don't set utm parameters, but then later when they return through an ad/referrer link etc we will, that makes us potentially attribute the ad success more than we should.

Expected behavior

The person properties can be used to determine how they discovered the app in the first place (If user discovered the app organically utm parameters aren't later set to future visit referrals).

Alternative

For every user check the first event explicitly to know where they came form.

Additional context

I suspect that if we set browser etc other initial params we should set the utm ones to be None if they weren't sent and then we'd know the user discovered us organically and thee utm params won't be overridden.

Relevant code: https://github.com/PostHog/posthog/blob/35142f636071a7b2bcc05b17dde7da4991e7e203/plugin-server/src/utils/db/utils.ts#L206

See user feedback here: https://posthog.slack.com/archives/C01F31E9PRD/p1639476221083500?thread_ts=1638549825.061900&cid=C01F31E9PRD

charlescook-ph commented 2 years ago

FYI @kpthatsme

timgl commented 2 years ago

Yeah suspect easiest solution would be for posthog-js to always set utm tags to 'organic' if they don't exist (see https://github.com/PostHog/posthog-js/blob/ad9d5f197657498656c2dbb5ae4495b3eb0a9d26/src/utils.js#L637). Would increase data a bit though. Worth rolling out behind a posthog-js setting and testing on our own website

charlescook-ph commented 2 years ago

@tiina303 we can close this one right?

tiina303 commented 2 years ago

Nope unfortunately not. I believe we now always send initial_referrer and initial_referrer_url (from posthog-js, but I'm not sure, my earlier fix for for how we badly overrode it in the past), but we might not always send initial_utm_source for example. If that's not sent, we don't set it, then a later login might set it and upon merging it would look like the initial utm_source was whatever we used in the later login. Here's an example https://app.posthog.com/person/182d53ada75ce-00ce255519d726-26021d51-e1000-182d53ada762fa#activeTab=events if you look at their first event ever you can see that we don't have initial_utm_source Screenshot 2022-08-25 at 18 47 17 so if this person now gets identified, then tomorrow logs in through a google referrer link we'd see the utm source based on that second login for this person.

dan-dr commented 1 year ago

hey @tiina303 We're encountering this issue with several marketing campaigns. We're getting Initial UTM <X> on old users because they clicked a UTM link.

Is https://github.com/PostHog/posthog-js/pull/496 suppose to help?

tiina303 commented 1 year ago

@dan-dr could you use the in-app support ticketing - that way I could get all the context needed to better understand your issue.

MarconLP commented 1 year ago

A current workaround is to set the UTM properties to null whenever the UTM properties are not set. That will make sure the initial_utm properties have a value and won't be set to something else in the future.

It could look something like this:

posthog?.register_once({
  utm_source: null,
  utm_medium: null,
  utm_campaign: null,
  utm_content: null,
  utm_term: null
});
misette-boob commented 10 months ago

Tell me, has a solution been found to this problem? When will it be fixed?

tiina303 commented 10 months ago

please see the previous comment https://github.com/PostHog/posthog/issues/7710#issuecomment-1669996908

MarconLP commented 8 months ago

fixed in: https://github.com/PostHog/posthog.com/pull/7692

charlescook-ph commented 8 months ago

I don't think we can close this issue - we haven't fixed it in the product, only applied the workaround to ourselves.

LeeSanity commented 7 months ago

will you fix this issue in posthog-js in late future @charlescook-ph @tiina303

axelcedercreutz commented 6 months ago

Would also be interested to hear if it's being fixed! @MarconLP @charlescook-ph

MarconLP commented 6 months ago

Would also be interested to hear if it's being fixed! @MarconLP @charlescook-ph

It's currently not fixed, but you can apply this simple workaround to solve the issue right now.

slshults commented 3 weeks ago

+1 https://posthoghelp.zendesk.com/agent/tickets/18229