Open tiina303 opened 2 years ago
FYI @kpthatsme
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
@tiina303 we can close this one right?
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.
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?
@dan-dr could you use the in-app support ticketing - that way I could get all the context needed to better understand your issue.
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
});
Tell me, has a solution been found to this problem? When will it be fixed?
please see the previous comment https://github.com/PostHog/posthog/issues/7710#issuecomment-1669996908
I don't think we can close this issue - we haven't fixed it in the product, only applied the workaround to ourselves.
will you fix this issue in posthog-js in late future @charlescook-ph @tiina303
Would also be interested to hear if it's being fixed! @MarconLP @charlescook-ph
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.
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