That's not the issue here. The issue is that Hacker News is on HTTPS, but the link he posted to dictionarydomains.co isn't. Browsers don't pass a referrer on links between HTTPS->HTTP. So, visits from HN don't have a referrer. Custom Channel Groupings won't help in this case, because GA is completely blind to what visits are referrer-blocked HTTPS
I've seen people bypass this by either:
1. Having a HN specific URL (sometimes just ?hn attached to the URL)
2. Just having HTTPS landing pages.
One thing that could help fix this behavior (on newer browsers) would be for HN to explicitly authorize passing the referrer using `<meta name="referrer" content="always">` or "origin"
Comments
That's not the issue here. The issue is that Hacker News is on HTTPS, but the link he posted to dictionarydomains.co isn't. Browsers don't pass a referrer on links between HTTPS->HTTP. So, visits from HN don't have a referrer. Custom Channel Groupings won't help in this case, because GA is completely blind to what visits are referrer-blocked HTTPS
I've seen people bypass this by either:
1. Having a HN specific URL (sometimes just ?hn attached to the URL)
2. Just having HTTPS landing pages.
One thing that could help fix this behavior (on newer browsers) would be for HN to explicitly authorize passing the referrer using `<meta name="referrer" content="always">` or "origin"
EDIT: Filed a bug to get this implemented on HN, since Chrome and Safari support it, and Firefox support is ongoing: https://github.com/HackerNews/HN/issues/68
Thanks for that detailed explanation. I learned something new.
Do you know if it's the same case if the referrer link is HTTP->HTTPS?
No, the only problem case is HTTPS->HTTP.
Default behaviors:
HTTP->HTTP: Referrer
HTTP->HTTPS: Referrer
HTTPS->HTTPS: Referrer
HTTPS->HTTP: No Referrer :(