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

[tiina303]

trafficstars

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]

FYI @kpthatsme

[timgl]

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]

@tiina303 we can close this one right?

[tiina303]

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 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]

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]

@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]

A current workaround is to set the UTM properties to organic 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: "organic",
  utm_medium: "organic",
  utm_campaign: "organic",
  utm_content: "organic",
  utm_term: "organic"
});

[misette-boob]

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

[tiina303]

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

[MarconLP]

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

[charlescook-ph]

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

[LeeSanity]

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

[axelcedercreutz]

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

[MarconLP]

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.