Recover the abandon that happened on the phone and the purchase that continues on the laptop, as one customer rather than two
A shopper fills a cart on their phone during a commute, then opens the laptop at home to think it over and never finishes. To the stack this is two separate stories: an anonymous mobile session that abandoned a cart, and a returning desktop visitor with an empty one. The basic recovery flow emails about the phone cart, the customer gets a reminder for items they are actively reconsidering on a different screen, and the experience feels disjointed because the system never understood that the abandon and the reconsideration are the same person.
The single-device version of this recipe works well for the share of carts that begin and end on one device. The gap it cannot close is the cross-device journey, which in many consumer categories is a large and growing fraction of considered purchases, because people research on mobile and commit on desktop. Closing that gap is not a tweak to the email sequence. It requires the stack to resolve the abandon and the continuation to one customer before the recovery logic runs.
This recipe is the cross-device variant: the same recovery cadence, but triggered against a resolved person rather than a device session.
Recover carts that span devices, which the single-device flow either misses or mishandles. Realistic effect: an incremental lift on top of the basic recovery rate, concentrated in the cross-device share of abandons, which depends on how much of the audience shops across devices and how much of that journey passes through a login or other deterministic link. Categories with considered purchases and routine authentication see more lift; impulse-buy categories where most carts complete in one session see less, because there is less cross-device journey to recover in the first place.
The cleaner outcome is coherence. The customer who abandoned on mobile and is reconsidering on desktop gets one recovery experience that recognizes them, rather than a mobile reminder that ignores the desktop session entirely.
The basic flow runs comfortably on a packaged marketing suite. This variant needs the composable identity layer underneath: a CDP or identity service maintaining the cross-device graph, with the recovery tool reading the resolved identity rather than a device cookie. The deciding capability is resolution freshness at trigger time. If the graph updates in nightly batch, a customer who abandons on mobile at noon and logs in on desktop at one is still two identities when the recovery trigger evaluates, and the cross-device recovery never fires. The load-bearing edges have to be fresh enough that the trigger sees the resolved person, which is why this recipe inherits the synchronous-write discipline of the identity recipe it depends on.
Compare the tools on Martech Stack Builder
Marketing ops still owns the recovery sequence, but now with cross-device exit conditions: a completion on any device has to suppress the flow, including a completion on a device other than the one that abandoned. Identity or CDP ownership becomes critical rather than absent, because the recovery decision now rests on the resolution layer's merge confidence, and a wrong merge means recovering the wrong person's cart. Data engineering owns the trigger-to-identity-to-activation pipeline and its freshness. Analytics audits the cross-device recovery cohort for false merges and measures the incremental recovery against the single-device baseline. The recipe sits at medium-high readiness and takes months rather than weeks because it inherits the identity layer's dependencies. A team that already runs cross-device resolution adds this quickly; a team that does not is really building the identity recipe first and the recovery flow second.
Work in this order. Resolve first, then trigger; triggering on a device session and resolving afterward produces the disjointed experience this recipe exists to fix.
Legal basis, deterministic linking and merge confidence (steps 1 to 3) are cross-device identity resolution, step 4 is anonymous-to-known stitching, step 5 is the behavioral trigger, step 6 is the channel eligibility check, and step 7 is the timed message sequence.
The first failure is the false merge recovering the wrong cart. If the identity layer merges two people who share a household device, the recovery flow can email one customer about another's abandoned cart, which is both a strange experience and a privacy exposure. The recovery cohort deserves conservative merge confidence specifically because the output is outbound contact about specific products.
The second is the stale graph swallowing the recovery. If resolution lags the session, the trigger evaluates against an unresolved identity and either fails to fire or fires from the wrong branch. This is the single most common reason a cross-device recovery flow underperforms its promise: the identity is correct eventually, but not at the moment the trigger needed it.
The third is consent and channel eligibility across the resolved identity. When a customer is one person across three devices, the consent and subscription state has to be evaluated against the person, not the device that happened to abandon. A send-time eligibility check that reads device-level state can message a customer who opted out on their primary device because the abandon happened on a secondary one. Eligibility has to resolve to the person, the same way the trigger does.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The resolution freshness the trigger needs, the merge confidence the recovery cohort requires, and the person-level eligibility check that keeps the flow from messaging the wrong device: those are the decisions that turn a single-device recovery flow into one that follows the customer across screens.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Recognize tenure and usage milestones with a touch that reads as personal rather than as a template with a date merged in
Warn the customer before the overage, the roaming charge, or the plan-mismatch cost lands on the bill, so the conversation is about what to do next rather than about why the bill is what it is
Recover the buy-online-pickup-in-store orders that the customer placed and never collected, with the cross-system identity and the in-store inventory signal that the recovery has to coordinate around