fix(analytics): load meta pixel only on keploy.io

[dhananjay6561]

• Meta pixel: the base snippet in docusaurus.config.js now runs only on keploy.io / www.keploy.io. It was injected on every host, so localhost, staging and Vercel preview builds were all sending events into the production pixel.
• src/metaPixelRouteTracker.js already checks for window.fbq, so route-change PageViews are skipped too on other hosts.

Test: on keploy.io/docs, a facebook.com/tr request shows in the Network tab. On localhost or a preview URL, no fbevents.js / facebook.com/tr requests.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[amaan-bhati]

@dhananjay6561, this mirrors the landing fix (keploy/landing#306) nicely and keeps both sites consistent.

The guard wraps the full base snippet (loader + init + PageView), and src/metaPixelRouteTracker.js already checks typeof window.fbq === "function", so SPA PageViews are skipped on other hosts with no extra change.

I verified this before merging by taking the exact snippet from this PR's docusaurus.config.js, swapping it into the live keploy.io/docs/ HTML, and loading it on both hosts in Chrome (Playwright). All facebook.com/tr requests were intercepted and answered locally, so nothing reached the real pixel.

Host	typeof fbq	Meta requests on load	After SPA navigation	Page errors
keploy.io	function	fbevents.js + GET /tr/ (PageView)	1 × POST /tr/	none
localhost	undefined	0	0	none

So the pixel keeps working on keploy.io (including route-change PageViews), and is fully silent everywhere else. The docs CSP is report-only with 'unsafe-inline', so changing the inline script has no CSP impact, and docs.keploy.io 301s to keploy.io/docs, so no real host is missed.

Small non-blocking notes:

• The <noscript> pixel still fires on any host for no-JS clients. That's negligible and can't be host-gated, so fine to leave.
• For the future: the docs report-only CSP has form-action 'self', the same directive that blocked the pixel's form POST on landing. Not an issue while it's report-only, but if it's ever enforced it'll need https://www.facebook.com in form-action like #306.

Before merging, could you add these findings (the table and testing approach) to the PR description? It'll be handy for future reference, for anyone else or for you later, when revisiting why the pixel is host-gated.

Approving this pr!

[nehagup]

Looks good to merge. It uses the same hostname gate and escaping as keploy/landing#306, and src/metaPixelRouteTracker.js already checks for window.fbq, so route-change PageViews are skipped on other hosts.

Nits (non-blocking):

• The live keploy.io/docs sends Content-Security-Policy-Report-Only, so nothing is blocked. However, that policy doesn't allow https://www.facebook.com in form-action or frame-src, so it will report the same violations landing#306 fixed. Worth a follow-up if anyone reads those reports.
• The <noscript> image fallback isn't gated by hostname, so a non-production host with JavaScript disabled still sends a PageView. Negligible in practice.