A working storefront pixel and a complete server measurement path are separate things to verify. This checklist covers fourteen areas, including the evidence you can inspect publicly and the private configuration and order records needed to complete the diagnosis.
The list began as a short audit rubric. Its earlier numeric pass bands were local choices rather than universal platform requirements. Use the controlled event and order evidence below to decide what is actually failing.
The fourteen checks
1. Browser event coverage
Test the homepage, product page, cart, and completed order flow. Inspect the network and the installed integration rather than assuming a missing fbq string in static HTML proves an absent pixel. Shopify's pixel sandbox and GTM can change where the event is visible.
2. Server event delivery
Verify recent server events in the actual sending system and Meta's diagnostics. A configured container does not establish delivery. Use a controlled purchase to connect an order with the emitted event and its processing result.
Public storefront checks can identify visible tracking setup. Server delivery still needs Events Manager or server logs. Run the free tracking scan to start with the public surface.
3. Browser and server deduplication
Inspect the event name and event ID used for the browser and server copies of one action. Check that retries preserve the intended identity. Review the platform's diagnostic result alongside the actual payload; an aggregate percentage alone cannot diagnose a duplicate.
4. Identifier normalization and hashing
Check each customer information field against its current format and hashing contract. Keep raw identifiers out of debugging logs. fbp and fbc use a different forwarding path from hashed email and phone fields.
5. Browser and server coverage differences
Record which controlled purchases reached each path under the tested browser and consent conditions. Investigate a missing delivery with its logs. A fixed server only percentage cannot describe every store's traffic.
6. Match quality diagnostics
Record the event type, reporting period, identifier coverage, and warnings. A score can prompt a closer inspection. It does not directly measure revenue recovered or a CPM increase.
7. Relevant event coverage
List the events the business intends to measure and test each against its triggering action. A store with subscriptions has a different lifecycle from a store selling only individual purchases. Maintain the list with the event schema.
8. Available matching parameters
Identify the values available and permitted for each event. Check guest and authenticated paths separately. A count of fields is less useful than evidence that the intended values are valid and reach the sender.
9. Current Shopify checkout integration
Inspect the current checkout and order confirmation configuration for this store and plan. Complete a purchase and trace its event through the configured integrations. Legacy customization deadlines varied by plan and surface; verify the actual installation.
10. Value and currency alignment
Compare the order with the payload using the business's chosen revenue definition. Specify tax, shipping, discounts, presentment currency, and reporting currency. A disagreement can reflect a definition difference or an implementation defect.
11. Refund handling
Trace how an order adjustment reaches the reporting model. A refund is not automatically a negative Meta Purchase event. Verify the supported event and reconciliation process before adding a sender.
12. Privacy choices and delivery gates
Test the choices that apply to each integration and jurisdiction. Google Consent Mode settings configure Google behavior; Meta events need their own reviewed handling. Check browser collection and queued server forwarding against the requirement.
13. Integration conflicts
Inventory the native Shopify channel, pixels, GTM containers, custom handlers, and attribution apps. Inspect which of them can send the same event. Assign an owner to the event contract and verify how duplicate delivery is prevented or deduplicated.
14. Cross platform reconciliation
Compare Shopify orders with platform events under documented filters, currencies, windows, and refund rules. Investigate specific unmatched orders or payload differences. A fixed percentage gap alone does not establish a broken system.
Prioritize from the evidence
Start with missing deliveries and duplicated events, then inspect invalid identifiers and incorrect values. A public scan can locate visible signals, while the completed review needs the private evidence for those paths. The CAPI Leak Report describes the current diagnostic scope.
Keep the wider context in the CAPI field guide, and use the purchase count reconciliation guide when the question crosses platform definitions.
The acceptance record before cutover
The same checklist needs a launch record. For each relevant event, capture the browser event, the server event, the shared identifier, the reported value and currency, and the consent decision used by each path. Save evidence from a controlled test order before relying on aggregate scores.
Start with the integration inventory. Record the Shopify native channel configuration, web pixels, GTM containers, custom handlers, and any attribution app that can send a Meta event. Assign one owner to each event path. If two integrations send the same purchase, verify the shared event name and ID deliberately. An installed app is a reason to inspect the payload, rather than proof that it creates a duplicate.
Run a completed purchase through the current checkout and order confirmation flow. Confirm the server receives the event and inspect the processing result. Compare product value, tax, shipping, currency, and refund treatment against the written reporting definition. Different definitions can explain a revenue gap even when delivery works.
The earlier readiness list used 8.5, 6.5, and 9.1 as score thresholds. Those numbers came from the article's rubric and reported engagement results. They are not universal Meta launch requirements. A match quality score is one diagnostic input. Pair it with event delivery, identifier validity, deduplication evidence, and the platform warnings for that event.
Meta's parameter builder documentation distinguishes normalized and hashed customer information from fields such as fbp and fbc. The latter are forwarded without another hash. Verify those field rules in the payload you plan to release.
Write down who approves cutover, the rollback path, and the first production verification window. Repeat the controlled order after release and compare it with the saved sample. That acceptance record is the part an automatically generated storefront scan cannot produce without access to the private event and order evidence.