แท็กยิงไม่ทันหน้าแรก ทำให้ค่า UTM หายตั้งแต่ก้าวแรกของลูกค้า
สรุปสั้น ๆ
UTM หายตั้งแต่หน้าแรกเมื่อมีบางอย่างอ่านหรือแก้ URL ก่อนแท็กของคุณทำงาน เช่นเว็บเฟรมเวิร์กล้าง query string แท็กที่รอ Window Loaded หรือรอ consent นานกว่าที่ลูกค้ากดปุ่ม LINE และคำขอส่งข้อมูลที่ถูกตัดเพราะหน้าเปลี่ยนก่อนส่งเสร็จ ทางแก้คือย้ายการเก็บค่าไปไว้จุดที่เร็วที่สุดของหน้า แยกจากแท็กรายงาน แล้วให้ลิงก์ LINE รอแท็กยิงเสร็จก่อนพาลูกค้าออก
ลองนึกถึงร้านขายอุปกรณ์ออกกำลังกายที่ยิงแอด Meta เข้าหน้า Landing Page แล้วให้ลูกค้ากดปุ่มไป LINE สมมติว่าใน GA4 การกดปุ่ม LINE ร้อยครั้ง มี 40 ครั้งที่ขึ้นเป็น (direct) ทั้งที่หน้านั้นไม่มีทราฟฟิกอื่นเลย ทีมเปิด GTM Preview ทดสอบ แท็กยิงครบ UTM ติดทุกครั้ง เลยสรุปว่า GA4 เก็บข้อมูลมั่ว
Preview ที่ทดสอบอยู่บนไฟเบอร์ในออฟฟิศ ด้วยคอมที่แรง ส่วนลูกค้าจริงอยู่บนมือถือ 4G บนรถไฟฟ้า เห็นปุ่ม LINE ก็กดทันทีก่อนที่หน้าจะโหลดเสร็จด้วยซ้ำ ปัญหาอยู่ที่เวลา ไม่ได้อยู่ที่การตั้งค่า และมันต่างจากกรณีที่แท็กไม่ยิงเลย ซึ่งอธิบายไว้ใน เรื่องปุ่ม LINE ไม่ยิง event กรณีนี้แท็กยิง แต่ยิงช้ากว่าเหตุการณ์ที่ทำลายข้อมูล
จุดที่แท็กแพ้เวลา
| จุดที่แพ้ | สิ่งที่เกิดขึ้น | ร่องรอยที่เห็นในข้อมูล |
|---|---|---|
| URL ถูกแก้ก่อนแท็กอ่าน | เฟรมเวิร์กหรือสคริปต์เรียก history.replaceState ล้าง query string หรือ redirect จาก http ไป https และจากไม่มี www ไปมี www ทำพารามิเตอร์หาย | page_location ของ page_view ไม่มี utm_ ติดมาเลย |
| แท็กผูกกับ trigger ที่ช้า | แท็กรอ Window Loaded หรือรอผู้ใช้ตอบ banner ลูกค้ากดปุ่ม LINE ไปก่อน | page_view มาช้าหรือไม่มา และ line_click ไปอยู่ใน (direct) |
| หน้าเปลี่ยนก่อนส่งข้อมูลเสร็จ | ปุ่มเปิด line.me ในแท็บเดิม คำขอที่ยังไม่เสร็จถูกตัด | line_click หายเป็นช่วง ยอดต่ำกว่าจำนวนที่เห็นฝั่ง LINE |
ทำให้เกิดซ้ำบนเครื่องตัวเอง ด้วยเน็ตช้าและนิ้วเร็ว
การเถียงกันว่าเกิดจริงไหมเสียเวลากว่าการทดสอบ ผมทำแบบนี้ก่อนจะแก้อะไร:
- เปิด Chrome DevTools ไปแท็บ Network ตั้ง Throttling เป็น Slow 4G และเปิด Performance ตั้ง CPU เป็น 4x slowdown
- เปิดหน้าด้วย URL ที่ใส่ UTM ทดสอบ เช่น
?utm_source=test&utm_medium=cpc&utm_campaign=raceแล้วกดปุ่ม LINE ให้เร็วที่สุดเท่าที่ปุ่มปรากฏ - ดูคำขอที่ชื่อ collect ใน Network ว่ามีหรือไม่ มีสถานะ canceled หรือไม่ และพารามิเตอร์ dl (ที่อยู่หน้า) ยังมี utm_ ติดอยู่หรือเปล่า
- เปิด Application > Cookies ดูว่าคุกกี้เก็บ UTM ของคุณถูกเขียนก่อนที่เบราว์เซอร์ออกจากหน้าหรือไม่
- ทำซ้ำสิบครั้งและจดว่ากี่ครั้งที่ UTM หาย ถ้าผลเป็นศูนย์จากสิบครั้ง ลองเพิ่มความเร็วในการกดหรือเปลี่ยนเป็น Fast 3G
เก็บ UTM ให้เร็วที่สุด และแยกจากแท็กรายงาน
หลักที่ผมใช้คือแท็กรายงานอย่าง GA4 และ pixel ช้าได้ แต่การจดค่า UTM ลงเครื่องลูกค้าต้องเกิดเป็นอย่างแรก ถ้าค่าอยู่ในคุกกี้ของโดเมนตัวเองแล้ว ต่อให้แท็กอื่นแพ้เวลา ปุ่ม LINE ก็ยังอ่านค่าไปแนบกับลิงก์ได้ ตัวอย่างวิธีเก็บค่าอยู่ใน เก็บ UTM ก่อนเข้า LINE ด้วย GTM
- ใส่สคริปต์สั้น ๆ ใน
<head>ก่อน snippet ของ GTM ให้อ่าน location.search แล้วเขียนค่า utm_, gclid, fbclid, ttclid ลงคุกกี้ของโดเมนตัวเองเมื่อมีค่า - ถ้าแก้โค้ดหน้าเว็บไม่ได้ ให้ใช้แท็ก Custom HTML ที่ผูกกับ trigger Initialization - All Pages ซึ่งยิงก่อน Page View
- ตั้งให้แท็กรายงานใช้ Tag sequencing เป็น setup tag ตัวนี้ หรือกำหนดลำดับด้วย Tag priority ที่ตัวเลขสูงกว่ายิงก่อน
- ให้คุกกี้เขียนทับเฉพาะเมื่อมีค่าใหม่ เพื่อไม่ให้การรีเฟรชหน้าหลัง URL ถูกล้างลบค่าเดิมทิ้ง
ไม่ให้การเปลี่ยนหน้าตัดการส่งข้อมูล
ถ้าปุ่ม LINE เป็นลิงก์ธรรมดา trigger แบบ Click ที่ใช้ Link Click มีตัวเลือก Wait for Tags ที่ให้เบราว์เซอร์รอแท็กทำงานเสร็จก่อนไปตามลิงก์ พร้อมเวลารอสูงสุด ผมตั้งไว้ราว 1,000 มิลลิวินาที เพราะนานกว่านั้นลูกค้าจะรู้สึกว่าปุ่มค้าง
ถ้าปุ่มเป็น JavaScript ที่สั่งเปลี่ยนหน้าเอง ให้ฝั่งเว็บ push เข้า dataLayer พร้อม eventCallback แล้วค่อยพาไป LINE ในฟังก์ชันนั้น รูปแบบที่ใช้ได้คือ dataLayer.push({event: 'line_click', eventCallback: go, eventTimeout: 1000}) ตัว eventTimeout กันไว้ไม่ให้ลูกค้าค้างหากแท็กไม่ตอบ วิธีนี้ลดโอกาสสูญหายแต่ไม่รับประกันเต็มร้อย การเปิด LINE ในแท็บใหม่ช่วยอีกชั้น แต่ in-app browser บางตัวจัดการแท็บใหม่ต่างจากเบราว์เซอร์ปกติ
กรณีที่ปุ่มหลายจุดบนหน้าเดียวกัน ตั้ง trigger ให้ครอบทุกจุดตามที่เขียนไว้ใน trigger ปุ่ม LINE หลายจุด
แท็กที่รอ consent ก็แพ้เวลาได้เหมือนกัน
เว็บที่มี cookie banner มักตั้งให้แท็กวิเคราะห์รอจนผู้ใช้กดยอมรับ ถ้าลูกค้ากดปุ่ม LINE ก่อนตอบ banner แท็กจะยังไม่เคยยิง ข้อมูลหน้าแรกจึงไม่ถูกเก็บเลย และพออนุญาตทีหลัง URL อาจถูกเปลี่ยนไปแล้ว
สิ่งที่ปรับได้คือเก็บ UTM ไว้ก่อนตั้งแต่ต้นหน้า แล้วส่งค่าไปกับ event เมื่อมีการอนุญาต ส่วนการเก็บค่าก่อนผู้ใช้ตอบ banner ต้องตรวจกับผู้รับผิดชอบด้านข้อมูลของลูกค้าว่าอยู่ในขอบเขตที่แจ้งไว้ในนโยบายหรือไม่ การตั้ง Consent Mode ให้แท็กทำงานตามสถานะ อ่านเพิ่มที่ Consent Mode กับ conversion ใน LINE
วัดผลด้วยสัดส่วนเดียว
ตัวเลขที่ผมใช้ตัดสินว่าแก้แล้วได้ผลคือสัดส่วนของ line_click ที่มี utm_source ครบ บนหน้าที่รับเฉพาะทราฟฟิกจากแอด ตัวอย่างสมมติจาก 100 line_click ก่อนแก้มี utm_source 62 ครั้ง หลังย้ายการเก็บค่าไปไว้ต้นหน้าและให้ปุ่มรอแท็ก เพิ่มเป็น 94 ครั้ง ที่เหลือน่าจะเป็นคนที่เปิดลิงก์ซ้ำจากบุ๊กมาร์กหรือเปิดต่อจากการแชร์ ซึ่งไม่มี UTM มาตั้งแต่ต้น
สรุป
ก่อนไล่แก้แท็กทีละตัว ให้ทดสอบด้วยเน็ตช้าและนิ้วเร็วก่อน แล้ววัดสัดส่วน line_click ที่ไม่มี utm_source บนหน้าที่รับเฉพาะแอด ถ้าสัดส่วนนั้นสูง แปลว่าเวลาคือปัญหา ไม่ใช่ตำแหน่งของแท็ก
ถ้ามีทางเลือกเดียวที่จะลงแรงได้ ให้ลงที่การจดค่า UTM ลงคุกกี้ของโดเมนตัวเองก่อนอย่างอื่น เพราะค่าที่จดไว้แล้วรอดแม้แท็กอื่นแพ้เวลา
- สามจุดที่แพ้เวลาคือ URL ถูกล้าง แท็กรอ trigger ที่ช้า และหน้าเปลี่ยนก่อนส่งเสร็จ
- ทดสอบด้วย Slow 4G และ CPU throttle ไม่ใช่ด้วยคอมในออฟฟิศ
- ใช้ Initialization trigger เก็บ UTM และ Wait for Tags หรือ eventCallback ที่ปุ่ม LINE
- วัดด้วยสัดส่วน line_click ที่มี utm_source ครบ
คำถามที่พบบ่อย
แท็ก GA4 ควรใช้ trigger ไหน Page View หรือ Window Loaded
ใช้ Page View ซึ่งยิงเร็วกว่ามาก Window Loaded รอให้รูปและสคริปต์ทุกตัวโหลดเสร็จ จึงเหมาะกับแท็กที่ต้องรอเนื้อหาเท่านั้น ไม่เหมาะกับแท็กที่ต้องจับพารามิเตอร์ของหน้าแรก
GA4 เก็บ campaign ให้อยู่แล้ว ทำไมต้องเก็บ UTM เอง
GA4 อ่านค่าจาก page_location ของหน้าแรกของเซสชัน แต่ข้อมูลนั้นอยู่ใน GA4 คุณไม่ได้ตัวค่ามาติดกับลีดฝั่ง LINE ตอนที่ลูกค้ากดทัก ถ้าอยากผูกยอดขายในแชทกลับไปหาแคมเปญ ต้องมีสำเนาค่าที่คุณเก็บเอง
เว็บ Next.js หรือ React ล้าง query string เอง แก้ยังไง
ให้สคริปต์เก็บค่าทำงานก่อนที่เฟรมเวิร์กจะ hydrate หรือก่อน router เปลี่ยน URL วางไว้ใน head ของ HTML ที่เซิร์ฟเวอร์ส่งออก หรือเก็บฝั่งเซิร์ฟเวอร์ใน middleware ก่อนส่งหน้า
ตั้ง Wait for Tags แล้วหน้าจะช้าไหม
ช้าได้เท่ากับเวลารอสูงสุดที่ตั้งไว้เฉพาะตอนที่แท็กยังไม่ตอบ ถ้าแท็กตอบเร็ว ลูกค้าแทบไม่รู้สึก จึงตั้งเพดานไว้ราวหนึ่งวินาที และเช็คบนมือถือจริงด้วย
ใช้กับ gclid และ fbclid ได้ไหม
ได้ หลักการเดียวกัน อ่านค่าตั้งแต่ต้นหน้าแล้วเก็บ ระวังว่าคุกกี้ที่เขียนด้วย JavaScript ใน Safari อายุสั้นกว่า จึงควรพิจารณาเก็บฝั่งเซิร์ฟเวอร์ถ้าลูกค้ากลับมาหลังหลายวัน
ลองตรวจด้วยตัวเอง
Attribution Data-Loss Simulator
จำลองเส้นทางลิงก์ของคุณทีละ hop แล้วดูว่า UTM กับ Click ID ขาดตรงจุดไหน
หาจุดที่ข้อมูลหายใช้ฟรี ไม่ต้องสมัคร ไม่เก็บข้อมูลที่คุณกรอก
อ่านต่อแบบเจาะลึก
วัด Conversion LINE ทุกแบรนด์ รวมศูนย์ที่เดียว
องค์กรที่มีหลายแบรนด์ หลายสาขา หลาย LINE OA linli รวม Tracking และส่ง Conversion กลับทุกแพลตฟอร์ม พร้อม Custom Limit เริ่มฟรี 14 วัน
ติดต่อทีม Salesบทความที่เกี่ยวข้อง
เว็บแบบหน้าเดียวเปลี่ยนเนื้อหาแล้วแท็กไม่ยิงซ้ำ ตั้ง Trigger ยังไง
ให้เซิร์ฟเวอร์เป็นคนเขียนคุกกี้แทน JavaScript ต่างกันตรงไหนและได้อะไรกลับมา
