অ্যাফিলিয়েটদের জন্য Facebook Conversion API সেটআপ: ২০২৬ গাইড

ধাপ 1: Event পাঠানোর আগে Conversion Contract নির্ধারণ করুন

Conversion contract হলো লিখিত নিয়ম যে প্রতিটি event কী বোঝায়, কখন এটি fire করবে, এবং payload-এ কোন field অনুমোদিত। এই contract ছাড়া CAPI একটি messy funnel-কে আরও দ্রুত messy funnel-এ পরিণত করতে পারে।

শুধু এমন Event বেছে নিন যা আপনি প্রমাণ করতে পারেন

বেশিরভাগ affiliate funnel চারটি standard event দিয়ে শুরু করা উচিত: ViewContent, Lead, InitiateCheckout, এবং Purchase। CompleteRegistration কেবল তখনই যোগ করুন যখন funnel-এ একটি বাস্তব registration step থাকে যা Lead-এর মাধ্যমে ইতিমধ্যেই ধরা পড়েনি।

প্রতিটি 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 second ব্যবহার করুন। ব্যবহারিক নিয়ম হিসেবে, action-এর যত কাছাকাছি সম্ভব event পাঠান; দেরি হওয়া event এখনও গ্রহণ করা যেতে পারে, কিন্তু পুরনো conversion data bidding এবং troubleshooting-এর জন্য কম উপকারী।

ধাপ 2: Pixel এবং CAPI-কে Lockstep-এ রাখুন

Pixel এবং CAPI-এর উচিত দুটি delivery path-এর মাধ্যমে একই বাস্তব-world 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 স্বাভাবিক করুন

Traffic context স্থিতিশীল field-এ সংরক্ষণ করুন: source, campaign, ad set, ad, creative, placement, affiliate ID, offer ID, এবং funnel variant। আপনার UTM decoding process-এর মতো একটি consistent naming system ব্যবহার করুন যাতে paid media এবং affiliate reporting manual cleanup ছাড়াই তুলনা করা যায়।

সব available parameter custom_data-তে ঢেলে দেবেন না। এমন field পাঠান যা attribution, value, funnel state, বা optimization quality যাচাই করতে সাহায্য করে।

ধাপ 3: Consent-Aware Payload তৈরি করুন

একটি ভালো CAPI payload প্রযুক্তিগতভাবে উপকারী এবং privacy-aware উভয়ই। এতে অনুমোদিত সবচেয়ে শক্তিশালী matching field থাকা উচিত, কিন্তু কেবল তখনই যখন সেই user এবং region-এর জন্য collection এবং transmission বৈধ।

ন্যূনতম Required Shape দিয়ে শুরু করুন

Optional field যোগ করার আগে একটি base payload তৈরি ও পরীক্ষা করুন:

• 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 double-hash করবেন না। দুইবার hash করা field সাধারণত বাদ দেওয়া field-এর চেয়েও খারাপ, কারণ এটি intended match হতে পারে না এবং diagnose করাও কঠিন।

Data Path-এ Consent এনকোড করুন

Payload তৈরি হওয়ার আগে consent enforce করা উচিত, event পাঠানোর পরে review করা নয়। Consent অনুপস্থিত থাকলে, কেবল আপনার policy যে field অনুমোদন করে সেগুলো পাঠান, অথবা আপনার legal basis এবং regional rule অনুযায়ী প্রয়োজন হলে event suppress করুন।

এটি আপনার compliance process-এ mapped রাখুন, যার মধ্যে legal and compliance checks রয়েছে। Technical team যেন দেখতে পারে কেন একটি field অন্তর্ভুক্ত, বাদ, বা ব্লক করা হয়েছে।

ধাপ 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 হলো: immediate send, একটি ছোট retry, একটি delayed 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 short-lived server-side cache রাখুন যাতে আপনার নিজের system একই conversion বারবার না পাঠায়।

আনুমানিকভাবে, একটি সুস্থ implementation-এ sustained duplicate leakage এতটাই কম থাকা উচিত যে এটি optimization সিদ্ধান্ত বদলায় না। checkout refresh, postback retry, বা delayed network approval-এর আশেপাশে duplicate দেখা দিলে সঙ্গে সঙ্গে তদন্ত করুন।

ধাপ 5: Scaling-এর আগে Signal Quality যাচাই করুন

Dashboard-এ event দেখা যাচ্ছে কি না, তার ভিত্তিতে CAPI বিচার করবেন না। বিচার করুন accepted event সঠিক, deduplicated, timely, এবং bidding-এর জন্য উপকারী কি না।

নিয়ন্ত্রিত Test Session চালান

পূর্ণ traffic পাঠানোর আগে পরিচিত session দিয়ে প্রতিটি event type পরীক্ষা করুন। browser event, server event, event ID, timestamp, URL, value, consent state, এবং প্রত্যাশিত outcome capture করুন।

Negative test-ও চালান। Abandoned checkout, declined card, invalid form, এবং rejected affiliate conversion সফল purchase বা lead হিসেবে গণ্য হওয়া উচিত নয়।

বাস্তবসম্মত Range-সহ Health Metric ব্যবহার করুন

সঠিক number vertical, geography, device mix, এবং consent rate অনুযায়ী ভিন্ন হয়, তাই এগুলোকে সার্বজনীন benchmark না ভেবে operating estimate হিসেবে দেখুন।

সঠিক ক্রমে Debug করুন

Meta Events Manager diagnostics এবং test event দিয়ে শুরু করুন। তারপর আপনার Event Match Quality process, server log, network postback record, এবং ad account reporting পর্যালোচনা করুন।

Broken tracking পুষিয়ে নিতে bid পরিবর্তন করবেন না। আগে event definition, payload field, dedupe, এবং consent handling ঠিক করুন।

ধাপ 6: Affiliate Scaling Decision-এ CAPI প্রয়োগ করুন

Affiliate team-এর প্রতিটি test-এ একই গভীরতার instrument ব্যবহার করা উচিত নয়। Offer-টির পুনরাবৃত্তিযোগ্য economics-এর প্রমাণ থাকলে deep tracking সবচেয়ে মূল্যবান।

Operating State অনুযায়ী Offer সাজান

Tracking investment নির্ধারণের আগে প্রতিটি offer শ্রেণিবদ্ধ করুন:

• Pre-scale: প্রাথমিক test volume, অস্থির CPA, এবং সীমিত conversion proof।
• Scaling: পুনরাবৃত্তিযোগ্য conversion rate, স্থিতিশীল CPA trend, এবং শেখার জন্য যথেষ্ট volume।
• Saturated: বাড়তে থাকা CPA, দুর্বল creative response, বা repeated 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-কে memory-এর ওপর নির্ভর করা থেকে বাঁচায়।

Offer URL, checkout flow, lead form, tracking domain, বা payout rule পরিবর্তিত হলেই runbook আপডেট করুন।

Schema Drift নজরে রাখুন

Schema drift ঘটে যখন আপনি যে payload পাঠাচ্ছেন বলে ভাবেন, সেটি আর Meta-তে পৌঁছানো payload থাকে না। সাধারণ কারণগুলোর মধ্যে আছে নতুন form field, checkout পরিবর্তন, relay provider update, এবং 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-এর টেকসই version সহজ: noise কম সংগ্রহ করুন, পরিষ্কার event পাঠান, consent সম্মান করুন, এবং funnel economics গভীর instrumentation ন্যায্যতা দিলে তবেই scaling করুন।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

প্রশ্ন: Facebook Conversions API কী?
উত্তর: Facebook Conversions API হলো Meta-এর server-side event interface, যা web, app, বা offline conversion event সরাসরি আপনার server বা অনুমোদিত integration থেকে Meta-তে পাঠায়।

প্রশ্ন: CAPI ব্যবহার করলে affiliates-এর কি এখনও Pixel দরকার?
উত্তর: হ্যাঁ। বেশিরভাগ affiliate setup-এ Pixel এবং CAPI দুটোই ব্যবহার করা উচিত, তারপর একই event_id দিয়ে matching event deduplicate করা উচিত। Pixel browser context দেয়, আর CAPI browser signal সীমিত হলে 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 যাচাই করুন। শুধু Meta Events Manager-এ CAPI event দেখা যাচ্ছে বলেই budget বাড়াবেন না।

প্রশ্ন: Event Match Quality কি tracking quality-র সমান?
উত্তর: না। Event Match Quality অনুমোদিত matching field-এর শক্তি দেখায়, কিন্তু tracking quality-ও নির্ভর করে সঠিক event logic, deduplication, timeliness, এবং পরিষ্কার conversion value handling-এর ওপর।