A senior DevOps engineer breaks down why absurdly high ROAS figures are a symptom of a broken data pipeline, not a marketing miracle. Learn three real-world fixes, from a quick client-side hack to a robust server-side deduplication strategy, to restore sanity to your metrics.

That 1,749% ROAS? It’s a Mirage. Here’s How to Fix the Data Pipeline That’s Lying to You.

I got a Slack message at 7 PM on a Friday. It was from our Head of Marketing. The message was just a screenshot of a dashboard with a big, green number and the text “Can we get this higher?? EOD goal.” The number was a 2,000%+ Return on Ad Spend (ROAS). My first thought wasn’t “Wow, great job,” it was “Which one of our event streams is broken now?” We spent the next four hours untangling a bug where a front-end change caused our conversion pixel to fire on every single page load after a purchase, not just on the thank-you page. The numbers were a fantasy, the client was making decisions based on garbage data, and my weekend was shot. So when I see a Reddit post about a client wanting to push a 17.49x ROAS even higher, I don’t see a demanding client. I see a flashing red light on my own monitoring dashboard.

The “Why”: Your Data is Lying to the Business

Let’s be blunt. A 1,749% ROAS isn’t a marketing achievement; it’s a data integrity failure. The client isn’t crazy for asking for more; they’re just reading the broken speedometer you handed them and asking why you can’t go faster. The root cause is almost always the same: duplicate conversion events.

This happens for a few common reasons:

• A user bookmarks the “Thank You” page and visits it again later, firing another conversion event.
• A single-page application (SPA) re-renders the confirmation component without a proper state check, re-firing the pixel.
• A misconfigured server-side tag sends the event multiple times due to retries or logic errors.

The result is that for one real $50 purchase, your analytics platform might record five “conversion” events, reporting $250 in revenue against the same ad spend. The math looks great, but it’s a complete fiction. Your job isn’t to make the fake number bigger; it’s to fix the data so the number reflects reality.

The Fixes: From Duct Tape to a New Foundation

You’ve got three paths forward, depending on how much time you have and how much technical debt you’re willing to take on. I’ve used all three in my career.

Solution 1: The Quick & Dirty Fix (Client-Side Deduping)

This is the “stop the bleeding” approach. You need to make the problem go away now because the business is making bad decisions. The goal is to prevent the user’s browser from firing the same conversion event multiple times. We can do this with localStorage.

When a purchase is complete, you generate a unique transaction ID. Before firing your analytics pixel, you check if this ID is already in the user’s local storage. If it is, you do nothing. If it isn’t, you fire the pixel and then immediately save the ID to storage.

Here’s a simplified JavaScript example:

function fireConversionEvent(transactionId) {
  const processedKey = `processed_tx_${transactionId}`;

  // Check if we've already processed this transaction in this browser
  if (localStorage.getItem(processedKey)) {
    console.log(`Transaction ${transactionId} already tracked. Skipping.`);
    return;
  }

  // Fire your actual tracking pixel here
  // fbq('track', 'Purchase', { ... }); 
  console.log(`FIRING event for transaction ${transactionId}`);

  // Mark this transaction as processed in this browser
  localStorage.setItem(processedKey, 'true');
}

// On your confirmation page, you'd call it like this:
// const orderId = getOrderIdFromPage(); // e.g., "ORD-12345"
// fireConversionEvent(orderId);

Warning: This is a band-aid, not a cure. It’s hacky. It fails if the user clears their cache, uses a different browser, or if the server-side event is the one duplicating things. Use this to buy yourself time to implement a real solution.

Solution 2: The Right Way (Server-Side Event Deduplication)

This is the permanent, architecturally sound solution. The source of truth should be your backend, not the client’s browser. The principle is the same: use a unique ID, but do the check on the server before you accept the event into your data pipeline.

The flow looks like this:

1. Your front-end or backend generates a unique event ID (a UUID or the order ID) when a conversion happens.
2. This event is sent to your event ingestion endpoint (e.g., an API Gateway hooked up to a Lambda function).
3. Your ingestion service first checks a high-speed cache like Redis or a database table to see if it has ever processed this event ID before.
4. If the ID exists: The service returns a 200 OK response but discards the event.
5. If the ID does not exist: The service adds the ID to the cache/database with a short TTL (Time To Live, say 24 hours) and then forwards the event to your analytics platform or data warehouse.

This is how we do it at TechResolve. We have a dedicated microservice, `event-ingest-api-prod`, that uses a Redis cluster for exactly this purpose. It’s the only way to guarantee a “one-and-only-one” event processing semantic.

Solution 3: The ‘Nuclear’ Option (Data Warehouse Reconciliation)

Sometimes, the event pipeline is just too far gone. It’s a spaghetti mess of client-side tags, server-side events, and third-party webhooks. Trying to fix it is a massive project. In this case, you abandon it as the source of truth for reporting.

The ‘nuclear’ option is to go directly to the source: your production database. You set up a nightly (or hourly) batch job that does the following:

1. Connects directly to a read-replica of your production database (e.g., prod-db-01-replica).
2. Pulls all sales records from the last 24 hours.
3. Connects to your marketing event data stored in your data warehouse (e.g., Snowflake, BigQuery).
4. Runs a SQL query to join the actual sales data with the marketing attribution data.

Your reconciliation query might look something like this in principle:

-- This is a conceptual query for BigQuery/Snowflake
SELECT
    s.order_id,
    s.order_total,
    s.timestamp AS sale_time,
    a.utm_source,
    a.utm_campaign
FROM
    prod_database.sales_data AS s
JOIN
    marketing_warehouse.attribution_events AS a
ON
    s.customer_id = a.customer_id
WHERE
    s.timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
-- This join gives you a source of truth for ROAS calculations
-- that completely bypasses the broken, real-time event stream.

Pro Tip: This approach is slow and isn’t real-time, but it’s 100% accurate. It’s often the first step in a major data platform overhaul. You use this to generate the “real” reports while you take the time to go back and fix the streaming pipeline correctly using Solution 2.

So, no, your client isn’t crazy. They’re just operating on bad intel. Your job is to stop being a report-puller and start being an engineer. Fix the underlying data integrity, give them a number they can trust, and then you can have a real conversation about growth.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions