In brief: An active CAPI connection does not prove that purchase reporting is correct. Check browser/server duplication, consent, data fields, infrastructure, plugin behaviour, monitoring and the complete buying journey. Start with confirmed orders before changing campaign budgets.
Server-side tracking moves part of event processing into a server environment. It can improve delivery control, but cannot recover information you have no basis to collect. Applicable privacy requirements depend on the business, customers and data flows, rather than the language your team speaks.
1. The same purchase arrives twice
Pixel and Conversions API can deliver two copies of one purchase. Meta’s official SDK identifies matching events using both event_name and event_id.
Generate the identifier once for the business event and reuse it across browser, server and delivery retries. A timestamp generated independently by each sender breaks that relationship. Different events need different identifiers; avoid embedding personal information in IDs. Reloading the confirmation page must not create a new purchase.
Illustrative arithmetic: €4,000 spent for 100 real purchases means €40 per purchase. If a report incorrectly counted 200, it would display €20. This assumes duplication in that report; incoming event totals are not automatically attributed advertising conversions. Check value, currency and payment status too: correct deduplication alone does not validate them.
2. Hosting is chosen without mapping the data
An EU server is one infrastructure choice, not proof that every recipient, log or transfer meets legal requirements. Equally, hosting outside the EU is not automatically prohibited. List sources, destinations, processor roles, access, retention and deletion, then assess international transfers separately with appropriate legal support. The Commission’s transfer guidance explains safeguards; it does not certify a particular installation.
For Google Cloud Run, europe-west1 is Belgium and europe-west3 Frankfurt; Stape also offers EU hosting. Compare the actual processing chain, operating cost and measured latency. During migration, test the domain, request handling, container configuration and rollback. There is no universal one-hour migration or fixed transatlantic delay. Follow Google’s Cloud Run setup guide.
3. Consent stops at the browser
A banner may block browser marketing tags while a backend sends the same customer data. Test rejection, acceptance, partial choices, withdrawal and reload across the whole chain, including stored settings and outbound server requests.
Google’s server-side consent guidance concerns consent signals and consent-aware Google tags. Custom Meta or TikTok integrations need their own applicable forwarding rules. A field called consent_state is not a universal solution. Cookieless transmission is not automatically anonymous or lawful; distinguish necessary processing from optional advertising using the applicable rules, including the Austrian DSB’s cookie guidance.
4. Matching fields are collected without a purpose
For each field, document its source, purpose and processing basis. Check placeholders, telephone/country formats and irrelevant or sensitive data before adding identifiers to improve Event Match Quality.
The Meta SDK’s field handling distinguishes normalised and hashed fields such as email and phone from IP address, user agent, fbc and fbp, which are not hashed in the same way. Follow the specification for the chosen integration; do not blindly lowercase and hash everything. Hashing does not make personal data anonymous. EMQ is a diagnostic indicator, not a universal pass mark or promised reduction in CPM.
5. A plugin is treated as a finished system
A standard integration may fit a standard shop. Shopify’s Enhanced and Maximum sharing settings already use CAPI alongside Pixel. Custom tracking should address an observed gap, rather than replace a working plugin by default.
Check paid versus unpaid orders, cancellations, refunds, currency, consent and repeated page loads. Remove obsolete duplicate Pixel installations in a controlled change. After CMS, checkout, CMP or plugin updates, repeat the scenarios and record the version, owner and rollback procedure. A plugin badge is not evidence that your business rules are implemented.
6. Nobody monitors the integration after launch
Teaching scenario: a theme update changes the confirmation page and purchase delivery stops. A successful launch test cannot detect that later fault. Monitor delivery errors, freshness, missing IDs, currency/value totals and differences against confirmed shop or CRM orders. Account for seasonality and differences in attribution windows.
Set alerts from your own stable baseline. A weekly reconciliation is a useful operating routine, with extra checks after relevant changes. EMQ can supplement it where available. Verify API fields and permissions before promising an automated EMQ export; neither a score of seven nor a 20% volume change is a universal alarm rule.
7. Only the endpoint is tested
An accepted API request proves less than a complete purchase journey. Start with local or staging checks; send platform test events or production orders only with the appropriate authorization. Server-container Preview, Meta Test Events and GA4 DebugView/Realtime answer different diagnostic questions.
On desktop and mobile, cover these seven paths:
- A new visitor rejects optional cookies.
- The visitor accepts them.
- The visitor changes that choice.
- An order is paid successfully.
- Payment fails or an order is cancelled/refunded.
- The confirmation page is reloaded.
- The same visitor returns from another channel.
Compare the interface, requests, server logs, platform receipts and confirmed sales source for each. A green test event is not legal clearance or proof of attribution.
Seven errors at a glance
| Error | Consequence and first check |
|---|---|
| Different event names/IDs | Inflated counts; trace one purchase across both senders |
| No data-flow map | Unclear recipients/retention; inventory every destination |
| Browser-only consent | Choice not applied; test all states through the server |
| Unnecessary matching fields | Excess collection/bad formats; review each field |
| Untested plugin logic | Wrong purchase status; test payment, refund and reload |
| No monitoring | Undetected changes; reconcile volume, values, IDs and delay |
| Endpoint-only test | Incomplete journey; exercise all seven paths on both devices |
What to fix first
Correct duplicated and false purchases first, then verify consent and permissible data flows. Follow with matching fields, monitoring and reporting. For the wider architecture, see the server-side tracking guide and CPA analysis.
Frequently Asked Questions
Which error should we investigate first?
Start with the mismatch that affects confirmed purchases: duplicates, incorrect payment status, value or currency. There is no verified universal ranking of how often these faults occur.
How do we find errors in an existing setup?
Trace a permitted test order through browser, server, platform and shop records. Repeat consent and failure paths, then compare larger totals using consistent periods and definitions.
Can server-side tracking bypass a visitor’s refusal?
No. A different technical route does not create a processing basis. Apply the applicable consent or other lawful basis throughout the chain.
What is a good Event Match Quality score?
There is no universal score that proves success. Correct events, permissible fields and reconciliation with confirmed results matter more than raising a diagnostic indicator through unnecessary collection.
Are events in Events Manager sufficient evidence?
No. Check deduplication, consent, payment status, value and currency against confirmed shop or CRM records, including behaviour after updates.
Is a Shopify or WooCommerce plugin enough?
Sometimes. Test its actual handling of payment, refunds, consent, currency and duplication. Standard integration can be suitable; custom development needs a concrete reason.
How often should CAPI be checked after launch?
After checkout, CMP, GTM, domain or plugin changes, and through regular reconciliation. Weekly review is a practical routine; alert thresholds should follow your own baseline.
How long do repairs take?
A single configuration fault may be quick to fix. Missing business logic, infrastructure changes and consent integration need investigation and retesting. Agree the scope before estimating time or financial benefit.
If shop, CRM and advertising numbers disagree, describe the systems and what counts as a confirmed sale. We can define the events and access needed for a scoped review. Describe the discrepancy.
