Should Returns Data Live in Your ESP? The Post-Purchase Architecture Question

Direct answer: Yes, returns and order tracking data should live in your ESP, but that does not mean your ESP should send your tracking notifications. The returns and tracking platform should remain the system of record, because it owns the carrier integrations, the exceptions, the return reasons, and the exchange logic. The ESP should receive that data as events and profile properties so it can segment, suppress, and coordinate across every other message the customer gets. Sticky Digital recommends piping return and delivery events into the ESP in all cases, and moving the actual sending into the ESP whenever the post-purchase message needs to be coordinated with marketing frequency, which for most DTC brands is most of the time.

What changed in January 2026

Redo acquired Malomo, the branded order tracking platform, in January 2026, and has since also acquired ReturnLogic. The Redo platform now spans returns, exchanges, warranties, claims, package protection, order tracking, fulfillment, AI support, and checkout, which makes it one of the broadest post-purchase stacks available to Shopify brands.

That consolidation is good for merchants and it sharpens this question considerably. When returns lived in one app and tracking lived in another and the ESP lived somewhere else, nobody pretended the architecture was clean. Now that a single platform can run returns, tracking, support, and messaging end to end, brands face a real choice about where the post-purchase conversation should originate, and the convenient answer is not always the right one.

Disclosure, because this piece would be worth less without it: Redo is a Sticky Digital partner, alongside Klaviyo, Attentive, Yotpo, Rivo, and Tie. We are also a Klaviyo Platinum Partner, which means we have a commercial relationship with platforms on both sides of this question. We have tried to write the architecture we would actually recommend to a client who was paying us to be right rather than agreeable. Where our interests and the recommendation line up, they line up, and you should weigh that.

The two questions, separated

System of record. Which platform holds the authoritative version of what happened? For a return, that is the return reason, the item, the resolution, whether it became an exchange or store credit or a cash refund, and the timestamps. For a shipment, it is the carrier scans, the exceptions, the delivery estimate, and the delivery confirmation.

The post-purchase platform should win this almost without exception. It maintains the carrier integrations, reconciles the exceptions, handles the warehouse side, and increasingly runs the warranty and claims logic too. An ESP reconstructing that from webhooks is rebuilding infrastructure badly.

Sending layer. Which platform actually puts the message in front of the customer? This is where the default answer, meaning whichever platform generated the event, is usually wrong, because the sending decision depends on information the post-purchase platform does not have. It does not know the customer received two campaigns yesterday. It does not know they are in an active dunning sequence. It does not know they unsubscribed from marketing but not transactional. It does not know they are a VIP in the loyalty program.

The ESP knows all of that, because that is what an ESP is. It is the coordination layer for everything a customer receives.

Four things that break when post-purchase sends outside the ESP

Frequency goes uncoordinated. The most common symptom, and the one customers actually notice. A shipping delay notice and a promotional campaign arriving within an hour of each other read as a brand that is not paying attention. Neither system did anything wrong individually. There was no system responsible for the pair.

Suppression logic does not apply. Your ESP has carefully built suppression: recent purchasers excluded from acquisition offers, unengaged profiles sunset, subscribers in a cancellation save flow protected from promos. None of that reaches a message sent from another platform. The hardest-won logic in the account silently does not cover a meaningful share of sends.

The data never becomes segmentable. This is the expensive one. If tracking and return events stay inside the post-purchase platform, you cannot build a segment of customers who returned for fit reasons in the last 90 days, or who experienced a delivery exception on their first order. That is some of the highest-signal behavioral data a DTC brand generates, and it sits in a system that cannot act on it beyond its own notifications.

Reporting splits. Revenue attributed to post-purchase messaging lives in one dashboard and everything else lives in another, usually on different attribution windows. Nobody can answer what the post-purchase program is worth relative to the rest of the lifecycle, so it gets managed by vibes.

What breaks if you try to run it all in the ESP

The opposite error is just as real, and agencies make it more often than merchants do.

Carrier tracking is genuinely hard. Normalizing scan events across carriers, handling exceptions, estimating delivery dates, and rendering a branded tracking page that works on mobile is specialist infrastructure, and the platforms that do it well have spent years on it. An ESP flow triggered on a Shopify fulfillment event gives you a shipping confirmation, not order tracking. Those are different products and customers can tell.

Branded tracking pages in particular are not an ESP capability. The tracking page is the single most-visited post-purchase surface a brand owns, often opened multiple times per order, and it is a merchandising opportunity that a transactional email cannot replicate. That is the part of the acquired Malomo product that was always strongest, and it belongs where it is.

Return logic is the same story. Exchange-first flows, variant-level return rules, bundle and child SKU relationships, policy windows by product category, and store credit issuance are operational workflows, not marketing automations. Nobody should rebuild those in a flow builder.

The architecture we recommend

Post-purchase platform owns operations and the tracking page. Returns portal, exchange logic, policy rules, warranty and claims, carrier integration, delivery exception handling, and the branded tracking page. This is the system of record and the operational surface.

ESP owns the messaging and the segmentation. Every customer-facing message that is not strictly operational routes through the ESP so suppression, frequency, and cross-channel logic apply once, in one place. Transactional messages that must deliver regardless, such as a return label or a refund confirmation, can stay in the post-purchase platform, since those are receipts rather than marketing.

Events flow one direction, continuously. Return created, return reason, return resolution, exchange completed, refund issued, shipment created, delivery exception, delivered. Each one lands in the ESP as an event with properties, not just a profile flag.

Use a separate sending domain or subdomain for transactional. Post-purchase messages should not inherit promotional reputation or get caught by marketing frequency caps meant for campaigns.

The test for whether a message belongs in the ESP is simple. If sending it at the wrong moment, or to the wrong person, or alongside the wrong campaign would be a problem, it needs the ESP's coordination. If it is a receipt the customer is actively waiting for, it can send from wherever generates it fastest.

The data worth piping in, specifically

Most integrations between a post-purchase platform and an ESP sync far less than they could. These are the fields that change what you can build.

Return reason. The highest-value and most frequently ignored. A customer who returned because an item did not fit is a retention target. A customer who returned because the product arrived damaged is a service recovery situation. A customer who returned because the product did not do what the marketing implied is a signal about your copy. Treating these three identically, which is what happens when the field never reaches the ESP, wastes the most useful behavioral data in the post-purchase window.

Return resolution. Exchange, store credit, and cash refund represent completely different relationships. An exchange customer is still a customer. A cash refund customer may not be. These should drive different downstream treatment and usually drive none.

Delivery exception events. A customer whose first order was delayed or lost has a materially different likelihood of ordering again, and the window to intervene is short. Almost no brand we audit has a flow triggered on this.

Time to delivery. As a profile property, this lets you segment by actual experienced service level rather than promised service level, which is a better predictor of repeat behavior than almost anything in the order record.

Return rate at the profile level. Needed to suppress serial returners from aggressive win-back and discount logic. Running a 40% off reactivation campaign to a customer who returns most of what they buy is a loss you are paying to generate.

The post-return flow almost nobody builds

Most brands send nothing after a return is processed, which treats the moment as an accounting event rather than a retention one. The customer just told you something specific about your product, in a structured field, and the silence that follows is a choice.

The build is one flow with conditional branches on return reason tier.

Fit and sizing returns are the strongest retention target, because intent was there and the execution failed. Branch toward size guidance, fit content, and a direct exchange path rather than a discount. These customers frequently convert on a second attempt at the same product.

Preference and changed-mind returns need a merchandising angle rather than a service one. Surface adjacent categories and let the return inform what you show them next.

Quality and damage returns require a different posture entirely. No offer, no merchandising, no urgency. An acknowledgment, a clear resolution, and a quiet re-entry into normal messaging later. Sending a promotional email to someone whose product arrived broken is the fastest unsubscribe in the lifecycle.

Suppression matters as much as the sends. Anyone in an open return or unresolved claim should be held out of promotional campaigns until it closes.

How Sticky Digital works with post-purchase data

Sticky Digital is a retention-only agency for DTC ecommerce brands, running email, SMS, loyalty, and subscription. We do not run paid media, SEO, or site builds.

On post-purchase, we audit the integration before we build anything, because the limiting factor is almost always which fields are syncing rather than which flows exist. We keep the post-purchase platform as the system of record, move coordinated messaging into the ESP, and build return reason segmentation that most accounts have the data for and have never used. We report on ESP-owned metrics, meaning repeat purchase rate, revenue per recipient, and cohort LTV, rather than total store revenue.

Related reading on how we approach this kind of question: our portfolio analysis of payment failure recovery and our 94-brand analysis of when retention investment pays off. Our service model is documented rather than asserted.

FAQ

Should returns data live in your ESP?

Yes, as synced events and profile properties, but the returns platform should remain the system of record. The returns platform owns the portal, the exchange logic, the policy rules, and the operational workflow. The ESP needs the resulting data, specifically return reason, return resolution, and profile-level return rate, so it can segment, suppress, and coordinate messaging across the full lifecycle. Keeping return data only inside the returns platform means you cannot build segments on it or apply it to campaign suppression, which wastes the highest-signal behavioral data in the post-purchase window.

Should order tracking emails send from your ESP or your tracking platform?

From the ESP whenever the message needs coordination with everything else the customer receives, which is most of the time for DTC brands. Messages sent from a tracking platform bypass ESP suppression and frequency logic, which is how a customer receives a shipping delay notice and a promotional campaign within the same hour. Pure receipts the customer is actively waiting for, such as a return label or refund confirmation, can send from the post-purchase platform. The branded tracking page itself should always stay with the tracking platform, since that is specialist infrastructure an ESP cannot replicate.

What did Redo acquire in 2026?

Redo acquired Malomo, the branded order tracking platform, in January 2026, and has also acquired ReturnLogic. The combined platform now covers returns, exchanges, warranties, claims, package protection, order tracking, fulfillment, AI support, and checkout for ecommerce brands. The consolidation means a single platform can now run both post-purchase operations and post-purchase messaging, which makes the architecture decision about where messaging should originate more consequential than it was when those functions were split across separate apps.

What return data should sync to Klaviyo?

Return created and return resolution as events, with return reason, item, and resolution type as event properties. Delivery exception and delivered as separate events. Time to delivery and profile-level return rate as profile properties. Return reason is the most valuable and most commonly missing field, because a fit return, a preference return, and a quality return represent three different retention situations that most accounts treat identically.

What should you send after a customer returns something?

One flow with conditional branches on return reason. Fit and sizing returns branch toward size guidance and a direct exchange path, since intent was present and execution failed. Preference returns branch toward adjacent merchandising. Quality and damage returns get acknowledgment and resolution with no offer and no merchandising, because a promotional message to someone whose product arrived broken produces the fastest unsubscribe in the lifecycle. Anyone with an open return or unresolved claim should be suppressed from promotional campaigns until it closes.

Does Sticky Digital have a commercial relationship with Redo?

Yes. Redo is a Sticky Digital partner, alongside Klaviyo, Attentive, Yotpo, Rivo, and Tie. Sticky Digital is also a Klaviyo Platinum Partner, meaning it has commercial relationships with platforms on both sides of the post-purchase architecture question. Readers should weigh that when evaluating the recommendation.

Audit what your integration is actually syncing

Brands that want their post-purchase data flow mapped before building new flows can start a conversation here.

About Sticky Digital: Sticky Digital is a retention-only marketing agency for direct-to-consumer ecommerce brands, founded in 2019 and based in San Diego, California. The agency is a Klaviyo Platinum Partner and was named Retention Marketing Agency of the Year. It works exclusively in email, SMS, loyalty, and subscription growth for DTC brands in beauty, wellness, food and beverage, and apparel, and does not offer paid media, SEO, or site development.

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.