ร้านเล็กไม่มีโปรแกรมเมอร์ ก็ต่อ Meta Conversions API ได้ ด้วย Conversions API Gateway

เจ้าของร้านขายอุปกรณ์ตกปลาแห่งหนึ่งเคยถามผมว่า ทำไมทุกบทความเรื่อง Conversions API ถึงพูดถึงแต่โค้ด ทั้งที่ร้านเขามีแค่แอดมินหนึ่งคนกับเพจ Facebook ไม่มีใครเขียน server ได้เลย เขาฟังเรื่อง Event Match Quality แล้วอยากทำ แต่พอเจอคำว่า POST request กับ access token ก็ถอดใจตั้งแต่ยังไม่เริ่ม

เรื่องนี้เข้าใจได้ เพราะ Conversions API แบบดั้งเดิมออกแบบมาให้ทีมเทคเป็นคนต่อ มันคือการเขียนโค้ดฝั่ง server ให้ยิงคำขอ HTTP เข้าไปที่ปลายทางของ Meta พร้อมโครงสร้างข้อมูลที่ถูกต้อง ถ้าไม่มีคนทำสิ่งนี้ได้ ก็แปลว่าต่อไม่ได้เลย

Meta เองก็เห็นช่องว่างนี้ เลยเปิดบริการที่เรียกว่า Conversions API Gateway ขึ้นมา เป็นทางที่ลดงานเขียนโค้ดลงมาก บทความนี้จะพาดูว่ามันคืออะไร ต่างจากการต่อ CAPI แบบดั้งเดิมยังไง และที่สำคัญคือ ‘ลดงานลงมาก’ ไม่ได้แปลว่า ‘ไม่ต้องทำอะไรเลย’

ทำไม CAPI แบบดั้งเดิมถึงยากเกินไปสำหรับร้านเล็ก

การต่อ CAPI แบบดั้งเดิมมีสามส่วนที่ต้องมีคนดูแล คือ โครงสร้างเซิร์ฟเวอร์ที่รับข้อมูลจากระบบหลังบ้าน โค้ดที่แปลงข้อมูลให้ตรงรูปแบบที่ Meta ต้องการ และการดูแลเรื่อง access token กับ error handling เวลาส่งไม่สำเร็จ

สำหรับบริษัทที่มีทีมพัฒนาอยู่แล้ว งานนี้อาจใช้เวลาไม่กี่วัน แต่สำหรับร้านที่มีแค่เจ้าของร้านกับแอดมินตอบแชท งานทั้งสามส่วนนี้คือกำแพงที่สูงเกินจะปีนข้ามได้ด้วยตัวเอง ทำให้หลายรายเลือกจะไม่ทำ Conversions API เลย แล้วยอมรับคะแนน Event Match Qualityที่ต่ำไปตลอด

Conversions API Gateway คืออะไร

Conversions API Gateway คือบริการที่ Meta เปิดให้ธุรกิจติดตั้งเป็นตัวกลาง โดยไม่ต้องเขียนโค้ดตั้งแต่ศูนย์ ตัว Gateway ทำหน้าที่รับข้อมูล event จากแหล่งต่าง ๆ ที่คุณตั้งค่าไว้ แล้วแปลงและส่งต่อให้ Meta ตามรูปแบบที่ถูกต้องเอง

จุดต่างหลักจากการต่อ CAPI ดั้งเดิมคือ คุณไม่ต้องเขียนโค้ดจัดการ payload หรือดูแล error handling เอง งานส่วนนั้น Gateway จัดการให้ สิ่งที่คุณต้องทำเหลือแค่ตั้งค่าว่าข้อมูลจะไหลเข้ามาจากทางไหน เช่นผ่าน webhook จากระบบหลังบ้านของร้าน

พูดง่าย ๆ Gateway เปลี่ยนงาน ‘เขียนโปรแกรม’ ให้กลายเป็นงาน ‘ตั้งค่า’ ซึ่งเป็นก้าวที่ทำให้ร้านขนาดเล็กมีโอกาสต่อ CAPI ได้จริง ไม่ต้องพึ่งทีมเทคทั้งหมด

จุดที่ยังต้องมีคนเชื่อม: webhook จาก LINE OA

แม้ Gateway จะลดงานเขียนโค้ดฝั่งส่งข้อมูลเข้า Meta แต่มันไม่ได้รู้เองว่าแอดมินร้านคุณเพิ่งปิดการขายในห้องแชท LINE เมื่อไหร่ ยังต้องมีจุดที่บอกให้มันรู้อยู่ดี

ทางที่ทำได้จริงสำหรับร้านที่ไม่มีทีมเทค คือใช้เครื่องมือ automation แบบลากวางที่หลายค่ายมีให้ใช้ฟรีหรือราคาถูก ตั้งเงื่อนไขว่า เมื่อแอดมินกดปุ่มหรือแท็กข้อความว่า ‘ปิดการขาย’ ในระบบจัดการแชท ให้ส่งข้อมูลนั้นต่อไปยัง webhook ที่ Gateway เปิดรับไว้ วิธีนี้เลี่ยงการเขียนโค้ดได้เกือบทั้งหมด แต่ยังต้องมีคนตั้งค่า flow นี้อยู่ครั้งหนึ่ง

หลักการเดียวกับที่พูดถึงในการตั้ง server-side container คือข้อมูลต้องมีจุดกำเนิดที่ชัดเจนก่อนจะไหลไปที่ไหนได้ Gateway แค่ทำให้ปลายทางง่ายขึ้น ไม่ได้ทำให้ต้นทางหายไป

สิ่งที่ยังต้องมีอยู่ดี แม้จะใช้ Gateway

• ข้อมูลที่ใช้จับคู่ตัวตน — ต่อให้ผ่าน Gateway ก็ยังต้องส่งอีเมลหรือเบอร์โทรที่แฮชแล้วไปด้วย ไม่งั้นคะแนนจับคู่ก็ยังต่ำเหมือนเดิม เรื่องนี้เกี่ยวโยงกับการแฮชข้อมูลก่อนส่งซึ่งเป็นขั้นตอนที่ข้ามไม่ได้
• คนตั้งค่า flow อย่างน้อยหนึ่งครั้ง — Gateway ลดงานเขียนโค้ด แต่การตั้งเงื่อนไขว่าข้อมูลอะไรควรไหลเมื่อไหร่ ยังต้องมีคนนั่งจัดครั้งแรกอยู่ดี ไม่ใช่ระบบอัตโนมัติ 100% ตั้งแต่วันแรกที่เปิดใช้
• การทดสอบก่อนใช้จริง — เหมือนการต่อ CAPI แบบดั้งเดิม ควรทดสอบผ่านเครื่องมือ Test Events ของ Meta ก่อนปล่อยใช้งานจริง เพื่อดูว่าข้อมูลที่ Gateway ส่งออกไปถูกต้องครบถ้วนไหม

สรุป

Conversions API Gateway ไม่ได้ทำให้การต่อ CAPI กลายเป็นเรื่องกดปุ่มเดียวจบ แต่มันย้ายภาระจากงาน ‘เขียนโค้ด’ มาเป็นงาน ‘ตั้งค่า’ ซึ่งเป็นระยะห่างที่ร้านขนาดเล็กพอจะข้ามได้ด้วยตัวเองหรือด้วยความช่วยเหลือเล็กน้อย

สิ่งที่ยังต้องมีอยู่เสมอคือจุดเชื่อมจากฝั่ง LINE OA เข้ามาหา Gateway และวินัยเรื่องการแฮชข้อมูลจับคู่ตัวตนให้ถูกต้อง ถ้าข้ามสองเรื่องนี้ไป ต่อให้มี Gateway ก็ยังได้ผลลัพธ์ที่ไม่ต่างจากไม่ต่อเลย

• CAPI แบบดั้งเดิมต้องเขียนโค้ดฝั่ง server ซึ่งเป็นกำแพงสำหรับร้านเล็ก
• Conversions API Gateway ลดงานตรงนั้นด้วยการตั้งค่าผ่านหน้าจอแทน
• ยังต้องมีจุดเชื่อมจาก LINE OA และข้อมูลจับคู่ตัวตนที่แฮชถูกต้องอยู่ดี

คำถามที่พบบ่อย