5 แคมเปญยิงเข้า LINE พร้อมกัน แต่ระบบนับ Custom Event ได้แค่ตัวเดียว จะแยกยังไง

ทีมการตลาดของธุรกิจแห่งหนึ่งเล่าให้ผมฟังว่า ช่วงโปรโมชันใหญ่พวกเขายิงแอดพร้อมกันถึงห้าแคมเปญ แต่ละแคมเปญใช้ Landing Page คนละหน้าและมีปุ่ม LINE คนละจุด ตั้งใจจะดูว่าแคมเปญไหนพาคนมากดปุ่มมากที่สุด แต่พอเปิดรายงานใน GA4 ขึ้นมากลับเจอ Event ชื่อเดียวคือ click_line ที่รวมทุกแคมเปญปนกันเป็นก้อนเดียว ไม่มีทางแยกได้เลยว่าตัวเลขที่เห็นมาจากแคมเปญไหนบ้าง

ต้นเหตุของปัญหานี้ไม่ใช่ GTM ทำงานผิดพลาด แต่เป็นเพราะตอนออกแบบ Event ตั้งแต่แรก มีการตั้งชื่อ Event แบบกว้าง ๆ ตัวเดียวให้ครอบคลุมทุกสถานการณ์ โดยไม่ได้ผูก Parameter ที่บอกรายละเอียดว่าเหตุการณ์นั้นมาจากแคมเปญไหน ตำแหน่งไหน หรืออยู่ในขั้นตอนใดของ Journey เมื่อข้อมูลไม่มีรายละเอียดพวกนี้ติดไปด้วย ต่อให้เก็บ Event ได้ครบทุกครั้ง ก็ยังใช้วิเคราะห์อะไรต่อไม่ได้อยู่ดี

บทความนี้จะพาไล่ตั้งแต่ทำไม Event เดียวไม่พอสำหรับธุรกิจที่มีหลายแคมเปญหรือหลายจุดสัมผัส ไปจนถึงวิธีออกแบบ Custom Event และ Data Layer ให้แยกแยะได้ชัด พร้อมวิธีตั้งชื่อที่ไม่ชนกันเมื่อธุรกิจโตขึ้นและมีแคมเปญเพิ่มเรื่อย ๆ

ทำไม Event เดียวถึงไม่พอเมื่อธุรกิจมีหลายแคมเปญและหลายจุดสัมผัส

การใช้ Event ชื่อเดียวจับทุกการคลิกปุ่ม LINE อาจดูง่ายและเพียงพอในช่วงที่ธุรกิจยังมีแคมเปญเดียวและปุ่มเดียว เหมือนขั้นตอนพื้นฐานตอนเริ่มตั้ง GTM ให้จับคลิกปุ่ม LINE ครั้งแรก แต่ทันทีที่ขยายมาเป็นหลายแคมเปญพร้อมกัน หรือมีปุ่ม LINE กระจายอยู่หลายจุดบนเว็บ เช่น Header, Popup, ท้ายบทความ หรือ Landing Page เฉพาะโปรโมชัน Event ชื่อเดียวจะกลายเป็นข้อมูลก้อนใหญ่ที่แยกอะไรไม่ออกเลย

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

Custom Event ต่างจาก Standard Event ของ GTM ตรงไหน

GTM มี Trigger สำเร็จรูปบางแบบที่จับพฤติกรรมทั่วไปได้เลย เช่น Click ธรรมดาหรือ Page View แต่สำหรับธุรกิจที่มี Journey เฉพาะของตัวเอง อย่างการเปลี่ยนหน้าไป LINE ผ่านหลายขั้นตอน จำเป็นต้องออกแบบ Custom Event ขึ้นมาเอง เพื่อให้สื่อความหมายตรงกับสิ่งที่ธุรกิจต้องการวัดจริง ไม่ใช่ใช้ Event มาตรฐานที่ไม่ได้ถูกออกแบบมาสำหรับ Journey แบบนี้โดยเฉพาะ

การออกแบบ Custom Event ที่ดีเริ่มจากถามว่า อะไรคือจุดตัดสินใจสำคัญใน Journey ของลูกค้าที่ธุรกิจอยากรู้ ไม่ใช่ไล่จับทุกการคลิกที่เกิดขึ้นบนเว็บ เพราะยิ่งเก็บเยอะโดยไม่มีจุดโฟกัส ยิ่งทำให้ข้อมูลรกและยากต่อการเอาไปใช้ตัดสินใจจริง ถ้าธุรกิจเคยผ่านขั้นออกแบบ Key ป้องกันข้อมูลซ้ำฝั่งเซิร์ฟเวอร์มาแล้ว หลักคิดเรื่องออกแบบให้มีจุดโฟกัสชัดเจนก็ใช้แนวทางเดียวกัน

แผนที่ Event ที่ควรออกแบบตั้งแต่เข้าเว็บจนถึงปุ่ม LINE

ก่อนเปิด GTM ขึ้นมาสร้างอะไร ควรมีแผนที่ Event คร่าว ๆ ที่ทั้งทีมเห็นตรงกันก่อน ตารางนี้เป็นตัวอย่างจุดตั้งต้นที่ปรับตาม Journey จริงของแต่ละธุรกิจได้

ออกแบบ Data Layer ให้รองรับ Custom Event หลายตัวพร้อมกัน

เมื่อมีแผนที่ Event แล้ว ขั้นตอนถัดไปคือออกแบบ Data Layer ให้แต่ละ Event ส่งข้อมูลที่จำเป็นมาครบ ไม่ใช่ปล่อยให้ GTM ต้องเดาเอาเองจาก Class หรือ URL เพียงอย่างเดียว แนวทางระดับแนวคิดมีลำดับประมาณนี้

1. กำหนดชื่อ Event ให้สื่อความหมายและไม่ซ้ำกับ Event อื่นที่มีอยู่แล้วในเว็บ เช่น ใช้ Prefix line_ นำหน้าทุก Event ที่เกี่ยวกับ Journey นี้โดยเฉพาะ
2. ผูกค่า campaign_id หรือชื่อแคมเปญเข้าไปใน Data Layer ตั้งแต่หน้า Landing Page โหลด ไม่ใช่รอไปดึงตอนคลิกปุ่มอย่างเดียว เพราะบางหน้าอาจไม่มีค่านี้ติดมาจาก URL ตรง ๆ
3. ให้แต่ละปุ่ม LINE บนเว็บมี Attribute หรือ Data Layer เฉพาะของตัวเองที่บอกตำแหน่งและบริบท เพื่อให้ Trigger เดียวใน GTM ดึงค่าที่ถูกต้องออกมาได้โดยไม่ต้องสร้าง Trigger แยกทีละปุ่ม
4. ทดสอบผ่าน Preview Mode โดยจำลองการเข้าเว็บจากหลายแคมเปญพร้อมกัน แล้วเช็คว่า Event ที่ยิงออกมามี Parameter ที่แยกแคมเปญได้ถูกต้องจริง

ตั้งชื่อ Event ให้ไม่ชนกันเมื่อธุรกิจมีแคมเปญเพิ่มขึ้นเรื่อย ๆ

ปัญหาที่ตามมาเมื่อธุรกิจเริ่มมีหลายแคมเปญพร้อมกันบ่อยขึ้น คือชื่อ Event หรือ Trigger ที่เคยตั้งไว้แบบเฉพาะกิจ เช่น click_line_promo1 เริ่มพอกพูนจนดูแลไม่ไหว ทุกครั้งที่มีแคมเปญใหม่ต้องมาสร้าง Event ใหม่อีกตัว ทำให้ระบบรกและเสี่ยงตั้งชื่อซ้ำกันโดยไม่รู้ตัว

แนวทางที่ยั่งยืนกว่าคือใช้ Event ชื่อเดียวกันสำหรับพฤติกรรมแบบเดียวกัน เช่น click_line_button ตัวเดียว แล้วให้ campaign_id ใน Parameter เป็นตัวแยกว่ามาจากแคมเปญไหนแทน วิธีนี้ทำให้โครงสร้างลิงก์ที่มี UTM ติดตามอยู่แล้วเชื่อมเข้ากับ Event ได้ง่ายขึ้น โดยไม่ต้องสร้าง Event ใหม่ทุกครั้งที่มีแคมเปญเพิ่ม

เทส Custom Event หลายตัวพร้อมกันไม่ให้ยิงซ้ำหรือหายไปกลางทาง

เมื่อมี Event หลายตัวทำงานพร้อมกันในหน้าเดียว ความเสี่ยงที่ตามมาคือ Event บางตัวยิงซ้ำโดยไม่ตั้งใจ เช่น view_line_section ที่ยิงทุกครั้งที่ผู้ใช้เลื่อนผ่านส่วนนั้นไปมา หรือบาง Event หายไปเพราะ Trigger ตัวหนึ่งเขียนทับค่าของอีกตัวใน Data Layer โดยไม่รู้ตัว

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

เอา Custom Event ที่แยกได้ไปใช้ทำรายงานเปรียบเทียบแคมเปญ

เมื่อออกแบบ Event และ Parameter ถูกต้องแล้ว การเปรียบเทียบแคมเปญจะทำได้ง่ายขึ้นมาก เพราะสามารถกรองรายงานใน GA4 ตามค่า campaign_id ที่แนบมากับทุก Event ได้โดยตรง ไม่ต้องมานั่งเดาว่าตัวเลขก้อนไหนมาจากแคมเปญไหน และยังเห็นได้ด้วยว่าแคมเปญไหนพาคนมาถึงขั้น view_line_section เยอะ แต่ไปต่อไม่ถึงขั้น click_line_button ซึ่งบอกว่าปัญหาน่าจะอยู่ที่ตัว Creative หรือข้อความรอบปุ่มมากกว่าตัวแคมเปญเอง

ถ้าธุรกิจต้องการเห็นภาพต่อยาวไปถึง Lead และยอดขายจริงในแชท ไม่ใช่แค่ Event บนเว็บ อาจพิจารณาใช้ระบบอย่าง linli ที่ออกแบบมาให้ผูก Custom Event เหล่านี้เข้ากับสถานะ Lead ในภายหลังได้ตาม Integration ที่รองรับ แต่ไม่ว่าจะใช้เครื่องมือไหน รากฐานที่สำคัญที่สุดยังคงเป็นการออกแบบ Event และ Parameter ให้ถูกต้องตั้งแต่ต้นทาง

ดูแลระบบ Event ระยะยาวเมื่อทีมการตลาดเปลี่ยนแคมเปญบ่อย

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

แนวทางที่ช่วยลดความผิดพลาดคือทำเอกสารมาตรฐานการตั้งชื่อแคมเปญและ UTM ไว้ให้ทีมการตลาดอ้างอิงทุกครั้งก่อนปล่อยแคมเปญใหม่ และมอบหมายให้มีคนตรวจสอบ Preview Mode ของ GTM ก่อน Publish ทุกครั้งที่มีการเพิ่มหรือแก้ Trigger ที่เกี่ยวกับ Event เหล่านี้ เพื่อไม่ให้ระบบพังกลางแคมเปญโดยไม่มีใครรู้ตัว

ตัวอย่างสมมติ เมื่อธุรกิจหนึ่งวางแคมเปญห้าตัวพร้อมกันจริง

ลองนึกภาพธุรกิจร้านฟิตเนสที่วางแผนโปรโมชันเปิดสาขาใหม่ ยิงแอดพร้อมกันห้าแคมเปญในเวลาเดียวกัน แคมเปญแรกเจาะกลุ่มคนที่เคยเข้าเว็บมาก่อน แคมเปญที่สองเจาะกลุ่มคนใหม่ในรัศมีใกล้สาขา แคมเปญที่สามเป็น Video Ad บน TikTok แคมเปญที่สี่เป็น Carousel บน Facebook และแคมเปญที่ห้าเป็น Search Ads บน Google แต่ละแคมเปญพาไปคนละ Landing Page ที่มีข้อความและปุ่ม LINE ออกแบบต่างกันเล็กน้อยตามกลุ่มเป้าหมาย

ถ้าตอนออกแบบ Event ทั้งห้า Landing Page ใช้ Trigger เดียวกันที่จับแค่ ‘คลิกปุ่มที่มีคำว่า line.me ใน URL’ โดยไม่มีการแนบ campaign_id ที่ต่างกันตามแต่ละหน้า ผลลัพธ์ที่ได้คือ Event click_line_button ก้อนเดียวที่ปนกันหมดทั้งห้าแคมเปญ ทีมการตลาดจะเห็นแค่ยอดรวมว่ามีคนคลิกกี่ครั้ง แต่ตอบไม่ได้เลยว่าแคมเปญ Video บน TikTok กับ Search Ads บน Google ตัวไหนพาคนมากดปุ่มได้มากกว่ากัน ทั้งที่ทั้งสองช่องทางใช้งบประมาณและวิธีคิด Creative ต่างกันโดยสิ้นเชิง

ในทางกลับกัน ถ้าตั้งแต่สร้าง Landing Page แต่ละหน้า มีการฝังค่า campaign_id ไว้ใน Data Layer ตามที่ระบุไว้ในตอนต้น เช่น fitness-newbranch-retarget, fitness-newbranch-nearby, fitness-newbranch-tiktok, fitness-newbranch-fb, fitness-newbranch-google เมื่อคนคลิกปุ่ม LINE จากหน้าไหน Event ที่ยิงออกมาจะพก campaign_id นั้นติดไปด้วยเสมอ ทำให้เปิดรายงานมาแล้วกรองแยกได้ทันทีว่าแต่ละแคมเปญทำผลงานต่างกันแค่ไหน โดยไม่ต้องสร้าง Event ใหม่ห้าตัวให้ซับซ้อนเกินจำเป็น

สรุป

การยิงหลายแคมเปญพร้อมกันแล้วระบบนับ Event ได้ก้อนเดียวปนกันหมด ไม่ใช่เพราะ GTM ทำงานผิด แต่เพราะตอนออกแบบ Event ไม่ได้ผูก Parameter ที่บอกบริบทของแต่ละแคมเปญไว้ตั้งแต่ต้น การแก้จึงไม่ใช่การสร้าง Event ใหม่เพิ่มเรื่อย ๆ แต่คือการกลับไปออกแบบ Data Layer ให้รองรับรายละเอียดที่จำเป็น

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

• Event ชื่อเดียวที่ไม่มี Parameter บอกบริบท คือสาเหตุหลักที่ทำให้แยกแคมเปญไม่ออก ไม่ใช่ปัญหาของ GTM เอง
• ออกแบบ Data Layer ให้มี campaign_id และรายละเอียดตำแหน่งติดไปกับทุก Event ตั้งแต่ต้น ไม่ใช่แก้ทีหลัง
• ตั้งชื่อ Event ให้ยืดหยุ่นรองรับแคมเปญใหม่ในอนาคต แทนที่จะสร้าง Event เฉพาะกิจทีละแคมเปญไปเรื่อย ๆ

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