Appearance
Meta (Facebook) CAPI
Prism delivers events to Meta through the Conversions API — server to server. No Meta pixel is required on the site: Prism generates the _fbp browser ID itself, so match quality does not depend on Meta's script being present.
Prism sends a deduplication ID with every event, but Meta can only deduplicate when the browser event carries the same ID — which a separately installed pixel never does. In practice that means a legacy pixel running alongside Prism double-counts, and should be removed (next section).
Looking for campaign management?
This page covers conversion tracking only. To connect a Meta ad account for importing and managing campaigns, see Meta Ads onboarding.
Remove existing pixel installs first
Most sites Prism lands on already run a Meta pixel — hardcoded in the header, in a WordPress plugin, or in a Tag Manager container. Once Prism CAPI is connected, remove the old pixel. Running both is not a harmless overlap:
- Double counting. The legacy pixel's events don't share Prism's deduplication IDs, so Meta counts both copies — PageView totals roughly double, and any event both sides fire is inflated.
- Hidden browser-side rules. Meta's Event Setup Tool and "Track events automatically without code" store rules inside the pixel's config, not on your site. These derive events client-side with no code anywhere you can read — we've seen a live rule that logged every homepage visit as a
Lead, inflating lead counts ~5× and training the campaign to optimize for homepage traffic. Rules like this can persist even when nobody can find them in the Events Manager UI; they die with the pixel. - Unreadable diagnostics. With two sources feeding one dataset, every count in Events Manager is a browser/server blend, and no number can be trusted at a glance.
Removing the pixel does not hurt match quality: Prism mints the _fbp first-party ID itself and delivers full customer information server-side.
What to remove: the "Meta Pixel Code" block — fbq('init', …), the connect.facebook.net/en_US/fbevents.js loader, and the <noscript> facebook.com/tr image. Check every place pixels hide: hardcoded <head> code, the official Meta pixel WordPress plugin, header-script plugins (WPCode, Insert Headers and Footers), theme options, Elementor/page-builder integrations, and Custom HTML tags in Google Tag Manager.
How to verify it's gone: view the page source and search for fbevents.js and fbq( (should be absent), then watch Events Manager — every event's connection method should read Server only, and Prism's events identify themselves as adsidian_prism.
Keeping both anyway?
Only sensible when your site deliberately fires browser events with the same event IDs Prism sends — a custom integration, not a pasted base-code install. If you can't say for certain that's your setup, it isn't; remove the pixel.
What you need
If your agency has already connected Meta in Settings (see Meta Ads onboarding): nothing. The wizard lists the pixels on the client's ad account — pick one and run the checks. No token to paste.
Otherwise, two values, both from Meta Events Manager:
- Pixel / Dataset ID — Events Manager → your dataset → Settings.
- Conversions API access token — same Settings page → Generate access token.
That's it — no app review, no system-user setup. The token only grants event delivery for that one dataset.
Who can generate the token?
Generating a Conversions API access token requires full control of the dataset in the Meta Business portfolio that owns it. Business portfolio admins have this automatically; anyone else must be granted full control on the data source (Business settings → Data sources → Datasets → select the dataset → People). If the Generate access token link doesn't appear on the dataset's Settings page, you don't have full control — ask a business admin to either grant it or generate the token for you. Pixels not owned by a business portfolio (e.g. created under a personal ad account) can't generate a token until they're connected to one.
Connecting
In the Adsidian dashboard, open the client → Connect Meta (or Reconfigure Meta). The wizard:
- Takes the pixel (picked from your agency connection, or entered manually with a token) and your landing domain.
- Runs live preflight checks — token validity, dataset reachability, domain verification, category restrictions, AEM priority.
- Fires a test event and confirms Meta received it (visible in Events Manager → Test events).
At client creation (tracking-only clients)
When adding a client with the Prism client only toggle, the Add Client dialog includes an optional Meta Dataset / Pixel ID field, so Meta is connected the moment tracking is provisioned:
- Agency Meta connection set up (Settings → Meta): the dataset ID alone is enough — events deliver through the agency connection, no token to paste.
- No agency connection: entering a dataset ID reveals an access-token field. Paste a dataset access token (generated as described above) and events deliver with it — no agency-level Meta integration required.
A dataset ID saved without any token (neither per-client nor agency) is stored but inactive: Prism keeps tracking events, and forwarding to Meta starts as soon as a token is available. The client page shows Meta as not connected until then, and the full wizard — with preflight checks and a test event — remains available there via Connect Meta.
Event mapping
Meta optimizes on standard event names (Lead, Purchase, Schedule, …). Your on-site event names are mapped to Meta names per client — e.g. site event AppointmentRequest → Meta Schedule. Events without a mapping pass through under their own name.
Restricted categories
For advertisers Meta classifies into special ad categories (health, housing, credit, employment, politics), Meta silently drops standard events like Lead — they're accepted with a 200 but never appear in the dataset. Prism's diagnostics detect this; the fix is mapping your events to custom (non-standard) names, which your agency configures in the dashboard.
Ongoing health
Prism runs hourly automated checks per client (token validity/scope, dataset reachability, category restrictions, AEM setup) and reconciles daily how many events Prism sent vs. how many Meta reports receiving — surfaced on the client page as Integration Health and Event delivery cards, plus Event Match Quality when available.