New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor referrer detection to be more flexible / replaceable #20067
Comments
Yes. That should make it possible to fix that one |
FYI this issue shows up in the visitor profile, visits log and in the reports. For example if you have segments that use a specific campaign property as the condition, the visit would be included but because of the bug the segment reports could show it as ‘Direct Entry’ or as a different campaign completely. This also means that the standard campaign reports could also be wrong, i.e. showing a higher number of direct entry even when a visitor actually entered through a campaign or showing as a potentially different campaign. |
@sgiehl Couple of questions:
|
@mattab why is this tagged as 5.1.0, this doesn't sound like extremely high value to a large group of users. Perhaps you can help me understand what value this unlocks? |
@Stan-vw Matt might have more to add here, but I believe the main reason this is 5.1.0 is because it'll be required to fix the related issue: #18511 |
@Stan-vw There might actually also be a couple more undiscovered bugs around campaign detection when using MarketingCampaignsReporting plugin. The problem is, that the detection in core and the plugin might differ, which could even end up in incorrect data being displayed. That might e.g. already be the case when core detects a campaign, while the plugin doesn't (or vice versa). I can explain that in detail in a quick call if you want. |
@mattab Guess that would make some things easier, but we should still aim to refactor the referrer detection, as the current structure is quite complex to understand |
@sgiehl would you recommend amending the scope you set out in the ticket with Matt's suggestion, or is there further work you're suggesting? |
Integrating the MarketingCampaignsReporting plugin to core will require some additional effort. There wouldn't be much benefit in simply shipping the plugin with core. To make code simpler and less error prone we need to restructure the referrer detection to be a bit more flexible (what this issue originally is about), we could then maybe move the campaign detection parts from referrer plugin to the integrated MarketingCampaignsReporting plugin, so all campaign related reporting would end up in that plugin. |
Our current referrer detection is hard coded into the referrer plugin, without any possibility to hook into it.
This makes it hard for plugins to manipulate that part in a useful way as it's only possible to overwrite the detected values afterwards.
I would suggest to refactor the whole detection part into a more flexible design.
First proposal:
Once this was implemented, we need to adjust the MarketingCampaignsReporting plugin, so it's detection uses the new possibilities.
refs L3-362
The text was updated successfully, but these errors were encountered: