Facebook Pixel ກັບ Conversions API (CAPI) ຕ່າງກັນແນວໃດ ເປັນຫຍັງຕ້ອງໃຊ້ທັງສອງ

Facebook Pixel ແມ່ນຫຍັງ ເຮັດວຽກແນວໃດ

Facebook Pixel (ປັດຈຸບັນ Meta ເອີ້ນວ່າ Meta Pixel) ຄືໂຄດ JavaScript ທີ່ວາງໄວ້ເທິງໜ້າເວັບ ເມື່ອຜູ້ເຂົ້າຊົມເປີດໜ້າເວັບ ບຣາວເຊີຂອງເຂົາຈະໂຫຼດໂຄດນີ້ ແລ້ວສົ່ງເຫດການຕ່າງໆ ກັບໄປທີ່ Meta ເຊັ່ນ PageView, ViewContent, AddToCart, Lead ຫຼື Purchase ພ້ອມຂໍ້ມູນປະກອບ ເຊັ່ນ ມູນຄ່າຄຳສັ່ງຊື້ ແລະ ສະກຸນເງິນ

ຂໍ້ມູນເຫຼົ່ານີ້ຖືກໃຊ້ສາມທາງ ຄືວັດຜົນວ່າແຄມເປນໃດສ້າງ conversion ໃຫ້ລະບົບໂຄສະນາຮຽນຮູ້ວ່າຄວນສົ່ງໂຄສະນາໄປຫາຄົນແບບໃດ ແລະ ສ້າງກຸ່ມເປົ້າໝາຍສຳລັບຣີທາເກັດ ເຊັ່ນ ຄົນທີ່ໃສ່ກະຕ່າແຕ່ຍັງບໍ່ຈ່າຍເງິນ

ຈຸດສຳຄັນຄືທັງໝົດເກີດຂຶ້ນຝັ່ງບຣາວເຊີ Pixel ເຮັດວຽກໄດ້ກໍຕໍ່ເມື່ອບຣາວເຊີຂອງຜູ້ໃຊ້ຍອມໂຫຼດສະຄຣິບ ແລະ ຍອມສົ່ງຂໍ້ມູນອອກໄປ ຖ້າມີຫຍັງມາຂວາງລະຫວ່າງທາງ ເຫດການນັ້ນກໍຫາຍໄປຊື່ໆ ໂດຍທີ່ທ່ານບໍ່ຮູ້ຕົວ

ຖ້າຫາກໍ່ເລີ່ມເຮັດໂຄສະນາ ອ່ານພື້ນຖານໄດ້ທີ່ ຍິງແອັດ Facebook ເລີ່ມຕົ້ນ ແລະ ເພາະ Pixel ເຮັດວຽກເທິງໜ້າເວັບຂອງທ່ານ ຄຸນນະພາບຂອງໜ້າປາຍທາງຈຶ່ງສຳຄັນບໍ່ແພ້ກັນ ເບິ່ງເພີ່ມໄດ້ທີ່ Landing Page ແມ່ນຫຍັງ

ເປັນຫຍັງ Pixel ຢ່າງດຽວຈຶ່ງເກັບຂໍ້ມູນບໍ່ຄົບ

ການຕິດຕາມຝັ່ງບຣາວເຊີມີຈຸດອ່ອນທາງໂຄງສ້າງ ບໍ່ແມ່ນບັນຫາຈາກການຕິດຕັ້ງຜິດ ເຖິງຈະວາງໂຄດຖືກທຸກແຖວ ຂໍ້ມູນສ່ວນໜຶ່ງກໍຈະຫາຍໄປຈາກສາເຫດເຫຼົ່ານີ້

• ຕົວບລັອກໂຄສະນາ ແລະ ສ່ວນຂະຫຍາຍດ້ານຄວາມເປັນສ່ວນຕົວ — ຫຼາຍຕົວບລັອກການໂຫຼດສະຄຣິບຂອງ Meta ຕັ້ງແຕ່ຕົ້ນ ເຫດການຈາກຜູ້ໃຊ້ກຸ່ມນີ້ຈຶ່ງບໍ່ຖືກສົ່ງເລີຍ
• ລະບົບປ້ອງກັນການຕິດຕາມຂອງບຣາວເຊີ — Safari ມີ Intelligent Tracking Prevention (ITP) ແລະ ບຣາວເຊີອື່ນກໍມີຟີເຈີຄ້າຍກັນ ເຊິ່ງຈຳກັດອາຍຸຄຸກກີ້ທີ່ສ້າງດ້ວຍ JavaScript ເຮັດໃຫ້ການເຊື່ອມໂຍງຄລິກໂຄສະນາກັບການຊື້ທີ່ເກີດຂຶ້ນຫຼັງຈາກນັ້ນຫຼາຍມື້ເຮັດໄດ້ຍາກຂຶ້ນ
• ການຂໍອະນຸຍາດຕິດຕາມເທິງ iOS — ຕັ້ງແຕ່ Apple ເພີ່ມການຂໍອະນຸຍາດຕິດຕາມຂ້າມແອັບ ຜູ້ໃຊ້ຈຳນວນຫຼາຍເລືອກບໍ່ອະນຸຍາດ ຂໍ້ມູນທີ່ Meta ໃຊ້ຈັບຄູ່ຜູ້ໃຊ້ຈຶ່ງໜ້ອຍລົງ
• ເນັດຫຼຸດ ຫຼື ປິດໜ້າໄວ — ຜູ້ໃຊ້ກົດຈ່າຍເງິນແລ້ວປິດແທັບກ່ອນໜ້າຂອບໃຈໂຫຼດແລ້ວ ເຫດການ Purchase ກໍບໍ່ຖືກສົ່ງ
• ການຍິນຍອມຄຸກກີ້ — ຖ້າເວັບມີແບນເນີຂໍຄວາມຍິນຍອມ ແລະ ຜູ້ໃຊ້ບໍ່ຍິນຍອມ Pixel ກໍບໍ່ຄວນເຮັດວຽກຕັ້ງແຕ່ທຳອິດ

Conversions API (CAPI) ແມ່ນຫຍັງ ຕ່າງຈາກ Pixel ແນວໃດ

Conversions API ຄືຊ່ອງທາງທີ່ໃຫ້ເຊີບເວີຂອງທ່ານສົ່ງເຫດການໄປທີ່ Meta ໂດຍກົງແບບເຊີບເວີເຖິງເຊີບເວີ ບໍ່ຕ້ອງຜ່ານບຣາວເຊີຂອງຜູ້ໃຊ້ ເມື່ອມີຄຳສັ່ງຊື້ເກີດຂຶ້ນໃນລະບົບຫຼັງບ້ານ ເຊີບເວີກໍຍິງເຫດການ Purchase ໄປທີ່ Meta ໄດ້ເລີຍ ຕົວບລັອກໂຄສະນາໃນບຣາວເຊີຈຶ່ງບໍ່ມີຜົນກັບຊ່ອງທາງນີ້

ຂໍ້ດີອີກຂໍ້ຄືສົ່ງຂໍ້ມູນທີ່ບຣາວເຊີບໍ່ມີໄດ້ ເຊັ່ນ ຄຳສັ່ງຊື້ທີ່ຢືນຢັນການຊຳລະເງິນແລ້ວແທ້ ລີດທີ່ທີມຂາຍກວດແລ້ວວ່າມີຄຸນນະພາບ ຫຼື ການຍົກເລີກຄຳສັ່ງຊື້ ເຮັດໃຫ້ຂໍ້ມູນທີ່ລະບົບໂຄສະນາໃຊ້ຮຽນຮູ້ໃກ້ຄຽງກັບຍອດຂາຍແທ້ຫຼາຍຂຶ້ນ

ແຕ່ CAPI ກໍບໍ່ໄດ້ມາແທນ Pixel ເພາະ Pixel ເຫັນພຶດຕິກຳເທິງໜ້າເວັບທີ່ເຊີບເວີບໍ່ເຫັນ ເຊັ່ນ ການເລື່ອນເບິ່ງສິນຄ້າ ແລະ ມີຄຸກກີ້ຂອງ Meta ຢູ່ໃນບຣາວເຊີທີ່ຊ່ວຍຈັບຄູ່ຜູ້ໃຊ້ Meta ຈຶ່ງແນະນຳໃຫ້ໃຊ້ທັງສອງແບບຄູ່ກັນ ແລ້ວໃຫ້ລະບົບຕັດເຫດການທີ່ຊ້ຳກັນຖິ້ມ

ໃຊ້ຄູ່ກັນຕ້ອງຕັ້ງ Deduplication ດ້ວຍ event_id

ເມື່ອທັງ Pixel ແລະ CAPI ສົ່ງເຫດການ Purchase ດຽວກັນ ຖ້າບໍ່ບອກ Meta ວ່າເປັນເຫດການດຽວກັນ ຍອດຂາຍຈະຖືກນັບສອງເທື່ອ ລາຍງານຈະເບິ່ງດີເກີນຈິງ ແລະ ລະບົບໂຄສະນາຈະຮຽນຮູ້ຈາກຂໍ້ມູນຜິດ

ວິທີທີ່ Meta ແນະນຳຄືສົ່ງລະຫັດເຫດການຊຸດດຽວກັນຈາກທັງສອງຝັ່ງ ຝັ່ງ Pixel ໃສ່ eventID ໃນພາຣາມິເຕີຕົວທີສີ່ຂອງຄຳສັ່ງ fbq track ສ່ວນຝັ່ງ CAPI ໃສ່ event_id ຄ່າຕ້ອງກົງກັນ ແລະ ຊື່ເຫດການຕ້ອງກົງກັນນຳ ຄື event ຂອງ Pixel ຕ້ອງເທົ່າກັບ event_name ຂອງ CAPI ເຊັ່ນ Purchase ທັງສອງ

ຕາມເອກະສານຂອງ Meta ຖ້າໄດ້ຮັບເຫດການທີ່ມີຄູ່ event_id ກັບ event_name ກົງກັນຈາກ Pixel ດຽວກັນພາຍໃນ 48 ຊົ່ວໂມງ ລະບົບຈະເກັບໄວ້ຕົວດຽວ ແລ້ວຕັດຕົວທີ່ຊ້ຳຖິ້ມ ໃນທາງປະຕິບັດລະຫັດນີ້ມັກໃຊ້ເລກຄຳສັ່ງຊື້ ຫຼື ສ້າງເປັນຄ່າສຸ່ມຕອນຜູ້ໃຊ້ກົດປຸ່ມ ແລ້ວສົ່ງຄ່າດຽວກັນໄປໃຫ້ທັງໂຄດໜ້າເວັບ ແລະ ເຊີບເວີ

Event Match Quality ແລະ ການ hash ຂໍ້ມູນລູກຄ້າ

ເຫດການທີ່ສົ່ງຜ່ານ CAPI ຈະມີປະໂຫຍດກໍຕໍ່ເມື່ອ Meta ຈັບຄູ່ໄດ້ວ່າເປັນຜູ້ໃຊ້ຄົນໃດ Events Manager ມີຄະແນນ Event Match Quality ບອກວ່າຂໍ້ມູນລູກຄ້າທີ່ທ່ານສົ່ງມາຊ່ວຍຈັບຄູ່ໄດ້ດີປານໃດ ຍິ່ງສົ່ງພາຣາມິເຕີທີ່ຖືກຕ້ອງຄົບ ຄະແນນຍິ່ງສູງ

ຂໍ້ມູນສ່ວນຕົວ ເຊັ່ນ ອີເມວ ເບີໂທ ຊື່ ນາມສະກຸນ ເມືອງ ລະຫັດໄປສະນີ ແລະ external_id ຕ້ອງເຮັດໃຫ້ເປັນຮູບແບບມາດຕະຖານກ່ອນ ແລ້ວຈຶ່ງ hash ດ້ວຍ SHA-256 ເຊັ່ນ ອີເມວຕ້ອງຕັດຍະຫວ່າງຫົວທ້າຍ ແລະ ແປງເປັນຕົວພິມນ້ອຍ ເບີໂທຕ້ອງເຫຼືອແຕ່ຕົວເລກ ຕັດເລກສູນນຳໜ້າອອກ ແລະ ໃສ່ລະຫັດປະເທດ ຕົວຢ່າງເບີໄທ 081-234-5678 ຈຶ່ງກາຍເປັນ 66812345678 ກ່ອນນຳໄປ hash

ສ່ວນຂໍ້ມູນບາງຕົວຕ້ອງສົ່ງແບບບໍ່ hash ໄດ້ແກ່ client_ip_address, client_user_agent, fbp (ຄຸກກີ້ _fbp ທີ່ລະບຸບຣາວເຊີ) ແລະ fbc (ຄ່າທີ່ມາຈາກ fbclid ຕອນຜູ້ໃຊ້ຄລິກໂຄສະນາ) ແລະ ສຳລັບເຫດການຈາກເວັບໄຊ Meta ກຳນົດໃຫ້ຕ້ອງສົ່ງ client_user_agent ນຳ

• em, ph, fn, ln, ct, zp, country, external_id — ເຮັດໃຫ້ເປັນມາດຕະຖານແລ້ວ hash ດ້ວຍ SHA-256
• client_ip_address, client_user_agent — ສົ່ງຄ່າແທ້ແບບບໍ່ hash ດຶງມາຈາກ request ຂອງຜູ້ໃຊ້
• fbp, fbc — ອ່ານຈາກຄຸກກີ້ຂອງຜູ້ໃຊ້ແລ້ວສົ່ງຕໍ່ແບບບໍ່ hash ຊ່ວຍໃຫ້ເຫດການຝັ່ງເຊີບເວີຈັບຄູ່ກັບຝັ່ງບຣາວເຊີໄດ້ແມ່ນຂຶ້ນ

ວິທີຕິດຕັ້ງ Conversions API ມີຈັກແບບ ເລືອກແບບໃດດີ

ບໍ່ມີວິທີທີ່ດີທີ່ສຸດສຳລັບທຸກຄົນ ຂຶ້ນກັບວ່າເວັບຂອງທ່ານສ້າງດ້ວຍຫຍັງ ມີນັກພັດທະນາໃນທີມບໍ ແລະ ຢາກຄຸມຂໍ້ມູນເອງປານໃດ ຕາຕະລາງນີ້ສະຫຼຸບສີ່ທາງເລືອກຫຼັກ

VPS ເຂົ້າມາຊ່ວຍຕົງໃສ ແລະ ຕ້ອງໃຊ້ສະເປັກເທົ່າໃດ

ຕົວຢ່າງການສົ່ງເຫດການດ້ວຍ curl

ສອງວິທີສຸດທ້າຍໃນຕາຕະລາງຕ້ອງມີເຊີບເວີທີ່ເປີດຕະຫຼອດເວລາ ແລະ ມີ HTTPS ຖ້າເຊີບເວີລົ້ມ ເຫດການຝັ່ງ CAPI ຈະຫາຍໄປທັງໝົດໃນຊ່ວງນັ້ນ ນີ້ຄືຈຸດທີ່ VPS ເຂົ້າມາຊ່ວຍ

Server-side GTM ແບບຕິດຕັ້ງເອງ Google ມີຄູ່ມື manual setup ທີ່ໃຫ້ຣັນເຊີບເວີຕິດແທັກເປັນ Docker image ເທິງເຄື່ອງທີ່ທ່ານເລືອກໄດ້ ໂດຍຕ້ອງມີທັງ tagging server ແລະ preview server ຊີ້ຊັບໂດເມນ HTTPS ຂອງເວັບທ່ານເຂົ້າມາ Google ລະບຸວ່າແຕ່ລະເຄື່ອງບໍ່ຄວນເກີນ 1 vCPU ເພາະ vCPU ທີ່ເກີນບໍ່ໄດ້ຖືກໃຊ້ ແລະ ແນະນຳໃຫ້ຣັນເປັນຄລັສເຕີເມື່ອທຣາຟຟິກສູງ ສຳລັບເວັບຂະໜາດນ້ອຍຫາກາງ VPS ທີ່ມີ 2 vCores / 4 GB RAM ຣັນທັງສອງຕົວພ້ອມ reverse proxy ໄດ້ສະບາຍ

ຖ້າຂຽນ endpoint ຮັບເຫດການເອງແລ້ວສົ່ງຕໍ່ໄປ Meta ງານນີ້ເບົາຫຼາຍ VPS ນ້ອຍທີ່ສຸດກໍຣັນໄດ້ຖ້າທຣາຟຟິກບໍ່ສູງ ແຕ່ຄວນມີຄິວ ຫຼື ການລອງສົ່ງໃໝ່ ເຜື່ອ Meta ຕອບກັບຊ້າ ສ່ວນ Conversions API Gateway ຕາມເອກະສານຂອງ Meta ຕ້ອງຣັນເທິງບັນຊີ AWS ຫຼື GCP ຈຶ່ງບໍ່ແມ່ນຕົວເລືອກສຳລັບ VPS ທົ່ວໄປ

ການຣັນ sGTM ຫຼື endpoint ຂອງທ່ານເອງດ້ວຍ Docker ເຮັດໃຫ້ຍ້າຍເຄື່ອງ ແລະ ອັບເດດງ່າຍກວ່າຫຼາຍ ແລະ ຖ້າຢາກຮູ້ວ່າ VPS ຊ່ວຍງານສາຍໂຄສະນາດ້ານອື່ນຫຍັງອີກ ເບິ່ງຕໍ່ທີ່ VPS ສຳລັບຄົນຍິງແອັດ

• ສົ່ງແບບ POST ໄປທີ່ https://graph.facebook.com/vXX.0/PIXEL_ID/events ໂດຍແທນ vXX.0 ດ້ວຍເວີຊັນຂອງ Graph API ທີ່ໃຊ້ຢູ່ ແລະ ແນບ access_token ທີ່ສ້າງຈາກ Events Manager
• ຄຳສັ່ງຕົວຢ່າງ: curl -X POST "https://graph.facebook.com/vXX.0/PIXEL_ID/events?access_token=TOKEN" -H "Content-Type: application/json" -d @event.json
• ໃນໄຟລ໌ event.json ໃສ່ data ເປັນອາເຣຂອງເຫດການ ແຕ່ລະຕົວມີ event_name, event_time (Unix timestamp ຫົວໜ່ວຍວິນາທີ), event_id, action_source ເປັນ website, event_source_url ແລະ user_data ທີ່ມີ em ແບບ hash, client_ip_address, client_user_agent, fbp, fbc
• ຊ່ວງທົດສອບເພີ່ມ test_event_code ໃນລະດັບເທິງສຸດຂອງ payload ແລ້ວລຶບອອກກ່ອນໃຊ້ງານແທ້

ທົດສອບດ້ວຍ Test Events ແລະ ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍ

ຫຼັງຕິດຕັ້ງແລ້ວ ເຂົ້າ Events Manager ເລືອກ Pixel ຂອງທ່ານ ແລ້ວເປີດແທັບ Test events ຝັ່ງ Pixel ໃຫ້ເປີດເວັບຜ່ານຊ່ອງທົດສອບແລ້ວລອງເຮັດເຫດການແທ້ ຝັ່ງ CAPI ໃຫ້ກັອບປີ້ລະຫັດທົດສອບໄປໃສ່ໃນ test_event_code ຂອງ payload ເຫດການຈະຂຶ້ນໃຫ້ເຫັນເກືອບທັນທີ ພ້ອມບອກວ່າມາຈາກບຣາວເຊີ ຫຼື ເຊີບເວີ ແລະ ຖືກຕັດຊ້ຳຫຼືບໍ່

ຖ້າເຫັນເຫດການດຽວກັນຂຶ້ນທັງສອງຝັ່ງ ແລະ ລະບົບລະບຸວ່າຕັດຊ້ຳແລ້ວ ໝາຍຄວາມວ່າ event_id ຕັ້ງຖືກ ຈາກນັ້ນເບິ່ງຄະແນນ Event Match Quality ໃນໜ້າພາບລວມ ຫຼັງມີຂໍ້ມູນແທ້ເຂົ້າມາໄລຍະໜຶ່ງ