Klaviyo Email Deliverability & Flow Architect for a Custom Ecommerce Site

We run a marketing agency, and we need a senior Klaviyo person to take over the cleanup of one client's account and own it through to fixed. Here's the situation. The client is an established ecommerce brand with a list of around 350,000 contacts. Earlier this year they moved off Listrak onto Klaviyo. Since the migration, orders attributed to email have dropped from roughly 1,500–2,000 per month to about 500. We've already run a full audit against the live account, so we know most of what's wrong. We need someone to confirm it, fix it, and talk about it confidently with a sharp technical contact on the client's side. The hard part is the website. The client's site is custom-coded, not Shopify or WooCommerce. The Placed Order event feeds Klaviyo through a custom API integration, and we believe it's double-firing (one transactional flow shows about 4,700 conversions from only 254 buyers). You need to be comfortable reading how events post through an API, spotting duplication, and telling the client's developer exactly what to change. This is not a template-design gig. What you'll do: 1. Work with the client's developer to validate the Placed Order API payload: one event per order, a unique event ID, no per-line-item or status-change duplication. 2. Fix attribution. Exclude or relabel transactional flows (order, shipping, delivery confirmations) so they stop inflating revenue, set proper conversion windows, and reconcile Klaviyo-attributed revenue against UTM/GA4 revenue. 3. Clean up the flow architecture. Remove a duplicate Welcome Series, de-conflict overlapping "Added to List" flows, and rebuild thin cart flows (abandoned checkout and add-to-cart) with the right exclusions between them. 4. Turn on and standardize UTM tracking across every flow and campaign email. 5. Set a warming and deliverability plan for the 350k list: engaged-segment sending, sender-reputation rebuild, and a clear rule for when full-list sends are safe. 6. Hand us a point-by-point issue log we can take into a Klaviyo support call. Please answer in your proposal: How do you tell real incremental email revenue from inflated transactional-flow attribution in Klaviyo? What do you turn off or relabel?