Is Klaviyo an ad platform?

No. Klaviyo is an email, SMS and CRM/CDP platform. The reason teams search for Klaviyo server-side tracking is reliability, not advertising. Klaviyo flows, segments and metrics are driven by behavioural events (Viewed Product, Added to Cart, Started Checkout, Placed Order). When those events depend on the client-side klaviyo.js onsite snippet, ad blockers and Safari ITP cause a meaningful share to never arrive, which means abandoned-cart and post-purchase flows simply do not fire for those people. Datafly Signal delivers the same events server-side to the Klaviyo Events API instead, so the flows fire reliably.

Which Klaviyo API does Signal deliver to?

Signal delivers to Klaviyo’s Events API using the Create Event endpoint with your private API key, server-to-server. Each event carries a human-readable metric name (for example Placed Order), an event properties object, and a profile identified by $email, $phone_number and/or external_id. This is the same API Klaviyo recommends for API-based website activity events, so the events land natively in Klaviyo and are available to flows, segments and metrics exactly as if they had come from the onsite snippet.

Do I still need klaviyo.js on my site?

For event collection, no. Datafly.js collects the behavioural events once as first-party data and Signal delivers them server-side. You can keep klaviyo.js if you use Klaviyo’s onsite forms, popups or the embedded sign-up experiences, since those are rendered by the onsite snippet rather than driven by event tracking. Many teams keep klaviyo.js purely for forms and move all event tracking to Signal for reliability.

How does identity stay consistent between web and server?

Klaviyo identifies a profile by $email, $phone_number or external_id. Signal’s Identity Hub links the pseudonymous first-party session captured by Datafly.js to a known profile the moment an identifier appears (a newsletter sign-up, a logged-in session, a checkout email), then stamps that identifier onto every subsequent event delivered to Klaviyo. So a Viewed Product that happened before sign-up and a Placed Order after it resolve to the same Klaviyo profile, which is what makes browse-abandonment and post-purchase flows accurate.

Does Signal respect Klaviyo’s metric naming?

Yes. Signal’s internal event and property names are snake_case in the GA4 style (add_to_cart, started_checkout), which keeps every downstream destination consistent. The blueprint then maps those to Klaviyo’s real metric names, which are human-readable strings such as Added to Cart and Started Checkout. The mapping lives in the pipeline config, so the names Klaviyo expects are produced exactly, while your internal schema stays clean and vendor-neutral.

Can I send the same events to Klaviyo and to my ad platforms at once?

Yes, and that is the point. Signal collects each first-party event once, then fans it out: Placed Order can go to the Klaviyo Events API as a Placed Order metric and, in the same pipeline run, to Meta Conversions API as a Purchase. You collect once, deliver many, with one consistent identity and one consent decision applied across every destination.

Klaviyo

Klaviyo server-side tracking. Reliable flows, without onsite klaviyo.js.

Klaviyo server-side tracking delivers your e-commerce and behavioural events straight to the Klaviyo Events API server-to-server, so flows, segments and metrics fire for every visitor. Datafly Signal collects each event once as first-party data with a single 5.2KB collector, then delivers it to Klaviyo with consistent identity, instead of depending on the client-side onsite snippet that ad blockers and Safari ITP quietly degrade.

Request a Demo View Platform

Events API

Native delivery

Events land via Klaviyo’s Create Event endpoint, available to flows, segments and metrics exactly like onsite events.

400 days

First-party cookie

Server-set first-party cookies persist identity far beyond the 7-day cap Safari ITP applies to client-side cookies.

One profile

Consistent identity

Pre and post sign-up events resolve to the same Klaviyo profile via $email, $phone_number or external_id.

Collect once

Deliver many

The same first-party event reaches Klaviyo and your ad platforms in a single pipeline run.

Why client-only Klaviyo tracking is unreliable

Klaviyo is not an ad platform. It is your email, SMS and CRM/CDP engine, and its flows depend entirely on events arriving. When those events depend on the browser, a meaningful share never arrive, and the flow simply does not fire for those people.

Ad blockers drop klaviyo.js

The onsite klaviyo.js snippet is a third-party script that content blockers and privacy tools target. Every blocked load is a Viewed Product or Added to Cart that never reaches Klaviyo, so the abandonment flow never starts.

ITP caps the onsite cookie

Safari ITP limits client-side cookies, so the pseudonymous visitor Klaviyo tracked last week looks like a brand-new person today. Browse history fragments, and segmentation built on it gets thinner over time.

Missed events break flows

A cart-abandonment flow only sends if the Added to Cart and the absence of a Placed Order both register. Drop the cart event client-side and the customer gets no reminder. The revenue loss is invisible because the event was simply never recorded.

How Signal delivers to Klaviyo

Collect the behavioural event once as first-party data, resolve a consistent profile identity, then deliver server-to-server to the Klaviyo Events API. No reliance on the browser executing a third-party tag at the moment that matters.

First-party collection

Datafly.js, served from your own first-party subdomain at 5.2KB gzipped, collects the same e-commerce interactions Klaviyo cares about, in GA4-style snake_case.

view_item on product detail pages
add_to_cart from buy buttons
started_checkout on checkout start
purchase on order completion
search and sign_up for intent and welcome flows

Server-side delivery

Signal calls the Klaviyo Events API Create Event endpoint with your private API key, server-to-server. Each event carries a Klaviyo metric name and properties, attached to a resolved profile.

Create Event endpoint, private key never in the browser
Internal snake_case mapped to Klaviyo metric names
Profile keyed on $email, $phone_number or external_id
Same event fans out to ad platforms in one run
Consent decision applied once, before any delivery

One identity across the journey. Signal’s Identity Hub links the pseudonymous first-party session to a known Klaviyo profile the instant an identifier appears, then stamps it onto every later event. A Viewed Product before sign-up and a Placed Order after it resolve to the same profile, which is what makes browse-abandonment and post-purchase flows fire on the right people.

Collect once, deliver everywhere

One first-party collector, one identity, every destination delivered server-to-server.

First-party source

Datafly.js

5.2KB gzipped, your own subdomain

Datafly Signal

Identity resolution + Pipeline transformation + Server-side delivery

Klaviyo Events API

Meta CAPI

GA4

Your CDP

Pipeline as Code

From snake_case event to Klaviyo metric

This pipeline config delivers first-party events to Klaviyo’s Events API. Your internal events stay snake_case, the blueprint maps them to Klaviyo’s real metric names, and the profile identity is resolved server-side before delivery.

Private API key stays server-side, never in the browser
add_to_cart maps to the Klaviyo "Added to Cart" metric
purchase maps to "Placed Order" with a deduplication $event_id
Profile keyed on $email, $phone_number or external_id
Identity resolved by the Identity Hub before the event is sent
Line items reshaped into Klaviyo property objects

klaviyo-events.yamlYAML

# klaviyo-events.yaml — first-party events to the Klaviyo Events API
name: klaviyo_events
integration: klaviyo-events-api

parameters:
  # Private API key stored server-side, never exposed to the browser
  private_api_key: "${KLAVIYO_PRIVATE_API_KEY}"
  endpoint: create_event

global:
  # Profile identity attached to every event. Resolved server-side by the
  # Identity Hub so events before and after sign-in hit the same profile.
  profile:
    "$email":
      source: context.traits.email
      mode: direct
    "$phone_number":
      source: context.traits.phone
      mode: direct
    external_id:
      source: context.traits.customer_id
      mode: direct

events:
  # Internal snake_case event -> Klaviyo human-readable metric name
  add_to_cart:
    metric: "Added to Cart"
    properties:
      "$value":
        source: properties.value
        mode: direct
      ProductName:
        source: properties.item_name
        mode: direct
      ProductID:
        source: properties.item_id
        mode: direct
      Currency:
        source: properties.currency
        mode: direct

  started_checkout:
    metric: "Started Checkout"
    properties:
      "$value":
        source: properties.value
        mode: direct
      ItemCount:
        source: properties.num_items
        mode: direct

  purchase:
    metric: "Placed Order"
    properties:
      "$event_id":
        source: properties.transaction_id
        mode: direct
      "$value":
        source: properties.value
        mode: direct
      Items:
        source: properties.items
        mode: array_map
        fields:
          - source: item_name
            target: ProductName
          - source: item_id
            target: ProductID
          - source: quantity
            target: Quantity

What moves server-side

Klaviyo metric names are human-readable strings, not snake_case, so Signal respects Klaviyo’s real naming on delivery while keeping your internal schema clean. Each internal event maps to the Klaviyo metric that drives the relevant flow.

Internal event	Klaviyo metric	What it drives
view_item	Viewed Product	Browse-abandonment flows and product affinity
add_to_cart	Added to Cart	Cart-abandonment triggers and consideration segments
started_checkout	Started Checkout	Abandoned-checkout flows, the highest-value reminder
purchase	Placed Order	Post-purchase flows, win-back, lifetime value metrics
search	Searched Site	Intent signals for segmentation
sign_up	Subscribed to Newsletter	Welcome series and profile creation

Built for reliable Klaviyo delivery

Native Events API delivery

Events arrive through Klaviyo’s Create Event endpoint and behave exactly like onsite events: visible to flows, segments and metrics with no special handling.

Consistent profile identity

Every event carries $email, $phone_number or external_id, resolved server-side, so pre and post sign-up activity lands on a single Klaviyo profile.

No client-side dependency

Event tracking does not depend on klaviyo.js executing in the browser, so ad blockers and ITP stop quietly degrading your flow triggers.

Flows that actually fire

Abandoned-cart, browse-abandonment and post-purchase flows trigger on the people who actually browsed, not just the ones whose browser allowed the tag.

Collect once, deliver many

The same first-party event reaches Klaviyo and your ad platforms in one pipeline run, with one identity and one consent decision applied across all of them.

Governed identifiers

Email and phone identifiers pass through Signal’s governance layer with consent enforced before any event leaves your single-tenant deployment.

Frequently asked questions

Is Klaviyo an ad platform?: No. Klaviyo is an email, SMS and CRM/CDP platform. The reason teams search for Klaviyo server-side tracking is reliability, not advertising. Klaviyo flows, segments and metrics are driven by behavioural events (Viewed Product, Added to Cart, Started Checkout, Placed Order). When those events depend on the client-side klaviyo.js onsite snippet, ad blockers and Safari ITP cause a meaningful share to never arrive, which means abandoned-cart and post-purchase flows simply do not fire for those people. Datafly Signal delivers the same events server-side to the Klaviyo Events API instead, so the flows fire reliably.
Which Klaviyo API does Signal deliver to?: Signal delivers to Klaviyo’s Events API using the Create Event endpoint with your private API key, server-to-server. Each event carries a human-readable metric name (for example Placed Order), an event properties object, and a profile identified by $email, $phone_number and/or external_id. This is the same API Klaviyo recommends for API-based website activity events, so the events land natively in Klaviyo and are available to flows, segments and metrics exactly as if they had come from the onsite snippet.
Do I still need klaviyo.js on my site?: For event collection, no. Datafly.js collects the behavioural events once as first-party data and Signal delivers them server-side. You can keep klaviyo.js if you use Klaviyo’s onsite forms, popups or the embedded sign-up experiences, since those are rendered by the onsite snippet rather than driven by event tracking. Many teams keep klaviyo.js purely for forms and move all event tracking to Signal for reliability.
How does identity stay consistent between web and server?: Klaviyo identifies a profile by $email, $phone_number or external_id. Signal’s Identity Hub links the pseudonymous first-party session captured by Datafly.js to a known profile the moment an identifier appears (a newsletter sign-up, a logged-in session, a checkout email), then stamps that identifier onto every subsequent event delivered to Klaviyo. So a Viewed Product that happened before sign-up and a Placed Order after it resolve to the same Klaviyo profile, which is what makes browse-abandonment and post-purchase flows accurate.
Does Signal respect Klaviyo’s metric naming?: Yes. Signal’s internal event and property names are snake_case in the GA4 style (add_to_cart, started_checkout), which keeps every downstream destination consistent. The blueprint then maps those to Klaviyo’s real metric names, which are human-readable strings such as Added to Cart and Started Checkout. The mapping lives in the pipeline config, so the names Klaviyo expects are produced exactly, while your internal schema stays clean and vendor-neutral.
Can I send the same events to Klaviyo and to my ad platforms at once?: Yes, and that is the point. Signal collects each first-party event once, then fans it out: Placed Order can go to the Klaviyo Events API as a Placed Order metric and, in the same pipeline run, to Meta Conversions API as a Purchase. You collect once, deliver many, with one consistent identity and one consent decision applied across every destination.

Shopify Server-Side Tracking

Capture storefront events and order webhooks server-side (the most common source for Klaviyo e-commerce metrics).

Meta Conversions API

Fan the same first-party events out to Meta CAPI alongside Klaviyo, collected once.

CDP Integration

Signal as the first-party collection and delivery layer for Klaviyo’s CDP and your wider stack.

PII Handling

How email and phone identifiers are governed before they reach the Klaviyo Events API.

Make your Klaviyo flows fire for everyone

See how Datafly Signal delivers your first-party events to the Klaviyo Events API server-side, with consistent identity, so abandoned-cart and post-purchase flows stop missing the customers who block client-side tags.