Executive Summary
In September 2026, I identified a conversion-tracking discrepancy on a website where the backend showed more completed paid orders than the analytics and advertising platforms were reporting.
The initial discrepancy was straightforward. Website backend: 3 paid orders, 2 Cash on Delivery, 1 online payment. But GA4 received 2 purchases, and Meta received 2 purchases as well.
The missing conversion was the online-payment order.
At first, this looked like a possible Google Tag Manager trigger problem. However, rather than immediately changing the GTM configuration, I traced the order through the complete measurement architecture:
Website → Web GTM → Stape/sGTM → GA4 + Meta CAPI
The investigation eventually revealed that the problem existed upstream of the server-side tracking infrastructure.
For Cash on Delivery orders, the Purchase flow was functioning. For online payments, customers were redirected to the third-party payment processor, SSLCommerz, before returning to the website’s order-success page. On that return journey, the expected Purchase event was not being generated.
At the same time, I discovered a second problem: the website’s dataLayer wasn’t structured well enough for reliable ecommerce and customer-data tracking. Important customer information and ecommerce parameters were missing.
I therefore worked with the developer to restructure the dataLayer using a WordPress/WooCommerce-style structure as a reference. The goal was not to add random fields, but to create an organized structure that included the information the tracking implementation required.
The investigation identified more than seven missing purchases.
The final solution involved correcting the Purchase event flow, improving the dataLayer, exposing ecommerce and customer information, aligning GTM variables with the actual dataLayer structure, and validating the complete event path through GTM and Stape.
One of the most important lessons from the investigation was that a successful API response does not necessarily mean that a conversion event is useful or correctly implemented.
1. Project Background
I was working on the website from the beginning of the project as the Digital Marketing Manager, with more than four years of experience across the broader digital marketing and tracking stack, including:
- Google Tag Manager
- GA4
- Meta Pixel and Conversions API
- Server-side GTM
- Stape
- Conversion tracking
- Marketing analytics
The website used a server-side tracking architecture built around:
Website → Web GTM → Stape/sGTM → GA4 + Meta CAPI
The server-side infrastructure was therefore already in place.
The initial assumption could be that the problem was somewhere inside GTM, Stape, GA4, or Meta.
But I wanted to determine exactly where the data was disappearing.
2. The Initial Problem
The investigation started around September 29, 2026.
I noticed that the website backend and the marketing platforms were reporting different numbers. The backend showed 3 paid orders. These included 2 Cash on Delivery orders and 1 online-payment order. However, GA4 and Meta showed 2 purchases.
The missing order was the online-payment order. This was the first important clue. If all three orders had been missing randomly, I would have investigated the entire Purchase implementation equally. But when I compared the orders individually, a pattern emerged. Cash on Delivery orders were being tracked, while the online-payment order was missing. That immediately narrowed the investigation.
3. My Initial Hypothesis: GTM Purchase Trigger
My first suspicion was the Google Tag Manager Purchase trigger. The Purchase implementation depended on a purchase event. So the first question was: Is the Purchase event actually being generated? This distinction is critical in conversion tracking.
There are several different failure points:
Order completed– does not necessarily mean
Purchase event generated– which does not necessarily mean
GTM processed the event– which does not necessarily mean
Stape received the request– which does not necessarily mean
GA4/Meta received a valid conversion.
I therefore traced the order from the beginning rather than immediately changing the destination-platform configuration.
4. Following the Customer Journey
I manually followed the online-payment customer journey. The flow was:
Customer
↓
Website
↓
Checkout
↓
SSLCommerz / third-party payment processor
↓
Successful payment
↓
Website order-success / thank-you page
At this point, I discovered the critical difference between the two payment methods. For Cash on Delivery, the Purchase tracking flow was functioning. For online payment, the Purchase event was missing after the customer returned from the payment processor.
The Event Checker documentation explicitly separates the two situations into Cash on Delivery Purchase and Online Payment Purchase, and notes that online-payment purchases weren’t being counted because the Purchase event wasn’t firing.
This was the first breakthrough. The backend knew that the order existed. The payment gateway knew that payment had succeeded. But the analytics implementation didn’t necessarily know the order had become a Purchase.
5. Why the Payment Gateway Was Important
The third-party payment flow created a gap in the browser-side tracking journey. The customer left the website to complete payment. After payment, the customer returned to the website. The critical question became: What information is available when the customer returns to the order-success page, and does the website push the Purchase event then?
The answer was no for the problematic online-payment flow. This explained why a real paid order could exist in the website backend while no Purchase request appeared in the tracking pipeline. This was also why simply looking at GA4 or Meta wasn’t enough. Those platforms were downstream. If the browser never generated the appropriate Purchase event, GTM had nothing reliable to send downstream.
6. Moving Upstream: The DataLayer Investigation
Once I understood the Purchase-event problem, I started examining the website’s dataLayer. This revealed a second major issue. The website’s existing dataLayer was limited and, more importantly, was not organized around a consistent ecommerce/customer-data structure.
Important customer information was unavailable in the dataLayer. For example, information required for stronger customer matching included:
- Hashed email
- Phone
- Hashed phone
- First name
- Last name
- City
- State
- Country
- ZIP/postcode
- External ID
The existing implementation did not expose these values in the way the tracking architecture needed. This was important for Meta CAPI because the quality of server-side conversion tracking depends heavily on the quality and availability of the data supplied to it.
7. Why I Recommended a WordPress/WooCommerce-Style DataLayer
I did not want the developer to keep adding individual fields randomly. The existing structure was difficult to work with because fields were inconsistent and important information was missing. So I provided the developer with an example of what a structured WordPress/WooCommerce-style dataLayer could look like.
My reasoning was simple: The dataLayer needed a standard structure, not a collection of unrelated fields.
The WordPress-style structure gave us a logical way to organize:
- Visitor information
- Customer information
- Billing information
- Shipping information
- Cart information
- Order information
- Product information
- Ecommerce totals
- Hashed customer information
The resulting Purchase structure contained an orderData object with order attributes, totals, customer information, shipping information, and product items. For example, the Purchase data eventually contained order attributes such as:
- Order number
- Payment method
- Payment method title
- Shipping method
- Order status
along with totals such as:
- Currency
- Discount
- Shipping
- Subtotal
- Total
The customer object also contained billing information, hashed identifiers, contact information, and location information. The product information included fields such as:
- Item ID
- Item name
- SKU
- Price
- Category
- Quantity
This was a much more reliable foundation for the tracking implementation.
8. The Relationship Between the DataLayer and GTM
This was one of the most important technical lessons from the investigation. A GTM variable can only retrieve information that exists where it’s looking. For example, my Purchase variables were built around ecommerce parameters such as:
ecommerce.value
ecommerce.transaction_id
But if those fields weren’t present in the dataLayer when the Purchase event fired, GTM couldn’t magically generate them. That created a chain reaction:
Missing dataLayer field
↓
GTM variable returns empty/false
↓
Server-side request contains invalid or missing data
↓
GA4/Meta receives incomplete conversion information
This is why I treated the dataLayer as part of the tracking architecture rather than merely a developer-side implementation detail.
9. Creating a Controlled Test
After identifying the problem, I created a test product and placed test orders. The purpose wasn’t simply to see whether a Purchase appeared. I wanted to identify where the event was failing.
The test had to answer:
- Does the website generate the Purchase event?
- Does Web GTM receive it?
- Does GTM send the request?
- Does Stape receive it?
- Does Stape forward it?
- Does GA4 receive the Purchase?
- Does Meta receive the Purchase?
- Are the purchase values correct?
- Are the customer parameters available?
- Is the transaction ID correct?
This transformed the investigation from a reporting problem into an end-to-end debugging exercise.
10. First Successful Test — But Not Yet a Complete Fix
After the developer made the initial dataLayer changes, I created a test order. The Purchase event began reaching the tracking infrastructure. This was a major improvement. However, I did not consider the problem completely solved. Why? Because an event existing is not the same thing as an event being high quality.
The initial corrected test demonstrated that the event could travel through the pipeline, but the data quality still needed improvement. This distinction became particularly important when examining the server-side logs.
11. Using Stape as the Forensic Layer
I used Stape logs to determine whether GTM was sending purchase information correctly to the server-side container. Instead of asking only:
“Why isn’t GA4 showing this purchase?”
I asked: “Did GTM send the purchase?”
Then: “Did Stape receive it?”
Then: “What exactly did Stape receive?”
Then: “What did Stape send to GA4 and Meta?”
This approach allowed me to isolate the failure point. During the investigation, I found that not every purchase event reached Stape. That mattered because it meant the problem wasn’t simply a GA4 or Meta reporting issue. Some conversions were disappearing before they reached the server-side infrastructure.
12. The Second Class of Problem: Invalid Purchase Parameters
During later testing, I found another problem. Some Purchase requests contained values such as:
value = false
transaction_id = false
product_price = false
currency = 0
This was different from the original missing-event problem. Now the event could exist, but the data inside the event could be wrong. The cause became clear when I compared the GTM variables against the actual dataLayer structure. My variables were expecting ecommerce fields such as:
ecommerce.value
ecommerce.transaction_id
But the corresponding fields were missing from the dataLayer implementation. As a result, the GTM variables had nothing valid to retrieve. The result was an event that could technically be sent but contained unusable purchase information.
13. Why an HTTP 200 Response Was Not Enough
This was one of the most important lessons from the project. An API request can succeed technically while the marketing data inside that request is still poor. For example:
HTTP request being successful does not necessarily mean: Correct purchase value, Correct transaction ID, Correct currency, Good customer matching, or Useful conversion data.
This is particularly important with server-side tracking. A CAPI implementation isn’t successful just because the destination API returns a successful response. The actual payload must be inspected.
14. Improving Meta Customer Matching
The original Meta Event Match Quality was approximately: 6.1/10
The website was not exposing enough customer information through the dataLayer. I therefore worked with the developer to make the required customer information available. The implementation eventually made parameters available, including:
- em
- ph
- fn
- ln
- ct
- st
- country
- zp
- external_id
- fbp
- client_ip_address
- client_user_agent
The purpose was not simply to increase the number of fields. Each field had to be available in the right place and pass through the tracking architecture correctly. The broader goal was to improve the quality of the customer information available to Meta for event matching.
15. The DataLayer Became the Foundation of the Solution
The final Purchase structure was substantially more organized. Instead of having isolated ecommerce values, the implementation contained a structured order object. The Purchase data included:
orderData
├── attributes
│ ├── date
│ ├── order_number
│ ├── order_key
│ ├── payment_method
│ ├── payment_method_title
│ ├── shipping_method
│ └── status
│
├── totals
│ ├── currency
│ ├── discount_total
│ ├── shipping_total
│ ├── subtotal
│ └── total
│
├── customer
│ ├── billing
│ └── shipping
│
└── items
├── item_id
├── item_name
├── SKU
├── price
├── category
└── quantity
The project documentation shows this structured Purchase object, including customer hashes and product-level information. This structure gave the tracking implementation a much more reliable source of truth.
16. Validation Strategy
I did not validate the fix by checking only GA4. I performed multiple test orders and verified the events at multiple points.
Browser / GTM
I checked whether the Purchase event appeared correctly in GTM.
Stape
I checked whether the request reached the server-side container and inspected the actual parameters being received.
GA4
I verified that the Purchase information was being sent correctly.
Meta
I verified that Meta was receiving the Purchase event and the associated data.
This multi-layer validation was important because a failure at one stage could otherwise be mistaken for a failure at another.
17. Before vs. After
| Area | Before | After |
| Backend orders | More orders than analytics reported | Tracking aligned more closely with completed orders |
| COD Purchase | Working | Working |
| Online-payment Purchase | Missing | Purchase event implemented/validated |
| DataLayer | Limited and inconsistent | Structured ecommerce/customer data |
| Customer information | Unavailable in dataLayer | Required matching information exposed |
| Transaction ID | Missing/invalid in problematic requests | Correct transaction information available |
| Purchase value | Missing/false in problematic requests | Correct purchase value available |
| Currency | Invalid/zero in problematic requests | Correct currency available |
| Product data | Incomplete | Structured product information |
| Stape | Some purchases absent | Events validated through server-side logs |
| GA4 | Missing purchases | Purchases appearing correctly |
| Meta | Missing purchases | Purchases appearing correctly |
| Attribution | Potentially incomplete | Improved |
| Event Match Quality | 6.1/10 initially | Improved through additional customer data |
| Debugging process | Platform-level symptoms | End-to-end request tracing |
18. The Most Important Diagnostic Insight
The most valuable part of this investigation was not one particular GTM setting. It was the decision to compare actual backend orders against individual tracking events. When I cross-checked each order against Stape logs, I noticed the missing events weren’t random.
The pattern was:
Paid online orders → missing
while:
Cash on Delivery orders → working
That immediately changed the direction of the investigation. Instead of treating the problem as a generic “GA4 isn’t tracking purchases” issue, I could investigate the specific customer journey associated with the missing order type. That led directly to the payment gateway investigation.
19. What Could Have Happened If We Had Not Fixed It?
This issue could have created several significant problems.
19.1 Underreported conversions
If real purchases weren’t sent to GA4 and Meta, reported conversion volume would be lower than the actual number of orders.
The backend could show the business was generating sales while the marketing platforms showed fewer conversions.
19.2 Incorrect revenue reporting
A Purchase event without the correct value or currency can make revenue reporting inaccurate.
Even when the event exists, incorrect parameters can make the conversion effectively unreliable for analysis.
19.3 Poor advertising optimization
Meta and other advertising systems use conversion signals to understand which users and campaigns are producing results. Missing purchases mean fewer useful signals.
That can affect:
- campaign optimization
- audience learning
- attribution
- ROAS analysis
- budget allocation
- conversion reporting
19.4 Poor customer matching
Without customer identifiers such as email, phone, and other matching parameters, server-side events can have weaker matching quality. The original Event Match Quality of 6.1/10 showed room to improve the quality of the customer information being supplied.
19.5 Incorrect business decisions
This is the biggest risk. Suppose the backend actually generated 100 purchases, but analytics recorded 90 purchases. A marketing manager could incorrectly conclude that campaigns generated fewer conversions than they actually did. That could influence decisions about:
- campaign budgets
- audience targeting
- creative performance
- product performance
- channel profitability
In other words, tracking errors can become business decision errors.
20. Why the Fix Was Necessary
The fix was necessary because the problem existed at the foundation of the measurement system. The issue wasn’t simply that Meta needed another parameter. It wasn’t simply that GA4 needed another tag. And it wasn’t simply that Stape needed configuration changes. The fundamental problem was:
The tracking infrastructure didn’t consistently receive the information needed to describe the transaction.
The website backend knew that the order existed. But the measurement architecture needed that transaction to be explicitly represented in the dataLayer and passed through the tracking pipeline. That meant fixing the data source.
21. The Broader CAPI Lesson
A common misconception about server-side tracking is that moving tracking from the browser to a server automatically makes the implementation reliable. It doesn’t. Server-side tracking can improve control, reliability, and data processing, but it still depends on accurate incoming data. The architecture can be represented as:
Website data
↓
DataLayer
↓
Web GTM
↓
Server-side GTM / Stape
↓
GA4 + Meta CAPI
If the information is missing at the beginning, the downstream systems cannot reconstruct it reliably. This investigation reinforced an important principle for me:
Server-side tracking does not eliminate the need for a properly designed client-side data layer.
It makes upstream data quality even more important.
22. My Debugging Methodology
Looking back at the investigation, my approach can be summarized as a sequence:
Step 1 — Start with the business truth
I compared actual backend orders with reported conversions.
Step 2 — Identify the pattern
I noticed that the missing conversions were specifically online-payment orders.
Step 3 — Reproduce the customer journey
I manually followed the online-payment process.
Step 4 — Find the first missing signal
The Purchase event was missing after the online payment flow.
Step 5 — Inspect the data source
I audited the website dataLayer.
Step 6 — Identify missing data
Customer and ecommerce fields were not sufficiently exposed.
Step 7 — Establish a structured data model
I recommended using a WordPress/WooCommerce-style structure as the standard.
Step 8 — Implement and test
I worked with the developer to expose the required data.
Step 9 — Trace the event through the infrastructure
I checked GTM and Stape rather than relying only on destination platforms.
Step 10 — Inspect payload quality
I identified invalid values such as false and 0.
Step 11 — Align variables with the dataLayer
I corrected the underlying data availability so the GTM variables could retrieve the expected values.
Step 12 — Validate repeatedly
I performed multiple test orders and verified the event at both GTM and Stape.
23. What I Learned
The biggest lesson I took from this project was:
A successful HTTP response from Meta doesn’t necessarily mean the event is useful.
A technically successful request can still contain:
- incorrect revenue
- missing transaction ID
- missing currency
- missing product information
- insufficient customer information
The same principle applies to the entire tracking stack.
A Purchase event should not be considered “fixed” merely because it appears somewhere in the logs.
I now look at the complete chain:
Did the order happen?
↓
Did the Purchase event fire?
↓
Did GTM receive the correct data?
↓
Did Stape receive the request?
↓
Did the payload contain the correct values?
↓
Did GA4 receive the correct transaction?
↓
Did Meta receive the correct conversion and matching data?
That is a much stronger definition of a successful CAPI implementation.
24. Conclusion
This investigation started with a simple discrepancy: The website backend showed 3 paid orders, while GA4 and Meta showed only 2.
It could have been treated as a routine analytics discrepancy. Instead, I traced the missing order through the entire tracking architecture. The investigation showed the problem was specifically tied to online payments. Customers completed payment through SSLCommerz and returned to the website, but the required Purchase event wasn’t generated reliably.
The investigation then uncovered a second, deeper problem: the website’s dataLayer was limited and did not expose the customer and ecommerce information required for robust tracking.
That led to the development of a more structured dataLayer based on a WordPress/WooCommerce-style model, including order information, totals, customer data, billing and shipping information, product information, and hashed customer identifiers.
More than seven missing purchases were ultimately identified during the investigation. The final implementation was validated using multiple test orders, with the events checked in both GTM and Stape logs and then verified downstream in GA4 and Meta.
The most important lesson is that conversion tracking is an end-to-end system, not a single tag.
A website can successfully process a payment while analytics never receives a Purchase event. A server can successfully send an API request while the payload contains false or incorrect revenue. Meta can return a successful API response while the event still has poor data quality. Therefore, reliable CAPI implementation requires more than configuring an endpoint.
It requires:
accurate business data → structured dataLayer → correct GTM implementation → reliable server-side processing → valid GA4/Meta payloads → continuous validation.
If this issue had remained unfixed, the business would have continued making marketing decisions based on incomplete conversion data. Paid online orders could have remained invisible to GA4 and Meta, revenue could have been underreported, attribution could have been distorted, customer matching could have remained weaker, and advertising platforms would have received fewer reliable conversion signals.
For me, the biggest takeaway is simple:
The quality of a server-side tracking implementation can never be better than the quality of the data it receives.
That is why the dataLayer was not a secondary development task in this project. It was the foundation of the entire measurement system.
