ਅਫ਼ਿਲੀਏਟਾਂ ਲਈ Facebook Conversion API ਸੈੱਟਅੱਪ: 2026 ਗਾਈਡ

ਕਦਮ 1: Event ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ Conversion Contract ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

Conversion contract ਲਿਖਿਆ ਹੋਇਆ ਨਿਯਮ ਹੈ ਕਿ ਹਰ event ਦਾ ਕੀ ਅਰਥ ਹੈ, ਉਹ ਕਦੋਂ fire ਕਰੇਗਾ, ਅਤੇ payload ਵਿੱਚ ਕਿਹੜੇ field ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਇਸ contract ਦੇ ਬਿਨਾ CAPI ਇੱਕ ਗੁੰਝਲਦਾਰ funnel ਨੂੰ ਹੋਰ ਤੇਜ਼ ਗੁੰਝਲਦਾਰ funnel ਬਣਾ ਸਕਦਾ ਹੈ।

ਸਿਰਫ਼ ਉਹੀ Event ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ

ਜ਼ਿਆਦਾਤਰ ਅਫ਼ਿਲੀਏਟ funnel ਨੂੰ ਚਾਰ standard event ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ViewContent, Lead, InitiateCheckout, ਅਤੇ Purchase। CompleteRegistration ਤਦੋਂ ਹੀ ਜੋੜੋ ਜਦੋਂ funnel ਵਿੱਚ ਇੱਕ ਅਸਲੀ registration step ਹੋਵੇ ਜੋ ਪਹਿਲਾਂ ਹੀ Lead ਨਾਲ capture ਨਾ ਹੋਈ ਹੋਵੇ।

ਹਰ micro-action ਲਈ custom event ਬਣਾਉਣ ਤੋਂ ਬਚੋ। Meta ਘੱਟ, ਹੋਰ consistent event ਤੋਂ weak signal ਦੀ ਲੰਬੀ ਸੂਚੀ ਨਾਲੋਂ ਵਧੀਆ optimize ਕਰ ਸਕਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ offer ਤੋਂ offer signal ਬਦਲਦੇ ਹਨ।

ਹਰ Event ਨੂੰ ਇੱਕ Business Action ਨਾਲ ਜੋੜੋ

ਹਰ event ਦੀ ਇੱਕ ਹੀ business definition ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Lead ਦਾ ਅਰਥ ਹੋ ਸਕਦਾ ਹੈ ਤੁਹਾਡੇ presell page ਤੋਂ ਭੇਜਿਆ ਗਿਆ ਇੱਕ validated opt-in, ਜਦਕਿ Purchase ਦਾ ਅਰਥ ਹੋ ਸਕਦਾ ਹੈ network postback ਜਾਂ checkout confirmation ਤੋਂ ਪੁਸ਼ਟੀਤ paid conversion।

ਹਰ event ਲਈ source of truth ਦਰਜ ਕਰੋ:

Identifier ਇੱਕ ਵਾਰ ਹੀ ਨਿਰਧਾਰਤ ਕਰੋ

event_id, event_time, ਅਤੇ action_source ਬਣਾਉਣ ਲਈ ਇੱਕ shared event layer ਵਰਤੋ। browser event ਅਤੇ server event ਤੋਂ ਇੱਕੋ event_id ਭੇਜੋ ਤਾਂ ਕਿ Meta ਉਹਨਾਂ ਨੂੰ ਇੱਕ action ਵਜੋਂ dedupe ਕਰ ਸਕੇ।

event_time ਲਈ Unix epoch seconds ਵਰਤੋ। ਵਿਆਵਹਾਰਿਕ ਨਿਯਮ ਵਜੋਂ, event ਨੂੰ action ਦੇ ਜਿੰਨਾ ਨੇੜੇ ਹੋ ਸਕੇ ਉਨ੍ਹਾਂ ਭੇਜੋ; ਦੇਰ ਨਾਲ ਆਏ event ਫਿਰ ਵੀ accept ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਪੁਰਾਣਾ conversion data bidding ਅਤੇ troubleshooting ਲਈ ਘੱਟ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ।

ਕਦਮ 2: Pixel ਅਤੇ CAPI ਨੂੰ Lockstep ਵਿੱਚ ਰੱਖੋ

Pixel ਅਤੇ CAPI ਨੂੰ ਦੋ delivery path ਰਾਹੀਂ ਇੱਕੋ ਅਸਲੀ ਦੁਨੀਆ ਦੀ action ਦਾ ਵਰਣਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਉਹ ਵੱਖ-ਵੱਖ definition 'ਤੇ fire ਕਰਦੇ ਹਨ, ਤਾਂ deduplication ਅਣਭਰੋਸੇਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ reporting ਵਧੀ ਹੋਈ ਲੱਗ ਸਕਦੀ ਹੈ।

ਪਹਿਲਾਂ Pixel Coverage ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

Server event ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ Pixel ਉਹਨਾਂ funnel page 'ਤੇ fire ਕਰਦਾ ਹੈ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹਨ: landing page, key intent step, checkout entry, ਅਤੇ confirmation। test session ਦੌਰਾਨ event name, URL, timestamp, value, currency, ਅਤੇ ਬਣਾਇਆ ਗਿਆ event_id ਦਰਜ ਕਰੋ।

ਇਹ ਤੁਹਾਨੂੰ server-side ਕੰਮ ਲਈ baseline ਵੀ ਦਿੰਦਾ ਹੈ। ਜੇ browser path ਪਹਿਲਾਂ ਹੀ ਗਲਤ fire ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ CAPI ਮੂਲ event logic ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ।

ਇੱਕ Shared Correlation Token ਬਣਾਓ

Page load ਹੋਣ 'ਤੇ ਜਾਂ user session ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਇੱਕ correlation token ਬਣਾਓ। ਜਿੱਥੇ ਕਾਨੂੰਨੀ ਅਤੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੋਵੇ, ਉਸ ਨੂੰ landing page, form, checkout redirect, ਅਤੇ postback ਰਾਹੀਂ ਲੰਘਾਓ।

ਉਹ token Meta-ਲਾਜ਼ਮੀ field ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਪਰ debugging ਦੌਰਾਨ browser log, server log, network postback, ਅਤੇ ad platform diagnostic ਮਿਲਾਉਣ ਲਈ ਤੁਹਾਡੀ team ਨੂੰ ਇੱਕ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ।

Campaign Context ਨੂੰ Normalize ਕਰੋ

Traffic context ਨੂੰ ਸਥਿਰ field ਵਿੱਚ ਸਟੋਰ ਕਰੋ: source, campaign, ad set, ad, creative, placement, affiliate ID, offer ID, ਅਤੇ funnel variant। ਆਪਣੀ UTM decoding ਪ੍ਰਕਿਰਿਆ ਵਰਗਾ consistent naming system ਵਰਤੋ ਤਾਂ ਜੋ paid media ਅਤੇ affiliate reporting manual cleanup ਬਿਨਾ ਤੁਲਨਾ ਕੀਤੇ ਜਾ ਸਕਣ।

ਹਰ ਉਪਲਬਧ parameter ਨੂੰ custom_data ਵਿੱਚ ਨਾ ਸੁੱਟੋ। ਉਹ field ਭੇਜੋ ਜੋ attribution, value, funnel state, ਜਾਂ optimization quality ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਕਦਮ 3: Consent-Aware Payload ਬਣਾਓ

ਇੱਕ ਵਧੀਆ CAPI payload ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਲਾਭਕਾਰੀ ਅਤੇ privacy-conscious ਦੋਵੇਂ ਹੁੰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਮਨਜ਼ੂਰਸ਼ੁਦਾ matching field ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਕੇਵਲ ਤਦੋਂ ਜਦੋਂ ਉਸ user ਅਤੇ region ਲਈ collection ਅਤੇ transmission ਕਾਨੂੰਨੀ ਹੋਵੇ।

ਘੱਟੋ-ਘੱਟ Required Shape ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

Optional field ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ base payload ਬਣਾਓ ਅਤੇ test ਕਰੋ:

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

Purchase ਲਈ, ਜਦੋਂ value ਭਰੋਸੇਯੋਗ ਹੋਵੇ ਤਾਂ currency ਅਤੇ value ਸ਼ਾਮਲ ਕਰੋ। delayed approval ਵਾਲੇ affiliate offer ਲਈ, internal reporting ਵਿੱਚ estimated conversion value ਅਤੇ approved payout ਨੂੰ ਵੱਖ ਕਰੋ।

User Data ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ Normalize ਅਤੇ Hash ਕਰੋ

Email address ਅਤੇ phone number ਨੂੰ hash ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ normalize ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, whitespace ਹਟਾਓ, email address lowercase ਕਰੋ, ਅਤੇ hashing ਦੀ ਲੋੜ ਹੋਣ 'ਤੇ SHA-256 ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ phone number ਨੂੰ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ format ਕਰੋ।

Value ਨੂੰ ਦੋ ਵਾਰ hash ਨਾ ਕਰੋ। ਦੋ ਵਾਰ hash ਕੀਤਾ field ਆਮ ਤੌਰ 'ਤੇ ਛੱਡੇ ਗਏ field ਨਾਲੋਂ ਵੀ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ intended match ਨਹੀਂ ਹੋ ਸਕਦਾ ਅਤੇ diagnose ਕਰਨਾ ਵੀ ਔਖਾ ਹੁੰਦਾ ਹੈ।

Data Path ਵਿੱਚ Consent Encode ਕਰੋ

Consent ਨੂੰ payload ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ enforce ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, event ਭੇਜਣ ਤੋਂ ਬਾਅਦ review ਨਹੀਂ। ਜੇ consent ਗੈਰਹਾਜ਼ਰ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਉਹ field ਭੇਜੋ ਜੋ ਤੁਹਾਡੀ policy ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਜਦੋਂ ਤੁਹਾਡੀ legal basis ਅਤੇ regional rule ਦੇ ਤਹਿਤ ਲੋੜ ਹੋਵੇ ਤਾਂ event suppress ਕਰੋ।

ਇਸ ਨੂੰ ਆਪਣੀ compliance process ਵਿੱਚ mapped ਰੱਖੋ, ਜਿਸ ਵਿੱਚ legal and compliance checks ਸ਼ਾਮਲ ਹਨ। Technical team ਇਹ ਦੇਖ ਸਕੇ ਕਿ ਕੋਈ field ਕਿਉਂ ਸ਼ਾਮਲ, ਛੱਡਿਆ, ਜਾਂ block ਕੀਤਾ ਗਿਆ।

ਕਦਮ 4: Retry ਅਤੇ Deduplication ਨਾਲ Event ਭੇਜੋ

Transmission quality ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਅਸਲੀ conversion ਇੱਕ ਹੀ platform event ਬਣਨੀ ਚਾਹੀਦੀ ਹੈ। ਬਿਹਤਰ optimization ਅਤੇ inflated reporting ਵਿਚਕਾਰ ਵਿਆਵਹਾਰਿਕ ਫ਼ਰਕ disciplined deduplication ਹੈ।

ਸਹੀ Integration Path ਚੁਣੋ

ਤਿੰਨ ਆਮ implementation path ਹਨ:

ਜੇ ਤੁਹਾਡੀ team ਪਹਿਲਾਂ ਹੀ Google Tag Manager server container ਵਰਤਦੀ ਹੈ, ਤਾਂ ਵੱਖਰਾ relay ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ workflow ਦੀ ਤੁਲਨਾ ਆਪਣੇ server-side GTM setup ਨਾਲ ਕਰੋ।

ਸਿਰਫ਼ ਸਹੀ Failure 'ਤੇ Retry ਕਰੋ

Timeout ਜਾਂ ਅਸਥਾਈ server error ਵਰਗੀਆਂ transient transport failure ਲਈ retry implement ਕਰੋ। ਪਹਿਲਾਂ validation error ਠੀਕ ਕੀਤੇ ਬਿਨਾ malformed event ਨੂੰ retry ਨਾ ਕਰੋ।

ਇੱਕ ਵਿਆਵਹਾਰਿਕ retry pattern ਹੈ: ਤੁਰੰਤ send, ਇੱਕ ਛੋਟਾ retry, ਇੱਕ ਦੇਰੀ ਨਾਲ retry, ਫਿਰ review ਲਈ dead-letter log। Failure audit ਕਰਨ ਲਈ log ਵਿੱਚ request ID, event ID, response code, ਅਤੇ payload version ਰੱਖੋ।

Event ID ਨਾਲ Deduplicate ਕਰੋ

Pixel event ਅਤੇ matching CAPI event ਲਈ ਇੱਕੋ event_id ਵਰਤੋ। ਨਾਲ ਹੀ, event ID ਅਤੇ business action ਨਾਲ keyed ਇੱਕ ਛੋਟੇ ਸਮੇਂ ਵਾਲੀ server-side cache ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਆਪਣਾ system ਇੱਕੋ conversion ਨੂੰ ਵਾਰ-ਵਾਰ ਨਾ ਭੇਜੇ।

ਅੰਦਾਜ਼ੇ ਵਜੋਂ, ਇੱਕ ਸਿਹਤਮੰਦ implementation ਵਿੱਚ sustained duplicate leakage ਇੰਨਾ ਘੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ optimization ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਨਾ ਬਦਲੇ। ਜੇ checkout refresh, postback retry, ਜਾਂ ਦੇਰੀ ਨਾਲ network approval ਦੇ ਆਸ-ਪਾਸ duplicate ਦਿਖਾਈ ਦੇਣ, ਤਾਂ ਤੁਰੰਤ ਜਾਂਚ ਕਰੋ।

ਕਦਮ 5: Scaling ਤੋਂ ਪਹਿਲਾਂ Signal Quality ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

Dashboard ਵਿੱਚ event ਦਿਖਾਈ ਦੇ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਇਸ ਆਧਾਰ 'ਤੇ CAPI ਦਾ ਮੁਲਾਂਕਣ ਨਾ ਕਰੋ। ਇਸ ਆਧਾਰ 'ਤੇ ਕਰੋ ਕਿ accepted event ਸਹੀ, deduplicated, timely, ਅਤੇ bidding ਲਈ ਉਪਯੋਗ ਹਨ ਜਾਂ ਨਹੀਂ।

ਨਿਯੰਤਰਿਤ Test Session ਚਲਾਓ

ਪੂਰਾ traffic ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣੀਆਂ session ਨਾਲ ਹਰ event type test ਕਰੋ। browser event, server event, event ID, timestamp, URL, value, consent state, ਅਤੇ ਉਮੀਦ ਕੀਤੇ outcome capture ਕਰੋ।

Negative test ਵੀ ਚਲਾਓ। ਛੱਡੇ ਹੋਏ checkout, decline ਕੀਤੇ card, ਗਲਤ form, ਅਤੇ rejected affiliate conversion ਨੂੰ successful purchase ਜਾਂ lead ਨਹੀਂ ਮੰਨਣਾ ਚਾਹੀਦਾ।

ਹਕੀਕਤੀ Range ਨਾਲ Health Metric ਵਰਤੋ

ਸਹੀ number vertical, geography, device mix, ਅਤੇ consent rate ਮੁਤਾਬਕ ਬਦਲਦੇ ਹਨ, ਇਸ ਲਈ ਇਨ੍ਹਾਂ ਨੂੰ universal benchmark ਨਹੀਂ, ਸਗੋਂ operating estimate ਵਜੋਂ ਦੇਖੋ।

ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ Debug ਕਰੋ

Meta Events Manager diagnostics ਅਤੇ test event ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ ਆਪਣੇ Event Match Quality process, server log, network postback record, ਅਤੇ ad account reporting ਦੀ ਸਮੀਖਿਆ ਕਰੋ।

ਖ਼ਰਾਬ tracking ਦੀ ਭਰਪਾਈ ਲਈ bid ਨਾ ਬਦਲੋ। ਪਹਿਲਾਂ event definition, payload field, dedupe, ਅਤੇ consent handling ਠੀਕ ਕਰੋ।

ਕਦਮ 6: Affiliate Scaling ਫੈਸਲਿਆਂ 'ਤੇ CAPI ਲਾਗੂ ਕਰੋ

Affiliate team ਨੂੰ ਹਰ test ਇੱਕੋ ਗਹਿਰਾਈ ਨਾਲ instrument ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। Deep tracking ਸਭ ਤੋਂ ਕੀਮਤੀ ਹੈ ਜਦੋਂ offer ਕੋਲ ਦੁਹਰਾਉਣਯੋਗ economics ਦਾ ਸਬੂਤ ਹੋਵੇ।

Operating State ਮੁਤਾਬਕ Offer ਨੂੰ ਵੰਡੋ

Tracking investment ਦਾ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ offer ਨੂੰ classify ਕਰੋ:

• Pre-scale: ਸ਼ੁਰੂਆਤੀ test volume, ਅਸਥਿਰ CPA, ਅਤੇ ਸੀਮਿਤ conversion proof।
• Scaling: ਦੁਹਰਾਉਣਯੋਗ conversion rate, ਸਥਿਰ CPA trend, ਅਤੇ ਸਿੱਖਣ ਲਈ ਕਾਫ਼ੀ volume।
• Saturated: ਵਧਦਾ CPA, ਕਮਜ਼ੋਰ creative response, ਜਾਂ ਦੁਹਰਾਏ ਗਏ window ਵਿੱਚ capped volume।

Daily Intel Service ਇੱਥੇ ਉਪਯੋਗੀ ਹੈ ਕਿਉਂਕਿ ਇਹ operator ਨੂੰ live scaling behavior ਅਤੇ stale public snapshot ਵਿਚਕਾਰ ਫ਼ਰਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਉਹਨਾਂ offer 'ਤੇ engineering time ਖਰਚ ਕਰਨ ਦਾ ਖ਼ਤਰਾ ਘਟਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਮੰਦ ਪੈ ਰਹੇ ਹਨ।

External Signal ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋ

Meta Ad Library ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਕਿ advertiser ਇਸ ਵੇਲੇ creative ਚਲਾ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਪਰ ਇਹ profitability, spend, ਜਾਂ conversion rate ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਇਸ ਨੂੰ direction signal ਵਜੋਂ ਦੇਖੋ, ਆਪਣੀ funnel data ਦੀ ਥਾਂ ਨਹੀਂ।

AdSpy, BigSpy, ਜਾਂ Anstrex ਵਰਗੇ competitor tool creative research ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਤੁਹਾਡਾ CAPI implementation ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ। ਤੁਹਾਡੇ ਆਪਣੇ event log ਅਤੇ approved conversion data source of truth ਹਨ।

Tracking ਨੂੰ Media Operation ਨਾਲ ਜੋੜੋ

Media buyer rollout process ਵਿੱਚ CAPI check ਸ਼ਾਮਲ ਕਰੋ। ਇੱਕ ਵਿਆਵਹਾਰਿਕ routine ਹੈ: ਸ਼ੁਰੂਆਤੀ test ਲਈ ਹਲਕਾ tracking, scaling candidate ਲਈ ਡੂੰਘੀ CAPI validation, ਅਤੇ paused ਜਾਂ saturated offer ਨਾਲ ਜੁੜੇ event ਲਈ ਹਫ਼ਤਾਵਾਰੀ cleanup।

Daily Intel Service ਵਰਤਣ ਵਾਲੀਆਂ team ਲਈ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ workflow ਇਹ ਹੈ ਕਿ budget ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ offer-state intelligence ਨੂੰ internal CAPI health check ਨਾਲ ਜੋੜਿਆ ਜਾਵੇ। ਜੇ ਉਸ classification ਦੇ ਪਿੱਛੇ decision framework ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ Daily Intel Service methodology ਦੀ ਸਮੀਖਿਆ ਕਰੋ।

ਕਦਮ 7: Launch ਤੋਂ ਬਾਅਦ Governance ਬਣਾਈ ਰੱਖੋ

CAPI ਇੱਕ ਵਾਰ ਦਾ setup ਨਹੀਂ ਹੈ। ਇਸ ਨੂੰ versioning, monitoring, ਅਤੇ ownership ਦੀ ਲੋੜ ਹੈ ਕਿਉਂਕਿ funnel page, checkout provider, affiliate postback, ਅਤੇ platform validation rule ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ।

ਹਰ Funnel ਲਈ ਇੱਕ-ਪੰਨੇ ਦਾ Runbook ਰੱਖੋ

ਹਰ funnel ਲਈ ਇੱਕ runbook ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ event map, payload schema, consent rule, owner, postback source, retry policy, rollback plan, ਅਤੇ ਆਖ਼ਰੀ validation date ਹੋਵੇ। ਇਹ ਸਧਾਰਣ ਹੈ, ਪਰ ਇਹ debugging ਨੂੰ ਯਾਦਦਾਸ਼ਤ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਜਦੋਂ ਵੀ offer URL, checkout flow, lead form, tracking domain, ਜਾਂ payout rule ਬਦਲੇ, runbook ਅਪਡੇਟ ਕਰੋ।

Schema Drift 'ਤੇ ਨਿਗਾਹ ਰੱਖੋ

Schema drift ਤਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਜੋ payload ਭੇਜ ਰਹੇ ਹੋ, ਉਹ Meta ਤੱਕ ਪਹੁੰਚ ਰਹੇ payload ਨਾਲ ਹੁਣ ਮਿਲਦਾ ਨਹੀਂ। ਆਮ ਕਾਰਨਾਂ ਵਿੱਚ ਨਵੇਂ form field, checkout ਬਦਲਾਅ, relay provider updates, ਅਤੇ network postback ਬਦਲਾਅ ਸ਼ਾਮਲ ਹਨ।

Payload version ਬਣਾਈ ਰੱਖੋ ਅਤੇ deployment ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ acceptance rate, match quality, ਅਤੇ duplicate behavior ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ release ਤੋਂ ਬਾਅਦ acceptance ਘਟੇ, campaign strategy ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ tracking change rollback ਕਰੋ।

User Trust ਕੇਂਦਰ ਵਿੱਚ ਰੱਖੋ

Server-side tracking ਨੂੰ user choice ਜਾਂ platform policy ਤੋਂ ਬਚਣ ਦੇ workaround ਵਜੋਂ ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੀਦਾ। Guidance ਜਾਂ internal playbook ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਸਮੇਂ ਆਪਣੀ implementation ਨੂੰ Meta's Conversions API documentation, Meta ad standards, ਅਤੇ Google's helpful content principles ਨਾਲ ਇਕਸਾਰ ਰੱਖੋ।

CAPI ਦਾ ਟਿਕਾਉ ਵਰਜਨ ਸਧਾਰਣ ਹੈ: noise ਘੱਟ ਇਕੱਠਾ ਕਰੋ, ਸਾਫ਼ event ਭੇਜੋ, consent ਦਾ ਸਤਿਕਾਰ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਤਦੋਂ ਹੀ scale ਕਰੋ ਜਦੋਂ funnel economics ਡੂੰਘੀ instrumentation ਨੂੰ ਜਾਇਜ਼ ਬਣਾਉਂਦੇ ਹੋਣ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

ਸਵਾਲ: Facebook Conversions API ਕੀ ਹੈ?
ਜਵਾਬ: Facebook Conversions API Meta ਦਾ server-side event interface ਹੈ ਜੋ web, app, ਜਾਂ offline conversion event ਸਿੱਧੇ ਤੁਹਾਡੇ server ਜਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ integration ਤੋਂ Meta ਨੂੰ ਭੇਜਦਾ ਹੈ।

ਸਵਾਲ: ਕੀ affiliates ਨੂੰ CAPI ਵਰਤਣ 'ਤੇ ਵੀ Pixel ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ?
ਜਵਾਬ: ਹਾਂ। ਜ਼ਿਆਦਾਤਰ affiliate setup ਵਿੱਚ Pixel ਅਤੇ CAPI ਦੋਵੇਂ ਵਰਤਣੇ ਚਾਹੀਦੇ ਹਨ, ਫਿਰ ਇੱਕੋ event_id ਨਾਲ matching event dedupe ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। Pixel browser context ਦਿੰਦਾ ਹੈ, ਜਦਕਿ browser signal ਸੀਮਿਤ ਹੋਣ 'ਤੇ CAPI resilience ਵਧਾਉਂਦਾ ਹੈ।

ਸਵਾਲ: ਇੱਕ affiliate ਨੂੰ ਕਿਹੜੇ event ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਜਵਾਬ: ViewContent, Lead, InitiateCheckout, ਅਤੇ Purchase ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪਰ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਜਦੋਂ ਹਰ event ਇੱਕ ਅਸਲੀ funnel action ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ। Basic event ਸਹੀ ਸਾਬਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੋਰ event ਜੋੜੋ।

ਸਵਾਲ: Duplicate conversion ਤੋਂ ਕਿਵੇਂ ਬਚਾਂ?
ਜਵਾਬ: ਅਸਲੀ action ਲਈ ਇੱਕ event_id ਬਣਾਓ, ਉਹੀ ID browser ਅਤੇ server path ਰਾਹੀਂ ਭੇਜੋ, ਅਤੇ postback retry ਜਾਂ checkout refresh ਲਈ server-side idempotency control ਰੱਖੋ।

ਸਵਾਲ: Spend scaling ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?
ਜਵਾਬ: event definition, payload acceptance, event timing, deduplication, consent handling, ਅਤੇ approved conversion reconciliation ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਸਿਰਫ਼ ਇਸ ਲਈ budget ਨਾ ਵਧਾਓ ਕਿ Meta Events Manager ਵਿੱਚ CAPI event ਦਿਖ ਰਹੇ ਹਨ।

ਸਵਾਲ: ਕੀ Event Match Quality tracking quality ਦੇ ਬਰਾਬਰ ਹੈ?
ਜਵਾਬ: ਨਹੀਂ। Event Match Quality ਮਨਜ਼ੂਰਸ਼ੁਦਾ matching field ਦੀ ਤਾਕਤ ਦਿਖਾਉਂਦੀ ਹੈ, ਪਰ tracking quality ਸਹੀ event logic, deduplication, timeliness, ਅਤੇ ਸਾਫ਼ conversion value handling 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।