Support CNAME Cloaking for tracking scripts to reduce DNI interference from ad blockers
I've seen estimates that up to 50% of visitors are using browser-layer ad blockers (Ghostery, AdBlock, uBlock, etc.) or DNS-layer (PI-hole, etc.) ad blocking.
I personally use the Ghostery browser plugin, which blocks CallRail's DNI script when I visit our client sites.
Clearly, this is a big problem - we're missing call and attribution data from a big chunk of our visitors.
Defeating ad blockers should be a top priority for CallRail because less interference by ad blockers = more tracking numbers served = more calls tracked = more billable minutes.
To defeat browser-layer blocking (which is what most people are using), we can use CNAME cloaking.
Some analytics providers are already offering it as a feature: the tenant chooses or is assigned a subdomain, then creates a CNAME record on their own domain with that subdomain as the target. From that point on, the .js is served from that cloaked domain, which isn't on any block lists.
And because browser-layer ad blockers have limited access to the request and DNS resolution, they can't compare the CNAME target to blacklists.
Despite this not being officially supported by CallRail, my experiment so far has produced exciting results.
I created a CNAME record "crcdn" with a target of "cdn.callrail.com", then changed a test site to call "crcdn.test-site.com/..swap.js" rather than "cdn.callrail.com/..swap.js".
When I visit the test site, Ghostery reports that it is blocking CallRail - but swap.js is loaded and the DNI still happens! The tel: link target has been replaced with the tracking number that corresponds to the URL parameter I used in the test.
Using Chrome dev tools, I can see that the request that Ghostery actually blocking was made to js.callrail.com to start the session. That request was initiated by swap.js after it loaded.
With an officially supported CNAME cloaking feature, what I'm imagining could happen is that when swap.js is generated for that company, the references to js.callrail.com and cdn.callrail.com are replaced by the chosen cloaking domain.
In this way, none of CallRail's tracking requests would be blocked at the browser layer.
This leads me to an important caveat - despite getting DNI working against Ghostery, there could be all sorts of potential for unexpected behavior and inaccurate CallRail session data, because:
- CallRail's tracking cookies appear to have been set from the cloaked domain - though this may not actually be a problem, because the keys/values still appear in the output of document.cookie() when I run it in console of the test site.
- Ghostery is still blocking any subsequent requests to *.callrail.com after loading swap.js, which interferes with CallRail session creation and update (CNAME cloaking those domains would fix this issue)
Defeating DNS-layer Blocking
This is another topic, but I think it would take a hybrid server-side/client-side DNI solution where everything is served from the first-party domain
A barebones implementation would be to expose an API endpoint which accepts a URL parameter value and returns the corresponding swap targets+values, then devs could update the DOM as needed based on the API response.