Facebook Conversion API सेटअप for Affiliates: 2026 Guide

Step 1: Events Send करने से पहले Conversion Contract Define करें

Conversion contract लिखित नियम है जो तय करता है कि हर event का मतलब क्या है, वह कब fire होगा, और payload में कौन से fields allowed हैं। इस contract के बिना, CAPI एक messy funnel को बस एक faster messy funnel में बदल सकता है।

केवल वे Events चुनें जिन्हें आप Prove कर सकते हैं

अधिकांश affiliate funnels को चार standard events से शुरू करना चाहिए: ViewContent, Lead, InitiateCheckout, और Purchase। CompleteRegistration तभी जोड़ें जब funnel में एक वास्तविक registration step हो जो पहले से Lead द्वारा capture न किया गया हो।

हर micro-action के लिए custom events मत बनाइए। Meta कम, लेकिन ज़्यादा consistent events से बेहतर optimize कर सकता है, बजाय एक लंबी list के weak signals के जो offer से offer बदलते रहते हैं।

हर Event को एक Business Action से Map करें

हर event की एक ही business definition होनी चाहिए। उदाहरण के लिए, Lead का मतलब हो सकता है आपके presell page से submit किया गया और validated opt-in, जबकि Purchase का मतलब network postback या checkout confirmation से आया confirmed paid conversion हो सकता है।

हर event के लिए source of truth document करें:

Identifiers एक बार Define करें

event_id, event_time, और action_source generate करने के लिए shared event layer का उपयोग करें। Browser event और server event से same event_id भेजें ताकि Meta उन्हें एक action के रूप में deduplicate कर सके।

event_time के लिए Unix epoch seconds का उपयोग करें। एक व्यावहारिक operating rule के रूप में, events को action के जितना संभव हो उतना करीब भेजें; delayed events स्वीकार किए जा सकते हैं, लेकिन stale conversion data bidding और troubleshooting के लिए कम उपयोगी होता है।

Step 2: Pixel और CAPI को Lockstep में रखें

Pixel और CAPI को दो delivery paths के माध्यम से एक ही real-world action describe करनी चाहिए। अगर वे अलग definitions पर fire करते हैं, तो deduplication unreliable हो जाता है और reporting inflate हो सकती है।

पहले Pixel Coverage Confirm करें

Server events बनाने से पहले, verify करें कि Pixel उन funnel pages पर fire होता है जो महत्वपूर्ण हैं: landing page, key intent step, checkout entry, और confirmation। Test sessions के दौरान event name, URL, timestamp, value, currency, और generated event_id record करें।

यह server-side काम के लिए baseline भी देता है। अगर browser path पहले से ही गलत fire कर रहा है, तो CAPI underlying event logic को ठीक नहीं करेगा।

एक Shared Correlation Token बनाएं

Page load होने पर या user session शुरू होते ही correlation token generate करें। जहाँ कानूनी और तकनीकी रूप से संभव हो, उसे landing pages, forms, checkout redirects, और postbacks में pass करें।

यह token Meta-required fields का replacement नहीं होना चाहिए, लेकिन debugging के दौरान browser logs, server logs, network postbacks, और ad platform diagnostics को reconcile करने का तरीका देता है।

Campaign Context को Normalize करें

Traffic context को stable fields में store करें: source, campaign, ad set, ad, creative, placement, affiliate ID, offer ID, और funnel variant। एक consistent naming system का उपयोग करें, जैसे आपका UTM decoding process, ताकि paid media और affiliate reporting को बिना manual cleanup के compare किया जा सके।

हर available parameter को custom_data में मत डालिए। केवल वे fields भेजें जो attribution, value, funnel state, या optimization quality को verify करने में मदद करें।

Step 3: Consent-Aware Payloads बनाएं

एक अच्छा CAPI payload technical रूप से उपयोगी भी होता है और privacy-conscious भी। इसमें सबसे मजबूत permitted matching fields होने चाहिए, लेकिन केवल तब जब उस user और region के लिए collection और transmission lawful हों।

Minimum Required Shape से शुरुआत करें

Optional fields जोड़ने से पहले base payload बनाकर test करें:

• event_name
• event_time
• event_source_url
• action_source
• event_id
• user_data
• custom_data

Purchases के लिए, जब value reliable हो तो currency और value शामिल करें। Delayed approvals वाले affiliate offers के लिए, internal reporting में estimated conversion value और approved payout को अलग करें।

User Data को सही तरीके से Normalize और Hash करें

Hashing से पहले email addresses और phone numbers को normalize करना चाहिए। उदाहरण के लिए, whitespace trim करें, email addresses को lowercase करें, और जब hashing required हो तब SHA-256 लागू करने से पहले phone numbers को consistent format में रखें।

Values को double-hash न करें। जो field दो बार hash की गई हो, वह आम तौर पर omitted field से भी खराब होती है, क्योंकि वह intended तरीके से match नहीं कर सकती और diagnose करना कठिन होता है।

Data Path में Consent Encode करें

Consent payload बनाने से पहले enforce होना चाहिए, event भेजने के बाद review नहीं। अगर consent missing है, तो केवल वे fields भेजें जिन्हें आपकी policy अनुमति देती है, या जब आपकी legal basis और regional rules की आवश्यकता हो तो event suppress करें।

इसे अपने compliance process में mapped रखें, जिसमें legal and compliance checks शामिल हैं। Technical teams यह देख सकें कि कोई field क्यों शामिल, छोड़ी, या block की गई।

Step 4: Retries और Deduplication के साथ Events Transmit करें

Transmission quality महत्वपूर्ण है क्योंकि एक real conversion को platform पर एक ही event बनना चाहिए। बेहतर optimization और inflated reporting के बीच व्यावहारिक अंतर disciplined deduplication है।

सही Integration Path चुनें

तीन common implementation paths हैं:

अगर आपकी team पहले से Google Tag Manager server containers इस्तेमाल करती है, तो अलग relay चुनने से पहले इस workflow की तुलना अपने server-side GTM setup से करें।

केवल सही Failures को Retry करें

Timeouts या temporary server errors जैसी transient transport failures के लिए retries implement करें। Malformed events को पहले validation error ठीक किए बिना retry न करें।

एक practical retry pattern है: तुरंत send करें, एक short retry, एक delayed retry, फिर review के लिए dead-letter log। Requests IDs, event IDs, response codes, और payload version logs में रखें ताकि failures audit किए जा सकें।

Event ID से Deduplicate करें

Pixel event और matching CAPI event दोनों के लिए same event_id का उपयोग करें। साथ ही event ID और business action keyed एक short-lived server-side cache रखें ताकि आपका अपना system एक ही conversion बार-बार न भेजे।

एक अनुमान के रूप में, एक healthy implementation को sustained duplicate leakage इतना कम रखना चाहिए कि वह optimization decisions को न बदले। अगर checkout refreshes, postback retries, या delayed network approvals के आसपास duplicates दिखें, तो तुरंत जांच करें।

Step 5: Scaling से पहले Signal Quality Validate करें

CAPI का मूल्यांकन इस आधार पर न करें कि events dashboard में दिख रहे हैं या नहीं। इसका मूल्यांकन इस आधार पर करें कि accepted events accurate, deduplicated, timely, और bidding के लिए उपयोगी हैं या नहीं।

Controlled Test Sessions चलाएँ

पूर्ण traffic भेजने से पहले known sessions के साथ हर event type test करें। Browser event, server event, event ID, timestamp, URL, value, consent state, और expected outcome capture करें।

Negative tests भी चलाएँ। Abandoned checkouts, declined cards, invalid forms, और rejected affiliate conversions को successful purchases या leads नहीं माना जाना चाहिए।

Realistic Ranges वाले Health Metrics उपयोग करें

Exact numbers vertical, geography, device mix, और consent rate के अनुसार बदलते हैं, इसलिए इन्हें universal benchmarks नहीं बल्कि operating estimates मानें।

सही क्रम में Debug करें

Meta Events Manager diagnostics और test events से शुरू करें। फिर अपने Event Match Quality process, server logs, network postback records, और ad account reporting की समीक्षा करें।

Broken tracking की भरपाई के लिए bids न बदलें। पहले event definitions, payload fields, dedupe, और consent handling ठीक करें।

Step 6: Affiliate Scaling Decisions में CAPI लागू करें

Affiliate teams को हर test को same depth के साथ instrument नहीं करना चाहिए। Deep tracking तब सबसे मूल्यवान होता है जब offer के पास repeatable economics का evidence हो।

Offers को Operating State के अनुसार Sort करें

Tracking investment तय करने से पहले हर offer को classify करें:

• Pre-scale: शुरुआती test volume, unstable CPA, और conversion proof सीमित।
• Scaling: repeatable conversion rate, stable CPA trend, और सीखने के लिए पर्याप्त volume।
• Saturated: बढ़ता CPA, कमजोर creative response, या repeated windows में capped volume।

Daily Intel Service यहाँ उपयोगी है क्योंकि यह operators को live scaling behavior और stale public snapshots के बीच अंतर करने में मदद करता है। इससे engineering time ऐसे offers पर खर्च होने की संभावना कम होती है जो पहले ही fade हो रहे हैं।

External Signals का सावधानी से उपयोग करें

Meta Ad Library यह verify करने में मदद कर सकता है कि advertisers अभी creative चला रहे हैं या नहीं, लेकिन यह profitability, spend, या conversion rate साबित नहीं करता। इसे directional signal मानें, अपने funnel data का replacement नहीं।

AdSpy, BigSpy, या Anstrex जैसे competitor tools creative research में मदद कर सकते हैं, लेकिन उन्हें यह तय नहीं करना चाहिए कि आपका CAPI implementation काम कर रहा है या नहीं। आपके अपने event logs और approved conversion data ही source of truth हैं।

Tracking को Media Operations से जोड़ें

CAPI checks को media buyer rollout process का हिस्सा बनाएं। एक practical routine है: शुरुआती tests के लिए light tracking, scaling candidates के लिए deeper CAPI validation, और paused या saturated offers से जुड़े events के लिए weekly cleanup।

Daily Intel Service उपयोग करने वाली teams के लिए सबसे मजबूत workflow यह है कि budget बढ़ाने से पहले offer-state intelligence को internal CAPI health checks के साथ combine किया जाए। यदि आपको इस classification के पीछे का decision framework चाहिए, तो Daily Intel Service methodology देखें।

Step 7: Launch के बाद Governance बनाए रखें

CAPI एक one-time setup नहीं है। इसे versioning, monitoring, और ownership चाहिए क्योंकि funnel pages, checkout providers, affiliate postbacks, और platform validation rules बदलते रहते हैं।

हर Funnel के लिए One-Page Runbook रखें

हर funnel के पास एक runbook होना चाहिए जिसमें event map, payload schema, consent rules, owner, postback source, retry policy, rollback plan, और last validation date हो। यह सरल है, लेकिन debugging को memory पर निर्भर होने से बचाता है।

जब भी offer URL, checkout flow, lead form, tracking domain, या payout rule बदले, runbook अपडेट करें।

Schema Drift पर नज़र रखें

Schema drift तब होता है जब आपको लगता है कि आप जो payload भेज रहे हैं, वह अब Meta तक पहुंचने वाला payload नहीं रहता। Common causes में नए form fields, checkout changes, relay provider updates, और network postback changes शामिल हैं।

Payload versions बनाए रखें और deployments से पहले और बाद acceptance rate, match quality, और duplicate behavior की तुलना करें। अगर किसी release के बाद acceptance गिर जाए, तो campaign strategy बदलने से पहले tracking change वापस लें।

User Trust को केंद्र में रखें

Server-side tracking का उपयोग user choice या platform policy को bypass करने के लिए नहीं किया जाना चाहिए। जब guidance या internal playbooks publish करें, तो अपनी implementation को Meta की Conversions API documentation, Meta ad standards, और Google के helpful content principles के साथ align करें।

CAPI का टिकाऊ संस्करण सरल है: कम noise collect करें, साफ़ events भेजें, consent का सम्मान करें, और केवल तभी scale करें जब funnel economics गहरे instrumentation को justify करें।

Frequently Asked Questions

Q: Facebook Conversions API क्या है?
A: Facebook Conversions API Meta का server-side event interface है, जो web, app, या offline conversion events को सीधे आपके server या approved integration से Meta तक भेजता है।

Q: क्या affiliates को CAPI के साथ भी Pixel चाहिए?
A: हाँ। अधिकांश affiliate setups को Pixel और CAPI दोनों का उपयोग करना चाहिए, फिर समान event_id से matching events को deduplicate करना चाहिए। Pixel browser context देता है, जबकि browser signals सीमित होने पर CAPI resilience बढ़ाता है।

Q: एक affiliate को किन events से शुरू करना चाहिए?
A: ViewContent, Lead, InitiateCheckout, और Purchase से तभी शुरू करें जब हर event एक वास्तविक funnel action से map होता हो। बुनियादी events की accuracy साबित होने के बाद ही और events जोड़ें।

Q: Duplicate conversions कैसे रोकूँ?
A: वास्तविक action के लिए एक event_id generate करें, वही ID browser और server paths से भेजें, और postback retries या checkout refreshes के लिए server-side idempotency controls रखें।

Q: Scaling spend से पहले क्या validate करना चाहिए?
A: Event definitions, payload acceptance, event timing, deduplication, consent handling, और approved conversion reconciliation validate करें। केवल इसलिए budget न बढ़ाएँ कि CAPI events Meta Events Manager में दिख रहे हैं।

Q: क्या Event Match Quality tracking quality के समान है?
A: नहीं। Event Match Quality अनुमति प्राप्त matching fields की strength दर्शाता है, लेकिन tracking quality accurate event logic, deduplication, timeliness, और clean conversion value handling पर भी निर्भर करती है।