เก็บ User ID จาก Webhook ไว้แล้ว จะผูกกับ Lead ในระบบขายได้ยังไง

ทีมพัฒนาจำนวนมากผ่านขั้นตอนตั้งเซิร์ฟเวอร์รับ Webhook จาก LINE ได้สำเร็จ เห็น User ID ของผู้ใช้แต่ละคนไหลเข้ามาทุกครั้งที่มี Event เกิดขึ้น แต่พอถามต่อว่า User ID เหล่านี้ถูกเก็บไว้ที่ไหน ผูกกับอะไรบ้าง คำตอบที่ได้บ่อยคือมีตารางเก็บ Log ของ Event ไว้เฉย ๆ ยังไม่มีการออกแบบว่า User ID หนึ่งค่าควรผูกกับ Lead กี่รายการ หรือควรอัปเดตข้อมูลอะไรบ้างเมื่อมี Event ใหม่เข้ามา

ปัญหานี้ไม่ใช่เรื่องเทคนิคการรับ Webhook แต่เป็นเรื่องการออกแบบ Data Layer ตั้งแต่ต้น ถ้าโครงสร้างข้อมูลไม่รองรับการเชื่อม User ID กับ Lead กับ Identifier ต้นทางตั้งแต่แรก ต่อให้รับ Event ได้ครบทุก Field ก็ยังเอาไปใช้วิเคราะห์หรือส่ง Conversion กลับแพลตฟอร์มโฆษณาไม่ได้อยู่ดี

บทความนี้จะพาไล่ดูแนวทางออกแบบ Data Layer สำหรับเก็บ LINE User ID ตั้งแต่ Field ที่ต้องมี ความสัมพันธ์ระหว่างตาราง ไปจนถึงจุดที่มักออกแบบผิดพลาดจนต้องย้อนกลับมาแก้ทีหลัง

ทำไมเก็บแค่ User ID ดิบ ๆ ไม่พอสำหรับใช้งานจริง

User ID ที่ LINE ส่งมาเป็นแค่รหัสอ้างอิงตัวหนึ่ง ไม่มีความหมายอะไรเลยถ้าไม่ผูกกับข้อมูลอื่น การเก็บ User ID ลงตาราง Log เดียวพร้อม Timestamp ของแต่ละ Event อาจพอสำหรับ Debug ทางเทคนิค แต่ไม่พอสำหรับทีมขายหรือทีมการตลาดที่ต้องการรู้ว่า User ID นี้คือ Lead รายไหน มาจาก Campaign อะไร และตอนนี้อยู่ในสถานะใด

สิ่งที่ต้องมีเพิ่มจาก User ID ดิบคือความสัมพันธ์แบบหนึ่งต่อหนึ่งกับ Lead หนึ่งราย และ Field ที่บอกว่า Lead รายนี้มาจากแหล่งไหน สถานะปัจจุบันเป็นอย่างไร ใครเป็นผู้รับผิดชอบ ถ้าขาดชั้นนี้ไป ทีมจะต้องมานั่งเขียน Query ย้อนหลังทุกครั้งที่ต้องการรู้ภาพรวม ซึ่งทำงานได้ช้าและเสี่ยงตีความข้อมูลผิด

Field ขั้นต่ำที่ต้องเก็บพร้อม User ID ตั้งแต่จุดแรกที่พบ

ข้อมูลชุดนี้ควรถูกบันทึกทันทีในจังหวะที่ Webhook แรกของ User ID นั้นเข้ามา ไม่ใช่รอให้มีการอัปเดตสถานะ Lead ก่อนแล้วค่อยย้อนกลับไปเติม เพราะ Identifier ต้นทางบางตัวอย่าง UTM มักหายไปถ้าไม่จับตั้งแต่จุดแรกที่เจอ

• User ID จาก LINE ผูกกับ Channel หรือ OA ที่รับ Event นั้น
• Timestamp ของ Event แรกที่พบ User ID นี้ในระบบ
• Event ที่ทำให้พบ User ID เช่น Follow, Message หรือ Postback
• Identifier ต้นทางที่มีในช่วงนั้น เช่น UTM Source/Medium/Campaign หรือ Tracking Token ที่ฝังในลิงก์
• Project หรือ LINE Connection ที่เกี่ยวข้อง กรณีธุรกิจมีหลาย OA
• Lead ID ภายในระบบของธุรกิจเองที่ใช้อ้างอิงข้าม Event ในอนาคต

ความสัมพันธ์ระหว่างตาราง User ID, Lead และ Event ควรออกแบบยังไง

แนวทางที่ใช้กันทั่วไปคือแยกเป็นสามส่วนหลัก ส่วนแรกคือตาราง Identity ที่เก็บ User ID พร้อม Mapping ไปยัง Lead ID ส่วนที่สองคือตาราง Lead ที่เก็บสถานะ ผู้รับผิดชอบ และ Identifier ต้นทาง ส่วนที่สามคือตาราง Event Log ที่เก็บทุก Event ดิบที่เกิดขึ้น ผูกกับ Lead ID เดียวกันผ่าน User ID

การแยกแบบนี้ช่วยให้ระบบรองรับกรณีที่ User ID หนึ่งค่าอาจเกี่ยวข้องกับ Lead ได้มากกว่าหนึ่งรอบตลอดอายุการใช้งาน เช่นลูกค้าเก่าที่เคยปิดการขายไปแล้ว กลับมาทักใหม่หลังผ่านไปหลายเดือนเพื่อซื้อรอบใหม่ ถ้าธุรกิจนิยามว่านี่คือ Lead ใหม่ ตาราง Identity ก็ต้องรองรับการสร้าง Lead ID ใหม่ผูกกับ User ID เดิมได้ โดยไม่ทับข้อมูล Lead รอบก่อนหน้า

ตารางที่แยกความสัมพันธ์ชัดแบบนี้ยังทำให้เชื่อมกับหัวข้อ LINE User ID Attribution ได้ง่ายขึ้นในภายหลัง เพราะการกันซ้ำและการให้เครดิต Campaign ต้องอาศัยโครงสร้างข้อมูลที่แยกชั้นกันแบบนี้เป็นพื้นฐาน ไม่ใช่มานั่งแยกทีหลังจากตาราง Log เดียว

ตัวอย่างสมมติ: หนึ่ง User ID เดินทางผ่านตารางไหนบ้างตามเวลา

เพื่อให้เห็นภาพว่า Field ที่อธิบายมาทำงานร่วมกันยังไงจริง ๆ ลองดูตัวอย่างสมมติของ User ID หนึ่งค่าที่เดินทางผ่านระบบตั้งแต่คลิกโฆษณาจนถึงกลับมาซื้อซ้ำ ตัวเลขและวันที่ในตารางนี้เป็นข้อมูลสมมติเพื่ออธิบายกรอบการทำงาน ไม่ใช่สถิติจริงจากลูกค้ารายใด:

Field ไหนใช้ทำอะไร เทียบให้เห็นภาพก่อนออกแบบตาราง

ก่อนลงมือสร้างตารางจริง ควรทำความเข้าใจว่าแต่ละ Field มีไว้ตอบคำถามอะไร เพื่อไม่ให้ออกแบบ Field ที่ไม่มีใครใช้งานจริง:

ความผิดพลาดที่พบบ่อยตอนออกแบบ Data Layer เก็บ User ID

ความผิดพลาดแรกที่พบบ่อยคือเก็บ User ID เป็น Text ธรรมดาปนกับ Field อื่นในตารางเดียวโดยไม่สร้าง Index หรือ Unique Constraint ทำให้เมื่อข้อมูลเพิ่มขึ้นเรื่อย ๆ การค้นหา Lead จาก User ID ที่เข้ามาใหม่ทำได้ช้าลงเรื่อย ๆ จนกระทบการตอบสนองของระบบเวลามี Event เข้ามาถี่ ๆ

ความผิดพลาดที่สองคือไม่แยกกรณีที่ธุรกิจมีมากกว่าหนึ่ง LINE OA ออกจากกันตั้งแต่ต้น เพราะ User ID ผูกกับแต่ละ Channel แยกกัน ถ้าตารางไม่มี Field ระบุว่า User ID นี้มาจาก OA ไหน เมื่อธุรกิจขยายมาใช้หลาย OA ในภายหลัง จะพบว่า User ID ซ้ำกันข้าม OA โดยไม่ได้ตั้งใจ เพราะไม่ได้กันไว้ตั้งแต่แรกว่าต้องดูคู่กับ Channel ID เสมอ

ความผิดพลาดที่สามคือลบหรือเขียนทับ Identifier ต้นทางเมื่อ Lead เปลี่ยนสถานะ เช่นพอ Lead ปิดการขายแล้วก็ล้าง Field UTM ทิ้งเพราะคิดว่าไม่จำเป็นแล้ว ทั้งที่ข้อมูลนี้ยังต้องใช้ตอนวิเคราะห์ย้อนหลังว่า Campaign ไหนสร้างยอดขายได้จริง ควรเก็บ Identifier ต้นทางไว้ถาวรแยกจาก Field ที่ใช้งานประจำวัน ไม่ใช่ปล่อยให้ถูกเขียนทับหายไป

รับ Webhook มาแล้ว ต้องมั่นใจแค่ไหนก่อนเขียนลง Data Layer จริง

การเขียน User ID และข้อมูลที่มากับ Event ลง Data Layer ไม่ควรทำทันทีที่ Request เข้ามาโดยไม่ตรวจสอบอะไรเลย ควรมีขั้นตอนตรวจ Signature ตามที่อธิบายไว้ใน การตรวจ Signature ของ LINE webhook ก่อนเสมอ เพื่อกันไม่ให้ Request ปลอมมาเขียนข้อมูลผิดลงระบบ

อีกจุดที่ต้องออกแบบคือกรณี Webhook Event เดิมถูกส่งซ้ำจากฝั่ง LINE เมื่อเซิร์ฟเวอร์ตอบช้าหรือมีปัญหาเครือข่ายชั่วคราว ถ้า Data Layer ไม่มีกลไกตรวจว่า Event นี้เคยถูกบันทึกไปแล้วหรือยัง อาจเกิดการเขียนทับหรือสร้าง Record ซ้ำโดยไม่ตั้งใจ วิธีที่ใช้กันคือเก็บ Event ID หรือค่าที่ไม่ซ้ำกันของแต่ละ Event ไว้เป็น Unique Key ก่อนเขียนข้อมูลจริงทุกครั้ง

สุดท้ายควรแยกขั้นตอนรับ Webhook กับขั้นตอนประมวลผลข้อมูลออกจากกัน เช่นรับ Request แล้วตอบกลับ LINE ทันทีว่าได้รับแล้ว จากนั้นค่อยส่งข้อมูลเข้าคิวประมวลผลแยกต่างหาก วิธีนี้ช่วยลดความเสี่ยงที่ปัญหาระหว่างเขียน Data Layer จะทำให้ LINE เห็นว่าเซิร์ฟเวอร์ตอบสนองช้าหรือล้มเหลว จนส่ง Event ซ้ำมาเพิ่มอีก

เก็บ User ID แล้วต้องระวังเรื่องความเป็นส่วนตัวตรงไหนบ้าง

User ID เองไม่ใช่ชื่อหรือเบอร์โทรที่ระบุตัวตนได้ทันที แต่เมื่อผูกกับ Lead ที่มีข้อมูลอย่างชื่อ เบอร์โทร หรือประวัติการสั่งซื้อ ชุดข้อมูลรวมนี้กลายเป็นข้อมูลส่วนบุคคลที่ต้องดูแลตามหลัก Privacy ที่เหมาะสม ไม่ควรเก็บเนื้อหาการสนทนาทั้งหมดไว้ในตารางเดียวกับ User ID โดยไม่จำเป็น และไม่ควรส่ง User ID ดิบไปเป็นพารามิเตอร์ของ Conversion Event ไปยังแพลตฟอร์มโฆษณาที่ไม่รองรับรูปแบบนี้

ควรกำหนดสิทธิ์การเข้าถึงตาราง Identity และ Lead ให้จำกัดเฉพาะทีมที่จำเป็นต้องใช้ พร้อมกำหนดระยะเวลาการเก็บข้อมูลที่เหมาะสมกับลักษณะธุรกิจ ไม่ใช่เก็บไว้ถาวรโดยไม่มีนโยบายชัดเจน และควรเตรียมกระบวนการรองรับคำขอเข้าถึงหรือลบข้อมูลจากเจ้าของข้อมูลตามข้อตกลงและระบบที่มีอยู่

ก่อนเปิดใช้งานจริง ทีมควรตรวจอะไรก่อน

ก่อนนำระบบเก็บ User ID จาก Webhook ไปใช้งานจริงกับแคมเปญที่มีงบโฆษณา ควรทดสอบ Journey จำลองตั้งแต่คลิกโฆษณา ทักเข้า LINE จนถึงสร้าง Lead ในระบบ แล้วตรวจว่า User ID Identifier ต้นทาง และสถานะ Lead ถูกบันทึกครบตามที่ออกแบบไว้จริงหรือไม่ ไม่ใช่แค่ดู Log ว่ามี Event เข้ามาแล้วสรุปว่าใช้งานได้

ธุรกิจที่ไม่อยากพัฒนาระบบรับ Webhook และออกแบบ Data Layer เองทั้งหมด อาจเลือกใช้บริการอย่าง linli ที่จัดการชั้นนี้ให้ในส่วนที่รองรับ แต่การกำหนดว่าอะไรคือ Lead ของธุรกิจตัวเอง และใครเป็นผู้รับผิดชอบตรวจสอบข้อมูลเป็นระยะ ยังเป็นสิ่งที่ทีมต้องวางแผนเองเสมอ ไม่ว่าจะสร้างระบบเองหรือใช้บริการสำเร็จรูปก็ตาม

สุดท้าย ควรตั้งรอบตรวจสอบข้อมูลเป็นประจำ เช่นทุกเดือน เพื่อดูว่ามี User ID ที่ไม่มี Lead ผูกอยู่หลงเหลือในระบบหรือไม่ มี Lead ที่ Identifier ต้นทางหายไปกี่ราย และสัดส่วนนี้เปลี่ยนไปจากเดือนก่อนหน้าอย่างไร เพราะ Data Layer ที่ออกแบบดีในวันแรกอาจเริ่มมีช่องโหว่เมื่อทีมเปลี่ยนคนดูแลหรือเพิ่มแคมเปญใหม่โดยไม่ทบทวนโครงสร้างเดิม

สรุป

การรับ Webhook จาก LINE ได้เป็นแค่จุดเริ่มต้น สิ่งที่ทำให้ User ID มีประโยชน์จริงคือการออกแบบ Data Layer ที่ผูก User ID กับ Lead หนึ่งรายและ Identifier ต้นทางตั้งแต่จุดแรกที่พบ พร้อมกันข้อมูลซ้ำและดูแลเรื่องความเป็นส่วนตัวไปพร้อมกัน

ทีมที่เพิ่งเริ่มออกแบบ Data Layer ไม่จำเป็นต้องทำให้ครบทุกจุดตั้งแต่วันแรก แต่ควรวาง Field ขั้นต่ำและความสัมพันธ์ระหว่างตารางให้ถูกทิศทางตั้งแต่ต้น เพราะการย้อนกลับมาแก้โครงสร้างข้อมูลทีหลังมักใช้แรงมากกว่าการออกแบบให้ถูกตั้งแต่แรกเสมอ

• แยกตาราง Identity, Lead และ Event Log ออกจากกัน อย่าเก็บทุกอย่างในตารางเดียว
• เก็บ Identifier ต้นทางตั้งแต่จุดแรกที่พบ User ID ไม่ใช่รอเติมทีหลัง
• ตรวจ Signature และกัน Event ซ้ำก่อนเขียนลง Data Layer จริงทุกครั้ง

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