Snapchat Conversions API

Snapchat server-side tracking via the Conversions API. Better match rates. Zero browser overhead.

Snapchat server-side tracking moves your conversion events out of the browser and into the Snapchat Conversions API, delivered server-to-server from your own cloud. Datafly Signal handles this automatically: server-set _scid, captured ScClickId, and direct delivery to the Conversions API with zero Snap Pixel JavaScript in the browser.

Request a DemoView Features

Snap Pixel

Removed entirely

The browser tag that sets _scid, captures the click id, and fires events is replaced by server-side delivery.

20-40%

Blocked by ad blockers

Users with ad blockers never trigger Snap Pixel events. Server-side delivery closes that attribution gap.

7 days

ITP cookie limit

Safari caps client-side _scid cookies to 7 days, breaking attribution for returning visitors.

5.2KB

Datafly.js collector

The only JavaScript in the browser. No Snap Pixel, no third-party tracking scripts.

Problems with the Snap Pixel

The Snap Pixel has the same architectural limitations as every other client-side tracking tag. These are not configuration problems, they are fundamental constraints of browser-based JavaScript.

Extra JavaScript on every page

The Snap Pixel loads vendor JavaScript that competes with your content for bandwidth. On mobile connections this directly impacts page load times, Core Web Vitals, and conversion rates.

Ad blockers block it

A large share of users run ad blockers that block Snapchat’s tracking domains by default. These users never register a single Pixel event, creating a permanent blind spot in your attribution data.

ITP-limited cookies

Safari’s Intelligent Tracking Prevention caps client-side JavaScript cookies at 7 days. A Pixel-set _scid expires weekly, breaking attribution windows and fragmenting Snapchat identity.

Consent timing issues

The Snap Pixel fires before consent banners resolve, or consent is revoked after events are already in flight. Server-side delivery gives you full control over when and whether events are sent.

How Signal delivers Snapchat events

Datafly Signal replaces the Snap Pixel with server-to-server delivery via the Snapchat Conversions API. Better identity matching, zero browser overhead.

Server-set _scid

The _scid identifier (and its _scid_r companion) is set and read server-side as a first-party cookie with 400-day expiry, then sent to the Conversions API as sc_cookie1. Fully exempt from Safari ITP restrictions.

Captured ScClickId from URL

When a user arrives from a Snapchat ad, the ScCid query parameter is automatically captured and stored as a 400-day server-set cookie, then sent in the sc_click_id field for attribution.

Server-to-server delivery

Events are delivered directly to tr.snapchat.com via the Conversions API. A purpose-built delivery worker handles retries with exponential backoff on failure.

SHA-256 enhanced matching

Email and phone are normalised and SHA-256 hashed into hashed_email and hashed_phone_number before transmission, improving match rates without sending raw PII to Snapchat.

ITP-exempt 400-day cookies

All identity signals, _scid and ScClickId included, are set via Set-Cookie headers from your true first-party subdomain. Safari ITP does not restrict server-set cookies.

Zero Snap Pixel JavaScript

No Snap Pixel, no third-party scripts. The only JavaScript in the browser is your 5.2KB Datafly.js collector, served from your own single-tenant deployment.

What moves server-side

Every job the Snap Pixel does in the browser is taken over by Signal’s server-side pipeline. The result is the same Snapchat identity matching with none of the client-side fragility.

Identifier generation

Before

Snap Pixel writes _scid in JavaScript

With Signal

Gateway sets _scid as a server-set first-party cookie, sent as sc_cookie1

Click capture

Before

Pixel reads ScCid from the landing URL

With Signal

Datafly.js captures ScCid once, the gateway persists ScClickId for 400 days

PII hashing

Before

Hashing relies on correct browser-side setup

With Signal

normalised_sha256 transform hashes email and phone before they leave your server

Event delivery

Before

Browser POSTs to Snapchat, blockable and ITP-limited

With Signal

Delivery worker POSTs to tr.snapchat.com with retry and validation

Deduplication

Before

Pixel and any server events can double-count

With Signal

Deterministic event_id emitted on every event for Snapchat-side dedup

Consent gating

Before

Pixel may fire before consent resolves

With Signal

Events held and gated server-side until consent state is known

Identity signals sent on every event

Datafly Signal sends the complete set of identity parameters to the Snapchat Conversions API on every event. More signals means higher match rates and better ad optimisation. Snapchat recommends sending at least one of sc_click_id, sc_cookie1, or external_id, and Signal sends all you have.

sc_cookie1
Source: _scid cookie
Expiry: 400 days
Description: Snapchat's pseudonymous browser identifier (also called uuid_c1). Set and read as a server-set first-party cookie. Recommended by Snapchat to raise match rates.
sc_click_id
Source: ScCid URL param
Expiry: 400 days
Description: The Snapchat Click ID (ScClickId), captured from the ScCid query parameter when a user arrives from a Snapchat ad. Persisted for full-cycle attribution.
external_id
Source: Your user ID
Expiry: Session
Description: Your internal user identifier, passed directly. Enables cross-device matching for logged-in users.
hashed_email
Source: traits.email
Expiry: SHA-256
Description: Email address, normalised (trimmed, lowercased) and SHA-256 hashed before transmission.
hashed_phone_number
Source: traits.phone
Expiry: SHA-256
Description: Phone number, normalised to E.164 and SHA-256 hashed before transmission.

All PII is automatically SHA-256 hashed as required by Snapchat. Email and phone data are normalised and hashed into hashed_email and hashed_phone_number before leaving your server. Raw PII never reaches the Snapchat API.

Pipeline as Code

Purpose-built Snapchat event transformation

This pipeline config transforms an order_completed track event into a Snapchat Conversions API PURCHASE event with event_conversion_type: WEB. User identity is enriched from cookies, PII is automatically hashed, and purchase data is mapped to Snapchat’s custom_data format.

  • event_name PURCHASE with event_conversion_type and action_source set to WEB
  • sc_cookie1 from _scid and sc_click_id from the captured ScClickId
  • normalised_sha256 hashing for hashed_email and hashed_phone_number
  • client_ip_address and client_user_agent forwarded for matching
  • Output validation against Snapchat’s Conversions API schema before delivery
snapchat-purchase.yamlYAML
# snapchat-purchase.yaml — Purchase event to Snapchat Conversions API
name: snapchat_purchase
integration: snapchat-conversions-api
trigger:
  event: track
  conditions:
    - field: event
      operator: equals
      value: order_completed

transform:
  static:
    - target: event_name
      value: PURCHASE
    - target: event_conversion_type
      value: WEB
    - target: action_source
      value: WEB

  mapping:
    - source: timestamp
      target: event_time
      transform: unix_seconds
    - source: context.page.url
      target: event_source_url

  # User context
  context:
    - source: context.ip
      target: user_data.client_ip_address
    - source: context.user_agent
      target: user_data.client_user_agent

  # User identity — auto-hashed PII (SHA-256)
  user_data:
    - source: traits.email
      target: user_data.hashed_email
      transform: normalised_sha256
    - source: traits.phone
      target: user_data.hashed_phone_number
      transform: normalised_sha256

  enrichments:
    - type: vendor_id
      vendor: snapchat
      cookies: [_scid]
      target: user_data.sc_cookie1
    - type: click_id
      param: ScCid
      target: user_data.sc_click_id
    - type: identity
      source: user_id
      target: user_data.external_id

  # Properties — purchase details
  properties:
    - source: properties.products
      target: custom_data.item_ids
      transform: pluck
      field: product_id
    - source: properties.revenue
      target: custom_data.value
    - source: properties.currency
      target: custom_data.currency
      default: USD

output:
  format: snapchat_conversions_api
  endpoint: https://tr.snapchat.com/v3/{pixel_id}/events
  auth: access_token
  validate: true

Supported Snapchat events

Standard Snapchat Conversions API event types are supported out of the box. Each event is delivered server-to-server with full identity enrichment.

PAGE_VIEW

When a user views any page on your site

VIEW_CONTENT

When a user views a product or content page

ADD_CART

When a user adds an item to their shopping cart

START_CHECKOUT

When a user begins the checkout process

PURCHASE

When a user completes a purchase transaction

ADD_BILLING

When a user adds billing or payment details

SIGN_UP

When a user registers a new account

SUBSCRIBE

When a user subscribes to a plan or newsletter

SEARCH

When a user searches on your site

Frequently asked questions

What is Snapchat server-side tracking and how does the Conversions API work?
Snapchat server-side tracking sends conversion events to Snapchat from your own server rather than from the browser. The Snapchat Conversions API (CAPI) accepts those events over HTTPS at tr.snapchat.com, matched to Snapchat users via hashed identifiers and the sc_click_id captured from the ad click. Datafly Signal runs this entirely server-to-server, so events are no longer dependent on the Snap Pixel JavaScript loading, surviving ad blockers, or Safari ITP. The browser only carries the 5.2KB Datafly.js collector.
How does Datafly Signal capture ScClickId for Snapchat attribution?
When a user clicks or swipes up on a Snapchat ad, the destination URL is appended with the ScCid query parameter, whose value is the Snapchat Click ID (ScClickId). Datafly.js extracts it on landing and the gateway stores it in a 400-day server-set first-party cookie alongside the _scid value. Conversions days or weeks later are sent to the Conversions API in the sc_click_id field, so attribution holds across the full buying cycle regardless of Safari ITP’s 7-day cap on browser-set cookies.
What is _scid and how does Signal handle it server-side?
The _scid cookie (with its _scid_r companion) is Snapchat’s pseudonymous browser identifier, normally written by the Snap Pixel. In the Conversions API it is sent as sc_cookie1 (also referred to as uuid_c1) to raise match rates. Datafly’s gateway sets and reads _scid as a server-set first-party cookie on your own subdomain with a 400-day expiry, then forwards the value on every event. From Snapchat’s perspective the identifier is the same one the Pixel would have used, so server-side events match the same identity record.
Do I need to keep the Snap Pixel on the page?
No. The Snap Pixel exists to set _scid, capture the click id, and fire events. All three are handled server-side by Datafly Signal. Removing the Pixel eliminates Snapchat JavaScript from every page, removes a category of ad blocker target, and gives you cleaner attribution because the underlying cookies persist for 400 days from a true first-party subdomain instead of being capped at 7 days under Safari ITP.
How does Snapchat Conversions API delivery improve match rates?
Match rate depends on how many strong identifiers reach Snapchat per event. Server-side delivery recovers events that ad blockers and ITP would otherwise hide, and every event ships with the complete identifier set: sc_cookie1 (the _scid value), sc_click_id, hashed_email, hashed_phone_number, plus client IP and user agent. Snapchat recommends sending at least one of sc_click_id, sc_cookie1, or external_id, and Signal sends all the identifiers you have available rather than only what the Pixel managed to write before it was blocked.
Can I deduplicate against an existing Snap Pixel setup during migration?
Yes. Datafly Signal generates a deterministic event_id for every event and emits it via the Conversions API. If the Snap Pixel is still on the page during migration, both client-side and server-side events arrive at Snapchat with the same event_id and Snapchat deduplicates them. You can run both in parallel for as long as you need before fully removing the Pixel.

Related

TikTok Events API

Same server-side pattern for TikTok with server-set _ttp and captured ttclid.

Meta Conversions API

Server-side Meta CAPI with _fbp generation and EMQ optimisation.

PII Handling

How email and phone are normalised and SHA-256 hashed before they leave your server.

Safari ITP Recovery

400-day first-party cookies for _scid and ScClickId persistence across the buying cycle.

Maximise Snapchat ROAS with server-side tracking

See how Datafly Signal delivers Snapchat Conversions API events with full identity matching, zero browser overhead, and ITP-exempt 400-day first-party cookies. Better data, better optimisation.

Request a DemoView Platform