Hi @ograssini
This is clear for me…
In my last message I used “feature request” as a generic term for new feature or bug report… (and the link I provided was for bugs).
In GitHub, there is already some (other) bug/feature about conversion attribution:
opened 03:58AM - 13 Jan 22 UTC
closed 11:48AM - 22 Aug 22 UTC
Bug
c: Tracking
from https://forum.matomo.org/t/referral-exclusions/33582/25
The resolution s… uggested by Matomo in this article https://matomo.org/faq/how-to/how-do-i-add-a-referral-exclusion-in-matomo/ does not really address the underlying issue - it merely recategorizes the referrer from “website” to “direct entry”, which in reality isn’t the true referrer for the user’s visit.
Here is an example of what is happening.
1. User clicks on an email link to visit the website.
2. User browses website and adds items to basket (at this stage referrer is “Email campaign”)
3. User completes the order but and website redirects to 3rd party payment provider (paypal/amazon etc)
4. User returns to website (but now the referrer for the visit is reset from “Email campaign” to “website” or if you have set the referrer exclusions it will be set to “direct entry”. What we need is for it to remain as “Email Campaign”.
As a result we are over attributing the channel “direct entry” greatly (40% vs 15% on GA).
I'm not sure if we actually should call this feature "Referrer exclusion" as it's more like an "ignore refrerrer" or "keep the original referrer"? We wouldn't exclude this tracking request. We would still track that referrer but re-use the original referrer from the same visit. If it's from a different visit then we would use again a direct visit?
opened 11:39AM - 22 Aug 22 UTC
Enhancement
This is a follow-up issue to the discussion in #18612
### Summary
When a v… isitor visits the page, the visit will be attributed to a certain referrer. This can currently be `website`, `campaign`, `search engine` or `social network`. If non of this referrer can be detected the visit will be attributed as `direct`.
When a visitor afterwards revisits the page coming from another referrer and the referrer was previously attributed as `direct`, we currently may update the attribution to this new referrer. See workflow below:
### Current Attribution workflow

### Conclusion
Updating the referrer in that case might not be correct, as the visitor initially came directly to the page, but would then be attributed to another channel.
As far as I know the code to update the referrer was initially added to fix some issue, where the referrer was not yet set with the first tracking request, but was sent with a later one. Not updating the referrer in that case, would then mean incorrectly attributing the visit as direct, instead of the correct referrer.
A possible solution could be to only set/update the referrer until the very first page view tracking request of a visit. This would solve the issue, that other tracking requests might have already created a visit without a referrer, as it would then be updated with the page view request.
Changing any behavior in referrer attribution might result in differently tracked data and thus changing numbers. As this might bring trouble, we should not change that outside of a major release.
Also we should consider to do that using a config flag, that will only be activated for new installs automatically, so it won't harm any existing install by default.
Your one is another use case I think.
Ping to @SteveG who participate the most on this subject.