Wrong Domain

When page views for one domain appear in a different site's dashboard, the same site key is in the tracking scripts on both domains, or the wrong site key was pasted into one of the templates.

How visits are routed to a site

Every beacon carries a site key in the data-k attribute. The server reads that key and increments the visit count for the site associated with that key, regardless of which hostname the beacon came from. The routing is key-based, not hostname-based. If the same site key is in the template for two different domains, all visits from both domains accumulate under one site in the dashboard.

This means the site registration in your dashboard and the key in your script tag must be kept in sync. Adding a new domain without registering it and getting a new key — instead reusing the key from an existing site — merges that domain's traffic into the existing site's count. The visits are not lost, but they land in the wrong place, mixed with unrelated traffic.

How to find which key is on a page

Open the domain in question in a browser. Choose View Page Source. Search for "data-k". The value next to data-k is the site key embedded in that page's script tag. Now open your dashboard and look at the registered sites. Find the site whose key matches that data-k value. That is the site where visits from this domain are being counted.

If the site you find is the wrong one — for example, the key belongs to site A but you are looking at domain B — the fix is to register domain B as its own site, get its key, and update the script tag on domain B's template to use that new key. Future beacons from domain B will then go to site B's count.

If you have several templates or a CMS with multiple theme files, check all of them. It is possible for a shared layout to have one key while a specific page template or a mobile layout has a different key — or no key at all. Each template file that includes the asset.js tag needs to have the correct key for the domain it is served on.

If data was already counted under the wrong site

Historical visit data cannot be reassigned from one site to another. Counts recorded under site A because the site A key was used on domain B remain under site A, attributed to whatever paths and dates they were recorded under. They do not automatically move to site B when you correct the key.

Going forward, once you update the template with the correct key, new beacons will go to the right site. The historical count under the wrong site will be inflated by the period during which the wrong key was in use. If precise historical accuracy is important, note the date you corrected the key. Visits before that date under site A may include traffic from domain B. Visits after that date should be cleanly separated.

If you registered domain B after the fact and it genuinely had no prior registration, the only option for historical data is to accept the mixed count as a known artifact of the period when the wrong key was in use. There is no retroactive reprocessing.

Verifying the fix

After updating the template with the correct key and deploying the change, reload the page in a browser with developer tools open. Go to the Network tab and find the beacon request. The beacon URL or payload will include the site key. Confirm it matches the key shown in Dashboard → Settings → Script tab for the site you intended.

Then generate a test visit — load the page in a clean browser or incognito window without extensions — and check whether the count appears under the correct site in the dashboard within a minute or two. If the count appears under the right site and not the old one, the fix is working.

Troubleshooting

If you have many sites registered and cannot quickly tell which key belongs to which site, the most reliable way to identify them is to go to each site's Settings → Script tab in the dashboard and note its key. Then compare those keys to the data-k values in your live page sources. The site whose key appears in a page's source is the site receiving that page's visits.

If both sites are now counting some traffic but you expect all visits to go to one of them, check whether your redirect is working correctly. If example.com should redirect to www.example.com but some requests are not being redirected — perhaps due to a caching layer serving the old hostname, or a specific path that bypasses the redirect — visits from the non-redirected hostname will land under whichever key is in that hostname's template.

If you are using a CDN or a multi-region hosting setup where different servers may have different template versions deployed, confirm that all servers have received the updated template with the correct key. A CDN edge that has cached the old template will continue to serve the old key to visitors hitting that edge until the cache is invalidated.