เพิ่มเพื่อนเดือนละหลักพันคน แต่ไม่รู้เลยว่าใครซื้อซ้ำในอีกครึ่งปีถัดมา

ร้านค้าออนไลน์แห่งหนึ่งมีเพื่อนใน LINE OA สะสมมากกว่าสามหมื่นคนหลังทำแคมเปญมาต่อเนื่องสองปี ทุกเดือนมีคนเพิ่มเพื่อนใหม่หลักพันคน แต่พอเจ้าของร้านถามว่า 'ลูกค้าที่ซื้อครั้งแรกเมื่อหกเดือนก่อน มีกี่คนที่กลับมาซื้อซ้ำแล้วบ้าง' กลับไม่มีใครในทีมตอบได้เลย เพราะไม่มีระบบไหนเก็บ Journey ของลูกค้าแต่ละคนย้อนหลังได้ไกลขนาดนั้น

ปัญหานี้ต่างจากปัญหาที่ธุรกิจเล็กเจอ เพราะเมื่อฐานลูกค้าโตถึงระดับหมื่นถึงแสนคน เครื่องมืออย่าง Google Sheets เริ่มรับภาระไม่ไหว ทั้งเรื่องความเร็วในการโหลดและความสามารถในการเก็บข้อมูลย้อนหลังหลายเดือนหลายปี จุดนี้เองที่ทีมเทคนิคเริ่มมองหา Data Warehouse อย่าง BigQuery มาเป็นที่เก็บข้อมูลระยะยาว

บทความนี้จะพาไปดูว่า BigQuery เก็บ Event จาก LINE OA ได้อย่างไรจริง ๆ ใช้วิเคราะห์การซื้อซ้ำและพฤติกรรมระยะยาวได้แค่ไหน และธุรกิจแบบไหนที่ควรเริ่มลงทุนกับ Data Warehouse ระดับนี้ ก่อนที่ฐานข้อมูลจะใหญ่จนจัดการไม่ทัน

BigQuery คืออะไร แล้วเกี่ยวข้องกับ LINE OA ตรงไหน

BigQuery เป็น Data Warehouse บนคลาวด์ของ Google ออกแบบมาเพื่อเก็บและประมวลผลข้อมูลปริมาณมากด้วยความเร็วสูง ต่างจาก Google Sheets ที่เหมาะกับข้อมูลหลักพันแถว BigQuery รองรับข้อมูลระดับหลายล้านแถวได้โดยไม่มีปัญหาเรื่องความเร็ว

ในบริบทของ LINE OA, BigQuery ไม่ได้เชื่อมกับ LINE โดยตรงเช่นเดียวกับเครื่องมืออื่นในกลุ่มนี้ ต้องมีตัวกลางที่รับ Event จาก LINE Messaging API Webhook แล้วส่งต่อเข้าไปเก็บใน BigQuery อีกที ซึ่งอาจเป็น Cloud Function ที่เขียนขึ้นเอง หรือใช้เครื่องมือ No-code บางตัวที่รองรับปลายทางเป็น BigQuery

จุดที่ทำให้ BigQuery ต่างจากการเก็บใน Sheet คือความสามารถเขียน Query ด้วยภาษา SQL เพื่อวิเคราะห์ข้อมูลข้ามช่วงเวลายาว ๆ ได้ เช่น หาว่าลูกค้าที่ซื้อครั้งแรกในเดือนมกราคม มีกี่เปอร์เซ็นต์ที่กลับมาซื้อซ้ำภายในหกเดือน ซึ่งเป็นคำถามที่ Sheet ทำได้ยากเมื่อข้อมูลมีปริมาณมาก

หลายทีมเข้าใจผิดว่า BigQuery เป็นเครื่องมือสำหรับนักพัฒนาเท่านั้น แต่ในความเป็นจริงคนที่พอเขียน SQL พื้นฐานได้ก็เริ่มใช้งานได้ ความยากส่วนใหญ่ไม่ได้อยู่ที่การเขียน Query แต่อยู่ที่การออกแบบ Pipeline ที่ส่งข้อมูลเข้าไปให้ครบและสม่ำเสมอ ซึ่งเป็นงานที่ต้องใช้ความเข้าใจระบบมากกว่าความเข้าใจภาษา SQL เพียงอย่างเดียว

หน้าตา Pipeline ที่ส่ง Event จาก LINE เข้า BigQuery เป็นอย่างไร

รูปแบบทั่วไปเริ่มจาก LINE Messaging API ส่ง Webhook มาที่ Endpoint ที่ทีมเทคนิคตั้งไว้ เช่น Cloud Function หรือ Cloud Run แล้วโค้ดในนั้นจะแปลง Event ให้อยู่ในรูปแบบตารางที่กำหนดไว้ล่วงหน้า ก่อนจะยิงคำสั่ง Insert เข้า BigQuery

อีกแบบที่พบได้คือใช้เครื่องมือ No-code อย่างที่กล่าวถึงใน การต่อ Make กับ LINE OA เป็นตัวกลางรับ Webhook แล้วส่งต่อเข้า BigQuery ผ่าน Module ที่รองรับ วิธีนี้ตั้งค่าง่ายกว่าแต่มีข้อจำกัดเรื่องปริมาณ Event ตามแผนที่ใช้และความยืดหยุ่นในการปรับโครงสร้างตารางเอง

ไม่ว่าจะเลือกวิธีไหน สิ่งที่ต้องออกแบบให้ดีตั้งแต่แรกคือ Schema ของตาราง ควรมีคอลัมน์ User ID, ประเภท Event, เวลาที่เกิด Event, และถ้าเป็นไปได้ควรมี Order ID หรือ Reference ที่เชื่อมกับระบบขายด้วย เพราะถ้า Schema ออกแบบไม่ดีตั้งแต่ต้น การแก้ไขภายหลังเมื่อข้อมูลสะสมไปมากแล้วจะยุ่งยากกว่ามาก

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

วิเคราะห์การซื้อซ้ำจากข้อมูลใน BigQuery ทำอย่างไร

1. กำหนดนิยาม 'ลูกค้าที่ซื้อซ้ำ' ให้ชัดก่อนเขียน Query เช่น ลูกค้าที่มี Order มากกว่าหนึ่งรายการภายในระยะเวลาที่กำหนด ไม่ใช่แค่ทักเข้ามาซ้ำโดยไม่มีการซื้อ
2. เขียน Query เชื่อมตาราง Event การซื้อกับ User ID เดียวกัน แล้วนับจำนวน Order ต่อคนในแต่ละช่วงเวลา เพื่อแยกกลุ่มลูกค้าที่ซื้อครั้งเดียวออกจากกลุ่มที่ซื้อซ้ำ
3. จัดกลุ่มลูกค้าตามเดือนที่ซื้อครั้งแรก (Cohort) แล้วดูว่าแต่ละกลุ่มมีอัตราการกลับมาซื้อซ้ำในเดือนถัดไปเท่าไร วิธีนี้ช่วยให้เห็นแนวโน้มว่าคุณภาพลูกค้าที่ได้มาในแต่ละช่วงต่างกันหรือไม่
4. เชื่อมผลลัพธ์กับข้อมูลแคมเปญต้นทาง ถ้ามี Tracking Link ผูกไว้ตั้งแต่แรก เพื่อดูว่าลูกค้าที่มาจากแคมเปญไหนมีแนวโน้มซื้อซ้ำสูงกว่ากัน ซึ่งเป็นข้อมูลที่ช่วยตัดสินใจเรื่องงบโฆษณาระยะยาวได้ดีกว่าดูแค่ยอด Order ครั้งแรก
5. สร้างตารางสรุปผลลัพธ์แล้วส่งต่อไปแสดงผลผ่านเครื่องมือ Dashboard เช่น Looker Studio หรือ Power BI เพื่อให้ทีมที่ไม่ถนัด SQL เข้าถึงข้อมูลนี้ได้ง่ายขึ้นโดยไม่ต้องเขียน Query เอง

ปริมาณข้อมูลกับต้นทุนที่ควรรู้ก่อนเริ่มใช้ BigQuery

BigQuery คิดค่าใช้จ่ายตามปริมาณข้อมูลที่ประมวลผลต่อ Query และปริมาณที่จัดเก็บ ตารางนี้เป็นตัวอย่างสมมติเพื่อให้เห็นภาพว่าขนาดฐานลูกค้าส่งผลต่อการพิจารณาใช้งานอย่างไร ตัวเลขจริงต้องตรวจราคาปัจจุบันจากหน้า Pricing ของ Google Cloud:

สัญญาณที่บอกว่ายังไม่ควรเริ่มทำ Pipeline เข้า BigQuery

• ยังไม่มีทีมเทคนิคที่ดูแล Pipeline ต่อเนื่อง — ถ้า Cloud Function หรือ Script ที่ส่งข้อมูลพังแล้วไม่มีใครรู้ตัว ข้อมูลจะขาดช่วงโดยไม่มีการแจ้งเตือน
• ฐานเพื่อนใน LINE OA ยังไม่ถึงหลักหมื่น — ปริมาณระดับนี้ Sheet ที่มีโครงสร้างดียังตอบโจทย์ได้โดยไม่ต้องเพิ่มความซับซ้อน
• ยังไม่มีคำถามเชิงวิเคราะห์ระยะยาวที่ชัดเจน — ถ้าธุรกิจยังโฟกัสที่การปิดการขายรอบแรก การลงทุนกับ Data Warehouse เพื่อวิเคราะห์ Cohort อาจเร็วเกินไป
• ไม่มีงบสำหรับดูแลระบบต่อเนื่อง — BigQuery มีค่าใช้จ่ายตามการใช้งานจริง ถ้าไม่มีคนตรวจสอบ Query ที่เขียนไม่ดีอาจทำให้ค่าใช้จ่ายพุ่งขึ้นโดยไม่รู้ตัว

คุณภาพข้อมูลที่ต้องดูแลเป็นพิเศษเมื่อวิเคราะห์ระยะยาว

การวิเคราะห์ข้ามหลายเดือนหลายปีมีความเสี่ยงเรื่องคุณภาพข้อมูลมากกว่าการดูรายงานรายวัน เพราะถ้ามีช่วงที่ Pipeline ขาดหายไปสองสามวันโดยไม่มีใครสังเกต ข้อมูลของช่วงนั้นจะหายไปถาวรและทำให้ผลการวิเคราะห์ Cohort ของเดือนนั้นผิดเพี้ยนไปทั้งกลุ่ม

อีกจุดที่ต้องระวังคือการเปลี่ยนแปลงนิยามระหว่างทาง เช่น ถ้าทีมเปลี่ยนเกณฑ์ว่าอะไรคือ 'Order' กลางปี แล้วไม่มีการบันทึกว่าเปลี่ยนตอนไหน การเปรียบเทียบข้อมูลก่อนและหลังการเปลี่ยนแปลงจะทำให้สรุปผิดได้ ควรบันทึกวันที่เปลี่ยนนิยามไว้เป็นหลักฐานเสมอ เพื่อให้คนที่มาวิเคราะห์ทีหลังรู้ว่าต้องแบ่งช่วงข้อมูลตรงไหน

Time Zone เป็นอีกจุดที่มักถูกมองข้ามเมื่อข้อมูลสะสมข้ามปี ถ้า Event บางส่วนถูกบันทึกเป็น UTC และบางส่วนถูกบันทึกเป็นเวลาไทยโดยไม่มีการระบุให้ชัดเจนในตาราง การนับ Cohort ตามเดือนอาจคลาดเคลื่อนไปหนึ่งวันในบางกรณี ซึ่งดูเหมือนเรื่องเล็กแต่ส่งผลต่อความแม่นยำของการวิเคราะห์ระยะยาวได้มากกว่าที่คิด ควรกำหนด Time Zone มาตรฐานเดียวให้ทุกตารางใช้ร่วมกันตั้งแต่ต้น

ธุรกิจที่เริ่มทำ Pipeline เข้า BigQuery ควรมีกระบวนการ QA อย่างน้อยเดือนละครั้ง ตรวจว่าจำนวน Event ที่เข้ามาสอดคล้องกับที่ควรจะเป็นหรือไม่ เทียบกับตัวเลขคร่าว ๆ จาก LINE Official Account Manager เพื่อจับความผิดปกติได้เร็วก่อนที่จะสะสมเป็นปัญหาใหญ่

การกันข้อมูลซ้ำก็ต้องพิจารณาแยกจากการกันข้อมูลหาย เพราะทั้งสองปัญหาส่งผลตรงข้ามกันต่อผลวิเคราะห์ Cohort ข้อมูลซ้ำทำให้ตัวเลขลูกค้าดูสูงเกินจริง ขณะที่ข้อมูลหายทำให้ตัวเลขดูต่ำเกินจริง ถ้าไม่แยกตรวจทั้งสองเรื่องให้ชัด อาจเข้าใจผิดว่าปัญหาหนึ่งชดเชยอีกปัญหาหนึ่งพอดี ทั้งที่ความจริงทั้งสองอย่างบิดเบือนผลลัพธ์คนละทิศทาง

จุดที่ต่างจากสิ่งที่ระบบวัดผลอย่าง linli ทำ

BigQuery เหมาะกับการเก็บและวิเคราะห์ Event ดิบปริมาณมากในลักษณะที่ยืดหยุ่นตามที่ทีมเทคนิคออกแบบเอง แต่ต้องมีคนเขียน Query และดูแล Pipeline ต่อเนื่อง ซึ่งเป็นงานที่ต้องใช้ทักษะเฉพาะทาง

linli เน้นการผูก Journey ตั้งแต่คลิกโฆษณาไปจนถึงยอดขายในรูปแบบที่ธุรกิจทั่วไปใช้งานได้โดยไม่ต้องเขียน SQL เอง เหมาะกับทีมที่ต้องการเห็นว่าแคมเปญไหนสร้างผลลัพธ์โดยไม่ต้องมีนักวิเคราะห์ข้อมูลประจำ ส่วนธุรกิจที่มีฐานข้อมูลใหญ่มากและต้องการความยืดหยุ่นสูงสุดในการวิเคราะห์ระยะยาว การมี Data Warehouse เช่น BigQuery ควบคู่ไปด้วยก็ยังเป็นทางเลือกที่สมเหตุสมผล

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

สรุป

ฐานเพื่อนใน LINE OA ที่โตขึ้นทุกเดือนเป็นสัญญาณที่ดีของการตลาด แต่ถ้าไม่มีระบบเก็บข้อมูลที่รองรับการวิเคราะห์ระยะยาว คำถามสำคัญอย่าง 'ใครซื้อซ้ำ' จะยังคงตอบไม่ได้ต่อไปเรื่อย ๆ ไม่ว่าฐานลูกค้าจะใหญ่แค่ไหน

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

• BigQuery เก็บ Event จาก LINE OA ได้ผ่าน Pipeline ที่ทีมเทคนิคต้องสร้างและดูแลเอง ไม่มี Connector ต่อตรง
• เหมาะกับธุรกิจที่มีฐานเพื่อนหลักหมื่นขึ้นไปและต้องการวิเคราะห์พฤติกรรมระยะยาวอย่างการซื้อซ้ำ
• ต้องออกแบบ Schema และดูแลคุณภาพข้อมูลอย่างสม่ำเสมอ เพราะข้อมูลที่ขาดช่วงจะกระทบผลวิเคราะห์ทั้ง Cohort
• ธุรกิจขนาดเล็กที่ยังไม่มีทีมเทคนิคควรเริ่มจากเครื่องมือที่ง่ายกว่าก่อน แล้วค่อยขยับมาเมื่อข้อมูลใหญ่พอ

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