How Domains Are Tracked
The Challenge of Tracking Domain.com Versus www.Domain.com
When Domain Tracking script loads on your webpage, it will perform a validation to ensure that the tracker key is real. The system ensures the key matches up with the client’s channel ID and the domain name of the webpage. This ensures that our client is the only one authorized to use the script and that the tracking activity is applied to the correct domain.
When the system validates against the domain, it searches for an exact match, including the prefix of the page. This is important because we track the activity for www.domain.com differently than the activity for ftp.domain.com.
However, it also means that domain.com and www.domain.com are not the same domain. A subscriber might type either one into the browser and be directed to the same webpage with the same code regardless, but the activity won’t be tracked the same. If the browser shows the domain of the page is domain.com, but the tracking script is set up to look for www.domain.com, it won’t find a match, the script will end prematurely, and the visit won’t be tracked. This is also true in reverse. A script looking for domain.com won’t track the activity if you enter the URL beginning with www. in the browser.
This presents a challenge, as there is no way to know if the visitor will type www. into their browser or not, and you don’t want to miss recording that visit.
If the two versions of the URL were really two different pages, with a different script on each one, it would be easy, but they’re the same page with the same code.
Both versions of the domain could be set up in the domain tracking tool. That would result in two different scripts which could be placed on the same page. However, the reporting would then be split between users who typed www. and those who didn’t.
Luckily, there is a better way. Web developers can use apache to customize a .htcaccess file on the site, which will force a browser to redirect to whatever version of the domain you want, whether the visitor typed it with the www. prefix or not. See these pages for more specifics:
https://www.a2hosting.com/kb/developer-corner/apache-web-server/adding-or-removing-the-www-prefix-in-domain-urls
http://solidlystated.com/scripting/remove-or-add-www-prefix-with-htaccess/
Forcing the browser to display the secure version of your website and control the prefix takes a little more work, but it is still doable:
https://www.weavweb.net/2015/06/03/enforcing-https-www-prefix-with-apache-htaccess-redirects-using-cpanel/
http://stackoverflow.com/questions/13977851/htaccess-redirect-to-https-www
Making these changes also has the added benefit of improving your website’s SEO by combining visits that would normally be split between visits to www.domain.com and domain.com. And, you can choose to display your domain with the prefix or without. Just let your digital services specialist know which should be tracked.
When Domain Tracking script loads on your webpage, it will perform a validation to ensure that the tracker key is real. The system ensures the key matches up with the client’s channel ID and the domain name of the webpage. This ensures that our client is the only one authorized to use the script and that the tracking activity is applied to the correct domain.
When the system validates against the domain, it searches for an exact match, including the prefix of the page. This is important because we track the activity for www.domain.com differently than the activity for ftp.domain.com.
However, it also means that domain.com and www.domain.com are not the same domain. A subscriber might type either one into the browser and be directed to the same webpage with the same code regardless, but the activity won’t be tracked the same. If the browser shows the domain of the page is domain.com, but the tracking script is set up to look for www.domain.com, it won’t find a match, the script will end prematurely, and the visit won’t be tracked. This is also true in reverse. A script looking for domain.com won’t track the activity if you enter the URL beginning with www. in the browser.
This presents a challenge, as there is no way to know if the visitor will type www. into their browser or not, and you don’t want to miss recording that visit.
If the two versions of the URL were really two different pages, with a different script on each one, it would be easy, but they’re the same page with the same code.
Both versions of the domain could be set up in the domain tracking tool. That would result in two different scripts which could be placed on the same page. However, the reporting would then be split between users who typed www. and those who didn’t.
Luckily, there is a better way. Web developers can use apache to customize a .htcaccess file on the site, which will force a browser to redirect to whatever version of the domain you want, whether the visitor typed it with the www. prefix or not. See these pages for more specifics:
https://www.a2hosting.com/kb/developer-corner/apache-web-server/adding-or-removing-the-www-prefix-in-domain-urls
http://solidlystated.com/scripting/remove-or-add-www-prefix-with-htaccess/
Forcing the browser to display the secure version of your website and control the prefix takes a little more work, but it is still doable:
https://www.weavweb.net/2015/06/03/enforcing-https-www-prefix-with-apache-htaccess-redirects-using-cpanel/
http://stackoverflow.com/questions/13977851/htaccess-redirect-to-https-www
Making these changes also has the added benefit of improving your website’s SEO by combining visits that would normally be split between visits to www.domain.com and domain.com. And, you can choose to display your domain with the prefix or without. Just let your digital services specialist know which should be tracked.