How-to · Updated October 11, 2026
Fix call tracking numbers that don't swap on your website
Updated October 11, 2026
20 minutes
Test in a new private window with your page address and ?gclid=test typed in full. If it does not swap, check in this order: one tracking script runs, the ad source's rule matches the visit, each page number is linked to a tracking number, each is text rather than an image, and the cookie banner allows it.
Before you start
- Access to your call tracking account and to wherever its script is installed: the site itself or its Tag Manager container.
- The number exactly as your website prints it, in every place it appears, including the tap-to-call link.
- A phone to make one test call once the number swaps.
Test it the way an ad visitor arrives
Start with the test itself, because a test from a used browser can make a working swap look broken. Call tracking scripts usually remember the first source a browser arrived from (CallTrackingMetrics does), so a browser that once loaded the site normally can keep showing the normal number.
- Close every private or incognito window, then open one new one. Use a fresh one for every test.
- Type your page address with ?gclid=test on the end, in full. Do not let the address bar fill it in, or it may load the address without the test tag.
- Wait for the page to finish loading. A script that loads late can take a second or two to swap the number.
- Check every place the number appears. On a phone, or a phone-width view, tap the number too: the number it dials has to be the tracking number, not only the number you see.
?gclid=test imitates a Google Ads visit, which is what a Google Ads source usually looks for. CallTrackingMetrics' Microsoft Ads (Bing Paid) source looks for ?msclkid=test or UTM tags instead. A source built on UTM tags needs its own test address. A source built on a referring site is tested by clicking through to your site from that site.
If it does not swap, check these in order
Work down these checks in order and stop at the first one that fails. The steps name CallTrackingMetrics' screens as one example; other tools have the same parts under their own names.
- The script runs, once. Open the browser console and run your tool's check. In CallTrackingMetrics, type __ctm.config.aid: an error or nothing means the script is not running, and a number other than your account ID means another account's script. If Tag Manager installs it as a Custom HTML tag, the page source will not show it, so check the published container instead.
- No second call tracking script is on the page. CallTrackingMetrics says other call tracking scripts interfere with its own, and the same applies to a second copy of one tool. Remove the extra one.
- The source rule matches the visit. Open the source meant for ad visitors and confirm it is set to swap on the website (the onsite toggle in CallTrackingMetrics), that its landing page rule looks for what the ad visit carries, and that no source higher in the order catches the same visit first.
- Each number on the page is linked to a tracking number. The script only replaces numbers it is told to look for, so a page with two different numbers needs a link for each. A tracking number with no page number linked to it is installed and does nothing. Link them, then reopen the setting to confirm the link saved.
- The number matches its format. A vanity number, or one formatted unusually, needs an exact match entry as well as the normal one. CallTrackingMetrics says an exact match entry fixes many common swap failures.
- The number is text. The script does not swap a number inside an image or graphic on its own. The simplest fix is to change it to text on the page. Keeping the image needs a developer and the tool's image callback.
- A caching or speed plugin is not altering the script. Exclude the tracking script from the cache, or the page from caching.
- The cookie banner lets it run. If the banner files the tracking script's cookies as marketing, visitors who decline see no swap at all. Test once with cookies accepted. Which category the cookies belong in is a privacy decision, not a setting to flip for coverage.
Check it worked
In a new private window with ?gclid=test, every copy of the number on the page should show the tracking number, and tapping it should dial the tracking number. In CallTrackingMetrics, typing __ctm_tracked_numbers in the console returns true with the number shown.
Then call the swapped number from your phone. The call should appear in your call tracking log under the ad source, not as a direct visit.
In another new private window (close the first one), a plain visit with no test tag should still show your own number if the tool only targets ad visitors.
Testing Google's own website call snippet
Google's snippet swaps in a Google forwarding number only for visitors who came from an ad, so ?gclid=test is not Google's test. Google says to search, click your own ad (the click is charged), and check the number changed. It can take up to an hour after setup, and you should delete the gwcc cookie before testing again.
Google's default snippet tracks one number per page. Tracking a second number means installing and editing the snippet yourself, and updating the number behind a tap-to-call link needs the snippet's callback function. Google recommends that option only for someone comfortable with JavaScript, so it is often a developer's job.
Why it swaps for ad visitors but not for you
The script ties a browser to the first source it arrived from, for 30 days by default in CallTrackingMetrics. If you once opened your site from a bookmark, that browser keeps the bookmark's number. That is the script doing its job, and the reason every test starts in a fresh private window.