If you have installed the Clickport tracker but data is not appearing in your dashboard, this guide will help you diagnose and fix the issue. Work through the sections below in order.
The fastest way to check if the tracker is working is to use your browser's developer tools. Open your website, then press F12 (or Cmd+Option+I on Mac) to open DevTools. Click the Network tab, then reload the page.
Look for two requests: the tracker.js script loading from clickport.io, and a POST request to /api/event that sends the pageview. Here is what a successful installation looks like:
{"success":true,"session_id":...}If you see both requests with a 200 status, your installation is working. Data will appear in your dashboard within a few seconds.
If the event request returns 200 but the response body contains a message like {"status":"blocked"}, the server accepted the request but filtered it. See the "Traffic being filtered" section below for details.
If the tracker is not loading or events are not being sent, walk through this checklist to identify the issue.
If you do not see the tracker.js request in the Network tab at all, the script is being blocked before it can load.
Some ad blockers maintain filter lists that block analytics scripts. To test whether an extension is causing the problem:
If you need to work around ad blockers for your visitors, you can proxy the tracker through your own domain. See Script Configuration for setup instructions.
If your site uses a Content Security Policy, you need to allow connections to clickport.io. Add the following to your CSP header:
script-src https://clickport.io;
connect-src https://clickport.io;The script-src directive allows the tracker script to load. The connect-src directive allows the tracker to send data to the /api/event endpoint.
To check whether CSP is causing the issue, open the browser Console tab (next to the Network tab) and look for errors mentioning "Content Security Policy" or "CSP".
If you recently added the tracker snippet to your site, your old HTML may still be served from a cache. Purge your site's cache (CDN, hosting provider, or caching plugin) and reload the page. Most caching plugins in WordPress, Squarespace, and similar platforms have a "Purge Cache" or "Clear Cache" button in their settings.
Some performance optimization tools (like WP Rocket, SiteGround Optimizer, Autoptimize, or W3 Total Cache) may defer, combine, or modify scripts in ways that break the tracker. If you use one of these plugins, try adding an exclusion for tracker.js or clickport.io in the plugin's settings.
If tracker.js loads with a 200 status but you don't see the /api/event request, or the request fails, one of these is the cause.
The tracker automatically disables itself when running on localhost, 127.0.0.1, or file:// URLs. This is intentional: it prevents development traffic from polluting your analytics data.
To test tracking, deploy your site to a real domain. There is no way to override this behavior in production. If you need to test the script locally during development, see Script Configuration for the __CP_TEST__ flag.
The data-domain attribute in your script tag must match the domain you registered in Clickport. The server compares the domain you registered with the Origin or Referer header of incoming requests.
Common mistakes:
data-domain="www.yoursite.com" when you registered yoursite.com (or vice versa). Clickport strips the www. prefix automatically, so either should work.data-domain="https://yoursite.com". The value should be just the domain name, without the protocol.data-domain="yoursite.com/" with a trailing slash.The correct format is simply:
<script defer data-domain="yoursite.com"
src="https://clickport.io/tracker.js"></script>yoursite.com in Clickport, traffic from blog.yoursite.com and shop.yoursite.com will be tracked under the same site. Use data-domain="yoursite.com" on all subdomains.
Clickport supports a browser-level self-exclusion mechanism. If the clickport_ignore key in localStorage is set to "true", the tracker silently exits without sending any data.
This is useful for excluding yourself, but you may have enabled it and forgotten. To check:
F12)localStorage.getItem('clickport_ignore')"true", remove it by typing: localStorage.removeItem('clickport_ignore')The tracker checks for automated browser environments before sending data. If navigator.webdriver is true (which is set by Puppeteer, Playwright, Selenium, and similar automation tools), the tracker will not fire. This also applies to PhantomJS and Cypress test runners.
If the tracker is loading and sending events but your dashboard still shows no data (or fewer visits than expected), the server may be filtering the traffic. Clickport applies several layers of protection to keep your analytics clean.
200 OK with {"success":true} rather than an error code. This prevents attackers from probing to find out why their traffic was rejected.
If you enabled "Exclude my IP" in your Clickport settings, all traffic from your IP address is filtered out at the server level. This applies to every browser and device on that IP. If you are testing from the same network, your visits will not appear.
To check: open your dashboard Settings, scroll to the Dashboard tab, and see if "Exclude my IP" is toggled on.
Clickport uses multiple layers of bot detection to keep analytics clean:
If your own traffic is being caught by bot detection, the most common cause is testing from a cloud server or VPS. Use a regular browser on a residential internet connection instead.
For more details, see Bot Management.
The server validates that the Origin or Referer header of incoming requests matches the domain registered for your site. If the domain in the header does not match (and is not a subdomain of) your registered domain, the event is silently dropped.
This can happen if:
example.com but are testing on staging.example.org (different root domain)Origin header. In this case, Clickport falls back to the Referer header. If both are missing, the request is allowed through.If the Network tab shows a successful /api/event response with a session_id, the data has been recorded. If it is not visible in your dashboard, check these settings.
Make sure your dashboard date range includes today. If you are viewing "Last 7 Days" or a custom range that ends yesterday, today's data will not appear. Switch to "Today" to see the most recent events.
The Realtime section (the green "online" indicator in the top-right) updates every 30 seconds and shows visitors from the last 30 minutes. This is the quickest way to confirm that new events are being recorded. If you see your visit there but not in the main panels, it is likely a date range filter issue.
If you have multiple sites in Clickport, make sure the correct site is selected in the dashboard. The site name appears in the top-left corner next to the Clickport logo.
Clickport automatically handles single-page application (SPA) navigation. It patches history.pushState, history.replaceState, and listens for popstate events. Each client-side navigation triggers a new pageview event.
If SPA navigation is not being tracked:
#/page) is detected via popstate, but some frameworks use non-standard navigation methods.defer attribute ensures the script runs after HTML parsing but before the DOMContentLoaded event, which is correct for most setups.<head> on navigation, the tracker may be removed. Add the script to a persistent layout that is not replaced during navigation.For more details, see SPA Tracking.
The easiest way to check your setup is from the dashboard itself. Open Settings (the gear icon in the top-right), scroll to the Site section, and click "Verify installation". Clickport will visit your site and check for the tracker script.
Quick answers to frequently encountered problems.
Events typically appear in the dashboard within 1-3 seconds. If you are experiencing a longer delay, check the Realtime section first. If Realtime shows your visit but the main panels do not, try refreshing the dashboard or switching the date range to "Today".
If you see inflated pageview counts, check that the tracker script is only included once per page. View your page source (Ctrl+U or Cmd+U) and search for "tracker.js". If it appears more than once, remove the duplicate.
Some WordPress themes and plugins can inject the snippet multiple times if you add it manually and also through a plugin. Pick one method and remove the other.
Scroll depth and session duration are sent as a pageleave event when the visitor navigates away or closes the tab. This event uses fetch with keepalive: true, which works reliably in most modern browsers. If engagement data is consistently missing for a specific browser, the keepalive request may be failing. There is no action needed on your part; the tracker falls back to sendBeacon as a backup.
If you load the Clickport tracker through Google Tag Manager instead of placing the script tag directly in your HTML, make sure the tag fires on "All Pages" and that the data-domain attribute is set correctly. GTM may also cache scripts in ways that delay the initial load.
Clickport does not use cookies and does not require consent under most GDPR implementations. If you have chosen to gate the tracker behind a consent banner, note that the "Verify installation" button will not detect the tracker until consent is given. See Privacy Overview and GDPR Compliance for details on why consent is not legally required.
If you have worked through this guide and your installation is still not working, reach out through the contact page. Include the following details so we can help quickly: