Snapchat Conversions API: _scid, ScClickId and server-side setup

Snapchat’s Conversions API (CAPI) accepts conversion events from your server over HTTPS, so delivery no longer depends on the Snap Pixel loading in the browser. As with every platform’s server API, the request is the easy part. What determines whether Snapchat can attribute the conversion is the identifiers that come with it.

The identifiers Snapchat uses

`_scid` is Snapchat’s pseudonymous browser identifier (with a companion _scid_r), normally written by the Snap Pixel. In the Conversions API it is sent as sc_cookie1 (also called uuid_c1) and raises match rates.

ScClickId is the click ID. When someone taps or swipes up on a Snapchat ad, the destination URL is appended with the ScCid query parameter, whose value is the Snapchat click ID. In the Conversions API it is sent as sc_click_id and ties the conversion to the ad.

Hashed customer data: email and phone number, normalised and hashed with SHA-256.

IP address and user agent of the visitor, as additional match signals.

Snapchat recommends sending at least one of sc_click_id, sc_cookie1 or external_id with every event. Sending everything you have matches best.

What breaks in the browser

The Snap Pixel sets _scid with JavaScript and captures the click ID in the browser. Ad blockers often stop the Pixel, and Safari deletes JavaScript cookies after 7 days without a return visit. A swipe-up on Friday and a purchase the following weekend often arrives at Snapchat with neither identifier.

How Datafly Signal keeps them

• Datafly.js reads ScCid from the landing URL, and the gateway stores the click ID in a server-set first-party cookie on your domain for up to 400 days.
• _scid is set and read as a server-set first-party cookie on your own domain, then forwarded on every event. To Snapchat it is the same identifier the Pixel would have set.
• Email and phone are hashed inside your infrastructure before delivery.
• Every event carries the visitor’s IP address and user agent.

Deduplicating during migration

Run the Pixel and the Conversions API together while you migrate. Snapchat deduplicates when a browser event and a server event share the same event_id. Datafly Signal generates a deterministic event_id for every event, so both copies carry the same ID and Snapchat keeps one. Compare the numbers in Snapchat’s Events Manager over a few weeks, then remove the Pixel.

Do you still need the Snap Pixel?

For measurement, no. The Pixel exists to set _scid, capture the click ID and fire events, and all three move to the server. Removing it takes Snapchat’s JavaScript off every page and gives you identifiers that last 400 days instead of 7.

Checklist

• Capture the ScCid click ID on landing.
• Set _scid from your server so Safari does not cap it at 7 days.
• Send sc_click_id, sc_cookie1 and hashed email and phone together where you have them.
• Use one event_id per event across Pixel and server during migration.

See how Snapchat server-side tracking works in Datafly Signal, or read the Snapchat integration docs.