Meta Pixel আর Conversions API একসাথে চালানোই Meta-র সুপারিশ: ব্রাউজারের কপি সার্ভারের দেখতে না পাওয়া ফাঁক পূরণ করে, আর সার্ভারের কপি ব্রাউজার আটকে যাওয়ার পরও পৌঁছায়। দাম হলো, প্রতিটি পারচেজ দুবার আসতে পারে, তাই Meta-কে জোড়াটি চিনতে হয়।
নিয়ম
একই Pixel আইডিতে, ওই আইডির প্রথম ইভেন্টের ৪৮ ঘণ্টার মধ্যে, নিচের দুটো মিললে Meta পরের ইভেন্টটি বাদ দেয়:
- Pixel-এর eventID আর Conversions API-র event_id একই।
- Pixel-এর ইভেন্টের নাম আর Conversions API-র event_name একই (যেমন Purchase আর Purchase)।
// ব্রাউজার
fbq('track', 'Purchase', { value: 2580, currency: 'BDT' }, { eventID: 'purchase_10023' });
// সার্ভার (Conversions API)
{ "event_name": "Purchase", "event_id": "purchase_10023", ... }যে ভুলগুলোতে দুবার গোনা হয়
- ব্রাউজারে একটি র্যান্ডম event_id আর সার্ভারে আরেকটি। দুই দিকেই অর্ডার আইডি থেকে বানান, যেমন purchase_{order_id}।
- সার্ভার ব্রাউজারের চেয়ে অন্য Pixel (ডেটাসেট) আইডিতে পাঠায়। ডিডুপ্লিকেশন শুধু একটি Pixel আইডির ভেতরে হয়।
- সার্ভারের কপি প্রথম কপির ৪৮ ঘণ্টারও পরে আসে, যেমন দেরিতে চলা কোনো ব্যাচ জব থেকে।
- শুধু fbp বা external_id মেলানোর ওপর ভরসা। Meta বলে এই পদ্ধতি সাধারণত তখনই কাজ করে যখন ব্রাউজারের ইভেন্ট আগে আসে।
Meta-র আগেও ডিডুপ্লিকেট করুন
রিট্রাই, ওয়েবহুক রি-ডেলিভারি আর দ্বিতীয় কোনো সার্ভার পথ একই অর্ডার কয়েকবার পাঠাতে পারে। অর্ডার আইডি ধরে নিজের দিকেই কপিগুলো এক করলে Meta প্রথম থেকেই প্রতি অর্ডারে একটি ডেলিভারি পায়, আর আপনার নিজের রিপোর্টেও প্রতিটি অর্ডার একবার গোনা হয়। ট্র্যাকেরো প্রতিটি পারচেজকে purchase:order:{order_id} হিসেবে ধরে আর সবসময় একই event_id পাঠায়, তাই দুই স্তরই একমত থাকে।