What should a Meta Conversions API project include?
A Conversions API project is complete when the brand can explain which customer actions are sent, how duplicates are handled, what sharing choices apply and how the result was verified. A connected status or a higher match-quality score is not enough. Start with the existing ecommerce integration before buying custom development, then define acceptance tests that connect real orders to the events used for advertising.
Dahna, original planning diagram
In this article
Overview
A Conversions API project is complete when the brand can explain which customer actions are sent, how duplicates are handled, what sharing choices apply and how the result was verified. A connected status or a higher match-quality score is not enough. Start with the existing ecommerce integration before buying custom development, then define acceptance tests that connect real orders to the events used for advertising.
Find every existing route before adding another
List the Meta integration installed through the commerce platform, any tag manager, theme code, checkout extension and third-party tracking app. Ask each vendor what events it sends and to which dataset. Adding a new server connection without this inventory can create overlapping purchase messages that are difficult to diagnose. Removing an old integration without understanding it can break useful collection.
Shopify’s documentation describes Meta data-sharing options that can include both the pixel and server-side purchase sharing. That makes Shopify a concrete example of why a brand should inspect its supported integration before commissioning custom work. The best scope may be configuration and verification, or it may require engineering for a more complex storefront. The proposal should explain why the chosen route fits your architecture.
| Item | Evidence to collect | Why it matters |
|---|---|---|
| Current Meta connection | Dataset identity, integration owner and configured events | Prevents accidental parallel installations |
| Storefront and checkout | Platforms, domains and unusual purchase paths | Defines where events originate |
| Data-sharing choices | Consent states and approved fields | Defines permitted behavior |
| Operational ownership | Who maintains the connector and credentials | Makes support possible after launch |
Define a purchase before discussing match quality
Agree when an order becomes a purchase event, how value and currency are calculated and which order states are excluded. A paid order, a test checkout, a canceled payment and a later refund are different business events. The implementation team should map the relevant commerce states rather than assuming every checkout screen represents a valid sale.
Also document how the reporting value relates to the brand’s financial view. Shopify notes that its integration’s order-value events use an order total with specified components; a finance report may use net merchandise sales instead. A difference in definitions can look like a tracking error. Keep an explicit reconciliation bridge so the media buyer does not optimize toward a number the owner interprets differently.
One customer action can arrive through two routes
Meta’s platform-authored integration playbook describes matching event names and event IDs to recognize browser and server messages for the same action. Treat the identifier as part of the event contract. A retry for the same purchase should preserve its identity; a genuinely different purchase needs its own identity. The current integration’s supported behavior must be checked during implementation.
Do not ask the owner to approve a screenshot of two incoming events without explaining whether they represent one processed action or two. The acceptance evidence should trace a small set of known test orders from commerce record to browser/server messages and the platform’s deduplication view. Redact customer information from shared evidence. The aim is an inspectable result, not a folder of raw personal data.
A purchase with two delivery routes
Store order
A defined, valid customer action receives an identity.
Browser route
The permitted client event describes that action.
Server route
The permitted server event describes the same action.
Reconciliation
Verify processing, duplication and value against the order.
A completed acceptance exercise for a fictional store
Suppose a fictional beauty brand finds 120 purchase messages for 60 known orders during a controlled test period. That ratio is a reason to inspect processing, not proof that reporting is doubled: browser and server messages can both be received and then deduplicated. The reviewer follows several known order IDs and checks whether the final processed actions align with the intended contract.
Next, the team deliberately repeats an allowed server delivery for the same test action, completes a different order, reloads the confirmation page and tries relevant consent states. Each scenario has an expected result written before execution. The store also tests a discount and a different supported currency. These exercises expose issues that a simple “event received” badge cannot answer.
| Scenario | Expected business behavior | Evidence |
|---|---|---|
| One valid paid order | One purchase action under the agreed contract | Order record plus processed-event trace |
| Retry of the same event | No second business purchase | Stable identity and processing evidence |
| A second distinct order | A second purchase action | Different order/event identity |
| Confirmation-page reload | No accidental additional purchase | Reload test with known order |
| Changed sharing choice | Behavior follows approved configuration | Recorded consent-state test |
| Discounted order | Value follows documented definition | Reconciled amount and currency |
A server connection does not remove sharing decisions
The fact that information travels from a server does not answer whether it should be shared. The brand needs an approved field list, appropriate handling of customer choices and a clear owner for policy questions. Shopify’s guidance explicitly treats data sharing as a choice and asks merchants to explain their practices. Have the responsible privacy or legal owner review the intended behavior where needed.
The project brief should exclude unrelated sensitive information and specify how credentials and diagnostic records are protected. Agency access should be limited to the work being performed, with ownership remaining clear. A custom integration also needs error monitoring, retry behavior, maintenance responsibility and a plan for platform changes. Those operating costs belong in the proposal before the build begins.
Define failure handling before the integration goes live
Ask what happens when the server connection is temporarily unavailable. A custom implementation may need queued delivery, controlled retries and an alert, while a supported connector may handle those functions internally. The brand still needs to know who investigates a gap and what evidence is available. A purchase that arrives later should not quietly become a new purchase with a new identity just because the delivery attempt was retried.
Include a recovery exercise in the acceptance scope where the architecture permits it safely. The developer can demonstrate a controlled failed delivery and show how the same business action is recovered. The media team should also know how to mark a measurement outage in its change log so a temporary reporting decline is not immediately blamed on creative or bids. This connects engineering reliability with the advertising decisions the project is meant to support.
Finally, agree on what happens when the store changes. A new checkout, payment provider, subscription flow or headless storefront can alter the event source. The handover should identify changes that trigger a fresh review. An integration that was correct at launch can become incorrect without anyone editing the advertising account. Maintenance ownership therefore belongs in the buying decision, alongside the initial implementation fee and the evidence used to accept the work.
Require a handover that survives the developer leaving
Request an architecture sketch, event dictionary, configuration record, acceptance results and a short troubleshooting guide. The guide should explain who is alerted when events stop, how to compare a known order with the platform view and how to roll back a faulty change. Set a follow-up review after real traffic has exposed ordinary variations in devices, payment methods and consent states.
Bring Dahna the current store platform, Meta connection and the specific reporting problem you want solved. We can help define the advertising requirements and coordinate the implementation review. Judge the project by trustworthy event behavior and usable ownership, then evaluate campaign outcomes separately. Better measurement can reveal less flattering performance; that can still be a successful implementation because the next budget decision becomes more reliable.
Continue with the related decision
Use these guides when the next question goes beyond the scope of this article.
Use the editable decision sheet
Download the completed tables as a CSV, then replace the example inputs and add your evidence, owner and review date. Illustrative figures are teaching examples, not default targets.
Sources & further reading
Bring this decision to Dahna
Use this guide to prepare a focused brief. Tell Dahna what needs to change, which evidence you already have and when you need a decision.
Why consider Dahna for this work?
Dahna brings bilingual Korean and English strategy together with creator, content, and measurement work for brands growing in the US. You can review the people behind the recommendations and the kind of work we propose before starting a conversation.
Founder experience includes prior and contracted roles. Sample deliverables illustrate our approach; they are not client results or a performance promise.
