Troubleshooting

Quick triage: whose side is it on?

Getting track.yourdomain.com working takes two things: your CNAME record, and our registration of that hostname on the tracking network. Most confusing failures come from one being done and the other not — and from the outside they can look identical.

This one request tells them apart:

https://track.yourdomain.com/health

What you get	Meaning
JSON with "service": "adsidian-prism"	Everything works. Any remaining problem is the snippet, not DNS.
Browser can't find the server / NXDOMAIN	Your side — the CNAME record doesn't exist yet.
A Cloudflare error page (a number like 1016 or 522)	DNS is reaching us; something on our side is incomplete. Escalate.
A certificate / "not secure" warning	Usually still issuing. See the SSL row below.

The short version: once your CNAME is in place and you still see an error page, it is not something you can fix from your DNS panel. Send it to your agency rather than changing records.

Error reference

NXDOMAIN / "CNAME record not detected yet"

Nothing exists at track.yourdomain.com yet.

Yours to fix. Add the CNAME from DNS setup. If you've already added it, give it a few minutes — and check you didn't get the doubled-host typo (track.yourdomain.com.yourdomain.com), which some providers create when you type the full hostname into a field that already appends your domain.

Cloudflare error 1016

The hostname resolves to us, but nothing is behind it yet.

Check your record first, then escalate. If dig CNAME track.yourdomain.com shows prism.ad-prism.xyz (or prism.binarybloom.dev on an install set up before August 2026 — that's correct, not stale), your half is done and this is ours — the hostname hasn't finished being registered on our side. Escalate.

A common, harmless version of this: you added the CNAME after your agency enabled Prism. Our first validation ran before your record existed and doesn't always retry on its own. Your agency clears it in one click from the dashboard — no DNS change needed, so please don't start editing records.

Cloudflare error 522

The hostname is fully set up and certificated, but requests aren't reaching Prism.

Escalate — there is nothing to do on your side. Your DNS is correct by definition if you're seeing this.

One exception: immediately after your agency fixes a setup, brief 522s are normal. The fix propagates across the network over a minute or two, and during that window some requests succeed while others fail — you may see prism.js load fine while another request errors. If it's still failing after ~5 minutes, escalate.

Cloudflare error 530

Usually a wrapper around 1016 — read the four-digit code in the page body and treat it as that error.

Certificate / SSL warning on the tracking subdomain

Usually yours. Two causes:

• Cloudflare users: the record is proxied (orange cloud). It must be DNS only (grey cloud) — a proxied record prevents the certificate from being issued.
• Still issuing. Certificates are normally ready within minutes of DNS propagating. If it's been over an hour with a DNS-only record, escalate.

404 on prism.js

The hostname works; the client ID in the snippet URL is wrong.

Escalate — the snippet is generated by your agency. Don't hand-edit the ID; ask for the correct tag.

CORS error on the events request

Almost never a real CORS problem. When the tracking hostname returns an error page, the browser's preflight fails and it reports that as CORS. Check /health first — if it returns an error code, fix that and the CORS error disappears with it.

If /health returns proper JSON and you still see CORS errors, that's worth escalating.

DNS never verifies

• Check the record exists: dig CNAME track.yourdomain.com (or an online DNS checker) should show prism.ad-prism.xyz. On an install set up before August 2026, prism.binarybloom.dev is the expected, fully-supported target — don't treat it as a misconfiguration.
• Cloudflare users: the record must be DNS only (grey cloud). Proxied records break certificate issuance for the tracking hostname.
• Typos: the host is track (not track.yourdomain.com.yourdomain.com — some providers append the domain automatically).
• Propagation: allow up to an hour; the dashboard re-checks automatically.

DNS verified, but no events ("Snippet installed" stays amber)

• Is the snippet actually on the page? View source and search for prism.js. On WordPress, check the page wasn't cached before the snippet was added (purge caches).
• Check the browser console for errors on https://track.yourdomain.com/prism.js — a 404 means the client ID in the snippet URL is wrong; a certificate error means DNS/SSL isn't done issuing yet.
• Rocket Loader (Cloudflare): make sure the script tag keeps data-cfasync="false", otherwise Rocket Loader defers it and click IDs on the landing URL can be missed.
• Content-Security-Policy: if the site sends a CSP, allow https://track.yourdomain.com in script-src and connect-src.
• Consent managers: if the snippet is gated behind consent, no events fire until consent is given — test with consent accepted.

Events arrive, but Meta shows fewer (delivery gap)

The client page's Event delivery card compares what Prism sent against what Meta reports. Common causes for a gap:

• Restricted ad category — Meta silently drops standard event names (Lead, Schedule, …) for special-category advertisers. Fix: remap to custom event names in the dashboard. Prism's diagnostics flag this case.
• Invalid or expired access token — surfaced as an Integration Health error; regenerate the token in Events Manager and reconnect.
• Deduplication — if the site also runs a Meta pixel, deduped events are expected and not a problem.

Meta shows more conversions than the dashboard (inflated or fake leads)

The delivery gap can run the other way: Ads Manager reports leads or conversions that Prism never saw. That's almost always a legacy browser pixel still installed on the site, and it has two failure modes:

• Double counting — the old pixel's events don't share Prism's deduplication IDs, so Meta counts both. PageView roughly doubles; so does anything both sides fire.
• Hidden derived events — rules saved through Meta's Event Setup Tool (or its "Track events automatically without code" feature) live inside the pixel's config, not on the site. They can turn plain page visits or button clicks into Lead-class events with nothing visible in the page source — and they don't always appear in the Event Setup Tool UI afterward, even to users with full pixel access.

How to confirm:

1. Events Manager → the dataset → click the suspect event → View details → Connection method. Real Prism events are Server (labeled adsidian_prism); anything Browser comes from a pixel install on the site.
2. View the site's page source and search for fbevents.js or fbq( — that's the install to remove.
3. Definitive rule check: open https://connect.facebook.net/signals/config/<PIXEL_ID> in a browser and search the text for estRules. An entry with "derived_event_name" and "rule_status":"ACTIVE" is a live browser-side rule, whether or not any UI shows it.

Fix: remove the pixel base code from the site (see Meta CAPI → Remove existing pixel installs first). Browser-side rules die with the pixel — no Events Manager archaeology required. Expect Ads Manager conversion counts to drop afterward; that's the inflation leaving, not tracking breaking.

Conversions missing in Google Ads

• Auto-tagging off or a redirect stripping gclid from the landing URL — check that ad clicks land with ?gclid=... present.
• Event not mapped — only events mapped to a conversion action in the wizard are uploaded.
• Reporting lag — Google attributes uploaded conversions to the click date, and reporting can lag a few hours.

Testing without polluting data

Append ?prism_test=TEST12345 (your code from Meta Events Manager → Test events) to any page URL — every event from that browser tab routes to Meta's Test Events instead of the live dataset. See Verifying your install.

When to escalate

Escalate to your agency — don't keep changing DNS — as soon as any of these is true:

• dig CNAME track.yourdomain.com returns the right target and you still get an error page.
• You see a 522, or a 1016 that persists more than a few minutes after your CNAME went live.
• The certificate hasn't issued after an hour with a DNS-only record.
• prism.js returns 404.
• /health returns proper JSON but events still never arrive.

Editing DNS past this point tends to make things worse: the record was right, and changing it restarts validation from the beginning.

What to include

A screenshot rarely carries enough. Send:

1. The exact URL you tried and the error code (the four-digit number in the page body, not just "522").
2. The output of dig CNAME track.yourdomain.com — or a link to an online DNS lookup for that hostname.
3. What https://track.yourdomain.com/health returns.
4. Roughly when the CNAME was added, and whether anything changed just before it broke.

Item 2 is the one that saves the most time: it settles immediately whether the problem is on your side or ours.

What your agency can do

Most of the errors above are cleared from the Adsidian dashboard without touching your DNS:

• Re-run setup on the Prism setup card re-registers the tracking hostname and re-triggers validation — this resolves the majority of 1016 and 522 cases.
• Integration Health → Run checks runs the full diagnostic suite (credentials, dataset reachability, ad-category restrictions) with specific remediation links.