Setup card: Omnisend to Klaviyo: mapping events and triggers

Last updated: October 30, 2026

Direct answer: Sticky Digital recommends running an Omnisend to Klaviyo migration trigger by trigger. List every Omnisend event, map it to the Klaviyo metric, list, segment, or date property that fires at the same moment, and confirm the data each message needs before you rebuild a single email. The stakes are concrete. Across the 60 accounts in our portfolio that attribute more than $1M a year to email and SMS, flows produced roughly 33% to 47% of that revenue for the middle half of accounts, with a median of 42% (Hiro, twelve months to October 30, 2026). A flow that never fires takes a piece of that share with it.

What we check first in an Omnisend to Klaviyo migration

Omnisend groups its automations by preset: Welcome, Cart and Checkout Abandonment, Browse Abandonment, Post-Purchase, Transactional, and Special Occasions. Klaviyo does not think in presets at all. A Klaviyo flow starts from a metric, a list, a segment, a date property, a price drop, or a low inventory alert.

That difference is easy to miss because the flow names look the same on both sides. "Abandoned Cart" exists in both platforms. The event underneath it does not behave the same way.

So the workflow name is the interface, and the trigger is the contract. A migration that matches on names copies the interface and loses the contract. At the revenue share above, that is a revenue problem, not a tidiness problem.

Omnisend to Klaviyo trigger map at a glance

The table covers every event Omnisend lists as a recommended event, plus its built-in and segment triggers. The sections after it explain where each family breaks.

How does the Omnisend welcome trigger map to Klaviyo?

Omnisend starts its welcome automation when a contact subscribes through a signup form, and only subscribed contacts qualify. Klaviyo's equivalent is the list trigger, which queues every new subscriber added to a list.

Two details matter. First, list and segment flows in Klaviyo default to no re-entry, so a person who joins the list a second time does not get a second welcome series unless you change the setting. Second, the trigger is "added to list," and an import is a lot of people being added to a list at once. Keep the welcome flow in draft until the contact import and consent mapping are finished, then switch it live.

What replaces Omnisend cart and checkout abandonment in Klaviyo?

Omnisend splits this into two workflows and tells merchants to run both: Abandoned Cart for people who add items but never start checkout, and Abandoned Checkout for people who start checkout and stop. Klaviyo builds the checkout version on the Checkout Started metric, with a time delay and a Placed Order filter to drop anyone who buys. The cart version runs separately on Added to Cart.

The name is the first trap. On the Shopify integration the metric reads Checkout Started, while Klaviyo's guide for custom integrations calls it Started Checkout. Open Analytics, then Metrics, and pick the one that exists in your account.

The second trap is the double send. Shopify has its own abandoned checkout emails, and Klaviyo's documentation tells you to turn them off so customers do not get both.

The third is consent. Omnisend lets its abandonment automations run for non-subscribed contacts, and Klaviyo will send an abandoned cart email to a profile that never subscribed, though its own guidance says to use caution. Decide the policy on purpose, and add a consent filter to the flow if you want it stricter than Omnisend was. That is a compliance call for your counsel, not a settings default.

Why browse abandonment does not map one for one

This is the cleanest example of a name hiding a difference. Omnisend's Browse Abandonment preset triggers on "viewed page," and its own documentation says the trigger does not capture which products the shopper looked at. Its separate Product Abandonment workflow uses the viewed product event.

Klaviyo's browse abandonment flow triggers on Viewed Product, which carries the product, so the email can show what the shopper actually viewed. That is an upgrade in message quality, but it also means a page-view flow from Omnisend turns into a product-level flow, with different volume and different copy needs.

Two cautions. Klaviyo can record a Shopify-branded Viewed Product through the Shopify pixel and a separate one through its own onsite tracking, and its help center says to check the source when two metrics share a name. And Klaviyo notes that, depending on Shopify Customer Privacy settings, onsite events may not be tracked for visitors in the EU, EEA, UK, and Switzerland. If browse abandonment volume drops after cutover, check tracking before you blame the creative.

Placed order, paid for order, and the order lifecycle

Omnisend's order follow-up automation defaults to the placed order trigger with an order status filter set to paid. The two triggers are different on purpose: placed order fires when the order is created at checkout, and paid for order fires only when payment status changes to paid.

Klaviyo's Shopify metric list has Placed Order, Ordered Product, Fulfilled Order, Fulfilled Partial Order, Cancelled Order, and Refunded Order. There is no separate paid event in it. If your Omnisend flow depends on payment status, such as for manual payment methods, confirm how that order data will reach Klaviyo before you assume Placed Order covers it.

The sharpest edge sits between Placed Order and Ordered Product. One order produces one Placed Order event and one Ordered Product event for each line item, synced seconds apart. Klaviyo's documentation gives the failure itself: trigger a flow on Placed Order, then filter out anyone who has Ordered Product since the flow started, and every recipient is skipped. Pick one metric per flow and keep to it. Klaviyo recommends Placed Order for triggers and filters.

Fulfillment gets better on the Klaviyo side. Omnisend's recommended events include order fulfilled but no delivery event. Klaviyo also tracks Confirmed Shipment, Delivered Shipment, and Marked Out for Delivery, which means a review request can key off delivery instead of a guessed number of days.

Exit conditions are the last gap. Omnisend lets you set up to five exit conditions on a workflow, such as Order Canceled. Klaviyo uses profile filters, which it checks when someone enters and before each action, plus conditional splits. A canceled order becomes a filter on the Cancelled Order metric. Transactional messages such as order confirmations get their transactional status per message in Klaviyo, and they cannot carry marketing content.

Back in stock, price drop, and wishlist triggers

Omnisend has a built-in "product back in stock" trigger, and many stores feed it from apps that send custom events. Klaviyo's back in stock flow only fires from the Klaviyo-branded Subscribed to Back in Stock metric. Its documentation states that custom metrics cannot trigger a back in stock flow. Only the Klaviyo metric from a supported integration, a custom catalog, or a back in stock API call can.

So a store whose restock alerts depend on a third-party app's custom event needs a different plan: switch to a supported integration, or rebuild the subscription step with Klaviyo's own form or API. Inventory also has to sync into the catalog, because the restock moment is detected from stock levels. Klaviyo adds a back in stock delay step that holds each subscriber until their product returns.

Price drops move the other way. Omnisend gets wishlist price drops through apps that send custom events. Klaviyo has native triggers for price drops and low inventory, fired for items a shopper viewed or started checkout with, by a flat amount or a percentage. If the Omnisend version only reached wishlisters, expect the Klaviyo version to reach a wider audience unless you filter it.

Birthday, dates, and segment triggers

Omnisend's birthday trigger fires on the contact's birthday and can be offset by hours, for example 24 hours before. Birthday is the only preset that recurs. Klaviyo handles this with a date property trigger, which can start before the date and repeat monthly or yearly, and which qualifies a person whenever the date property is added or updated.

That last clause is the catch. If the birthday arrives as a text field in the import instead of a date property, the flow has nothing to fire on. Map it deliberately and test with one profile.

Segment triggers carry a similar subtlety. Omnisend uses an "entered segment" event filtered by segment ID. Klaviyo's segment-triggered flow fires when a profile newly qualifies, and repeated activity that does not change membership does not re-trigger it. If your Omnisend automation relied on a segment to re-enroll the same people repeatedly, plan the re-entry setting up front.

Custom events: names, properties, and consent

Custom events are the least portable part of an Omnisend account because they are defined by whoever built them. Omnisend custom events have no predefined names or properties, and they can be used for triggers, filters, and segments. One quirk matters for consent: Omnisend's own FAQ says automations built on custom events can reach every contact type, including unsubscribed contacts.

In Klaviyo, custom data arrives as a metric through the API, and flows can be triggered from API-created events. For a store on a custom platform, Klaviyo's integration guide is blunt that metric names must match the documented ones, such as Placed Order, or Klaviyo will not recognize them in its analytics. Then there is consent. Klaviyo sets transactional status message by message, and transactional messages cannot carry marketing content. A custom-event workflow that reached unsubscribed contacts in Omnisend needs a deliberate decision: mark it transactional only if it truly is, or let normal consent rules apply and expect the audience to shrink.

Why event-for-event migrations fail

The common failure is rebuilding flows from screenshots of the Omnisend canvas. The trigger gets matched by name, and the data the trigger carried gets lost on the way.

The visible symptoms are small: a flow that sends to nobody, a browse email with no product, a back in stock flow that never fires, a post-purchase series that skips every recipient. Each one traces to a trigger whose data contract was never written down. The Placed Order and Ordered Product skip is the clearest case, because the flow looks perfect in the builder and sends nothing.

Screenshots also miss everything that is not on the canvas: the audience filter, the trigger filter, the frequency limit, and the exit conditions. Those four settings decide who is eligible, and they live in menus.

How Sticky Digital maps an Omnisend to Klaviyo migration

Our Klaviyo migration work starts from an inventory, not a design. The mechanics we use:

• Export every workflow with its trigger, trigger filters, audience filters, frequency limit, and exit conditions, so nothing lives only in someone's memory.
• Write a one-line trigger contract for each flow: the Omnisend event, the Klaviyo metric or trigger that replaces it, and the properties the email template reads.
• Check each metric's source in Analytics before choosing it, since Shopify-branded and onsite-tracked metrics can share a name.
• Keep every flow in draft until the contact import, consent mapping, and catalog sync are finished, then fire each trigger with a test profile and a test order.
• Schedule the cutover so Omnisend workflows and Shopify's own abandoned checkout emails are switched off the same day the Klaviyo flows go live, to prevent double sends.

Flows come first and campaigns come second, because flows carry the larger and steadier share of attributed revenue.

FAQ

Does Omnisend's placed order trigger map to Klaviyo's Placed Order metric?

Yes, they describe the same moment: an order created when checkout completes. The difference is that Klaviyo sends each line item as a separate Ordered Product event seconds later, so a flow should trigger and filter on one metric only. Klaviyo recommends Placed Order for that purpose.

Can a custom event trigger Klaviyo's back in stock flow?

No. Klaviyo's documentation states that custom metrics cannot trigger a back in stock flow. The flow needs the Klaviyo-branded Subscribed to Back in Stock metric, which comes from a supported integration, a custom catalog, or a back in stock API call.

Will browse abandonment work the same way in Klaviyo as in Omnisend?

Not exactly. Omnisend's browse abandonment preset triggers on a page view and does not capture which products were viewed. Klaviyo's flow triggers on Viewed Product, which carries the product, so the email can show it. Both only work for identified visitors, and onsite tracking can be limited by privacy settings in some regions.

What replaces Omnisend exit conditions in Klaviyo?

Klaviyo uses profile filters, which it checks when someone enters a flow and before each action, along with conditional splits. An Omnisend exit condition such as Order Canceled usually becomes a filter on the matching Klaviyo metric, such as Cancelled Order.

How should contacts who never opted in be handled during the move?

Decide the policy before cutover. Omnisend lets abandonment automations run for non-subscribed contacts, and Klaviyo will send an abandoned cart email to a never-subscribed profile while advising caution. A consent filter on the flow makes it stricter. This is a compliance decision, so involve counsel rather than relying on defaults.

Brands that want an Omnisend to Klaviyo migration scoped trigger by trigger can start here, and the Sticky blog has more migration guides.

Article By: Mariel Kilroy, Co-Founder, Sticky Digital

Mariel Kilroy is the Co-Founder of Sticky Digital, a retention marketing agency specializing in email, SMS, loyalty, and subscription growth for DTC brands.