Content security policy

If your site sends a Content-Security-Policy header, allow your tracking domain in three directives. Use the host from your own snippet on the Pixels page, not the example below.

script-src  'self' https://10.vidstats.top;
connect-src 'self' https://10.vidstats.top;
img-src     'self' https://10.vidstats.top;

Directive	Why
script-src	Loads p.js, and pv.js, which is fetched separately the first time a video appears on a page
connect-src	Sends the beacon, over fetch or sendBeacon. This is the one that carries your data
img-src	Only for browsers with no fetch, and for the no-script image pixel. Safe to omit if you use neither

Everything loads from that one host. There is no CDN and no third-party origin to allow.

Blocking connect-src does not silently fall back to an image. The beacon is held and retried on the next page load instead, so a wrong connect-src looks like missing data, not partial data.

Changing your tracking domain changes the host your snippet uses, so update the policy at the same time or data stops arriving.

Inline webstats() calls

The content call in the video snippet is an inline type="module" script, so a policy with script-src 'self' and no allowance for inline code blocks it. Add a nonce and put the same nonce in your policy:

<script type="module" nonce="RANDOM_PER_REQUEST">
  webstats('content', { type: 'movie', ids: { tmdb: '278' } });
</script>

Or move the call into a file you already serve. Calls from your own app or framework files are already covered by whatever allows those files. See webstats() commands.

Verify

Load a page and open your browser console. A CSP problem names the directive that blocked the request. If the console is clean and data still does not arrive, the cause is elsewhere. See Troubleshooting.