Klaviyo server-side tracking: keep your flows firing when klaviyo.js is blocked

Klaviyo is not an ad platform, so it is easy to assume tracking problems do not apply to it. They do, and they cost revenue directly. Klaviyo flows (abandoned cart, browse abandonment, post-purchase) are triggered by behavioural events: Viewed Product, Added to Cart, Started Checkout, Placed Order. If an event never reaches Klaviyo, the flow never starts and the email is never sent.

Where the events go missing

On most sites those events are sent by klaviyo.js, the onsite snippet. That makes them subject to the same problems as any browser tag:

• Ad blockers frequently block the snippet, so events from those visitors never arrive.
• Safari’s 7-day limit on JavaScript cookies means a returning visitor may no longer be recognised, so their activity is not tied to their profile.
• Identity gaps. A visitor browses anonymously, signs up a week later, and the earlier browsing is never attached to the profile that could have triggered a browse-abandonment email.

None of this produces an error. Flows simply fire less often than they should.

Sending the events from the server

Klaviyo’s Events API (the Create Event endpoint) accepts the same events from a server using your private API key. Each event carries a metric name such as Placed Order, an event properties object, and a profile identified by $email, $phone_number and/or external_id. Events arrive natively and are available to flows, segments and metrics exactly as if the snippet had sent them.

With Datafly Signal, Datafly.js collects each behavioural event once as first-party data on your own domain, and the server delivers it to the Klaviyo Events API.

Keeping identity joined up

Klaviyo needs to know who an event belongs to. Datafly Signal’s Identity Hub links the anonymous first-party visitor to a known profile the moment an identifier appears: a newsletter sign-up, a login, or an email at checkout. From then on, that identifier is attached to every event sent to Klaviyo. A Viewed Product before sign-up and a Placed Order after it resolve to the same Klaviyo profile, which is exactly what browse-abandonment and replenishment flows need.

Metric names

Internally, Datafly Signal uses consistent snake_case event names (add_to_cart, started_checkout) across every destination. The Klaviyo blueprint maps them to Klaviyo’s human-readable metric names (Added to Cart, Started Checkout), so existing flows keep working without renaming anything.

Do you still need klaviyo.js?

For event tracking, no. Many teams keep the snippet only for Klaviyo’s onsite forms and pop-ups, which it renders, and move all event tracking to the server for reliability.

One event, every destination

The same Placed Order can go to Klaviyo as a Placed Order metric and, in the same pipeline, to Meta’s Conversions API as a Purchase and to GA4 as a purchase. You collect once, deliver everywhere, with one identity and one consent decision across all of them.

Checklist

• List the flows that matter most and the metrics that trigger them.
• Make sure each metric is sent server-side with a profile identifier.
• Capture an identifier as early as possible (sign-up, login, checkout email).
• Keep the onsite snippet only if you use Klaviyo forms.

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