<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: RAMO</title>
    <description>The latest articles on DEV Community by RAMO (@elias_0549e0e2ef8cf6ad89a).</description>
    <link>https://dev.to/elias_0549e0e2ef8cf6ad89a</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4225815%2F585211d9-cca0-479d-9f73-ab0c4bd4be82.png</url>
      <title>DEV Community: RAMO</title>
      <link>https://dev.to/elias_0549e0e2ef8cf6ad89a</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/elias_0549e0e2ef8cf6ad89a"/>
    <language>en</language>
    <item>
      <title>What broke when we counted conversions twice (and the boring test that fixed it)</title>
      <dc:creator>RAMO</dc:creator>
      <pubDate>Wed, 04 Nov 2026 17:06:14 +0000</pubDate>
      <link>https://dev.to/elias_0549e0e2ef8cf6ad89a/what-broke-when-we-counted-conversions-twice-and-the-boring-test-that-fixed-it-d10</link>
      <guid>https://dev.to/elias_0549e0e2ef8cf6ad89a/what-broke-when-we-counted-conversions-twice-and-the-boring-test-that-fixed-it-d10</guid>
      <description>&lt;p&gt;We run a small Israeli tools and home-improvement store, &lt;a href="https://ramo.co.il" rel="noopener noreferrer"&gt;ramo.co.il&lt;/a&gt;, on Next.js and Vercel. A few weeks ago our ad dashboards said we were doing great. Our bank account disagreed.&lt;/p&gt;

&lt;p&gt;The cause was dull: the purchase event fired twice on the thank-you page. Once on the first render, and again after a client-side navigation re-mounted the component. Google Ads and Meta both happily counted two sales, and the bidding algorithms started paying more for traffic that wasn't converting as well as they thought.&lt;/p&gt;

&lt;h2&gt;
  
  
  How we found it
&lt;/h2&gt;

&lt;p&gt;Not from the dashboards. We opened the network tab, finished a test order and watched two identical &lt;code&gt;purchase&lt;/code&gt; hits go out a few hundred milliseconds apart. That was the whole investigation.&lt;/p&gt;

&lt;h2&gt;
  
  
  The fix
&lt;/h2&gt;

&lt;ol&gt;
&lt;li&gt;Fire purchase events from one place only, keyed by order ID.&lt;/li&gt;
&lt;li&gt;Store the order ID in &lt;code&gt;sessionStorage&lt;/code&gt; after sending, and skip if it's already there.&lt;/li&gt;
&lt;li&gt;Pass the same &lt;code&gt;transaction_id&lt;/code&gt; / &lt;code&gt;event_id&lt;/code&gt; to every platform so they can dedupe on their side too.&lt;/li&gt;
&lt;/ol&gt;

&lt;h2&gt;
  
  
  The test that keeps it fixed
&lt;/h2&gt;

&lt;p&gt;The real win was a Playwright test that runs before every deploy. It loads a product page, adds to cart, completes a test checkout and counts outgoing requests per platform. If any tag fires zero times or more than once, the deploy is blocked.&lt;/p&gt;

&lt;p&gt;It takes about a minute to run and it has already caught one regression from an unrelated refactor.&lt;/p&gt;

&lt;p&gt;If you sell anything online, check your purchase event today. Place a test order with the network tab open. It's five minutes, and it might explain why your ROAS looks better than your revenue.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>nextjs</category>
      <category>ecommerce</category>
      <category>testing</category>
    </item>
  </channel>
</rss>
