ลูกค้ากดโทรก่อนแล้วค่อยเพิ่มเพื่อน LINE จะตามยังไงว่ามาจากแอดไหน

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

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

บทความนี้จะอธิบายว่า GTM ช่วยตาม Journey แบบข้ามช่องทางนี้ได้แค่ไหน อะไรที่ทำได้จริงในทางเทคนิค และอะไรที่ต้องยอมรับว่าเป็นข้อจำกัดที่ต้องแก้ด้วยกระบวนการอื่นแทน

สิ่งที่ GTM เห็นได้จริงเมื่อลูกค้ากดปุ่มโทร

เมื่อลูกค้ากดปุ่มโทรที่เป็นลิงก์ tel: บนเว็บ GTM สามารถดัก Event การคลิกนั้นได้เหมือนปุ่มอื่นทั่วไป รู้ว่าคลิกจากหน้าไหน มาจากแคมเปญอะไรผ่าน UTM ที่เก็บไว้ และเวลาไหน สิ่งนี้ทำได้เหมือนกับการ track ปุ่ม LINE ทุกประการ

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

ช่องว่างตรงกลางที่ทำให้ตามยากที่สุด

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

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

ตัวเลือกที่ช่วยให้เห็นภาพชัดขึ้น: เบอร์โทรแบบ Dynamic

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

วิธีนี้ช่วยตอบคำถามว่า 'แคมเปญไหนสร้างสายโทรเข้า' ได้ดีขึ้นมาก แต่ยังไม่ได้แก้ปัญหาการเชื่อมกับ Event ฝั่ง LINE ที่เกิดขึ้นทีหลังอยู่ดี ต้องอาศัยอีกชั้นหนึ่งคือการบันทึกฝั่งแอดมินเพื่อเติมเต็มช่องว่างสุดท้าย

ตั้ง Trigger ดักปุ่มโทรใน GTM ให้ไม่ชนกับ Tag ปุ่ม LINE

ในทางเทคนิค การตั้ง Trigger ดักปุ่มโทรใน GTM ทำคล้ายปุ่ม LINE คือดักการคลิกที่ลิงก์ขึ้นต้นด้วย tel: แต่จุดที่ต้องระวังคือถ้าเว็บมีทั้งปุ่มโทรและปุ่ม LINE อยู่ใกล้กัน เช่น วางเป็นแถบเดียวกันด้านล่างจอ Trigger ที่ตั้งแบบกว้างเกินไปอาจดักผิดปุ่ม ทำให้ Event line_click กับ Event call_click ปนกัน วิธีป้องกันคือตั้งเงื่อนไข Trigger ให้เจาะจงที่ Attribute href ขึ้นต้นด้วย tel: เท่านั้น แยกจาก Trigger ของปุ่ม LINE ที่เจาะจง href ขึ้นต้นด้วย line.me หรือ lin.ee

เมื่อ Event call_click เกิดขึ้น ควรส่งพารามิเตอร์ campaign_source, page_location และ button_position ติดไปด้วยเหมือนที่ทำกับ Event ของปุ่ม LINE เพื่อให้เปรียบเทียบพฤติกรรมสองช่องทางนี้บนมาตรฐานเดียวกันได้ ไม่ใช่เก็บข้อมูลปุ่มโทรแบบง่าย ๆ ในขณะที่ปุ่ม LINE เก็บละเอียดกว่า เพราะจะทำให้เทียบผลระหว่างสองช่องทางไม่ได้ในภายหลัง

ตอนทดสอบผ่าน GTM Preview ให้ลองคลิกปุ่มโทรและปุ่ม LINE สลับกันไปมาบนหน้าเดียวกัน แล้วดูว่า Event ที่ขึ้นในไทม์ไลน์ตรงกับปุ่มที่กดจริงหรือไม่ ถ้าคลิกปุ่มโทรแล้วดันมี Event line_click ขึ้นมาแทน แปลว่า Trigger สองตัวนี้ตั้งเงื่อนไขทับซ้อนกันอยู่ ต้องกลับไปเจาะจง Attribute ให้แคบลงอีก

อีกเรื่องที่มักถูกลืมคือถ้าเว็บมี Consent Banner บังคับให้ผู้ใช้เลือกก่อน Tag ที่ส่ง Event call_click ไปยังปลายทางโฆษณาก็จะถูกรอเหมือน Tag ของปุ่ม LINE เช่นกัน ดังนั้นเวลาทดสอบใน Preview แล้วเจอว่า Tag ปุ่มโทรไม่ยิง ให้เช็คสถานะ Consent ก่อนเสมอ ก่อนจะไปแก้ Trigger ที่จริง ๆ อาจไม่ได้มีปัญหาอะไรเลย

หลังตั้ง Trigger และทดสอบผ่าน Preview จนมั่นใจแล้วว่า Event call_click กับ line_click แยกกันถูกต้อง ควรบันทึกไว้เป็นเอกสารสั้น ๆ ว่าปุ่มแต่ละแบบใช้เงื่อนไข Trigger อะไร เพราะเมื่อทีมพัฒนาเว็บเปลี่ยนโครงหน้าในอนาคต เช่น ย้ายปุ่มโทรไปรวมกับปุ่ม LINE ในองค์ประกอบเดียว จะได้รู้ทันทีว่าต้องกลับมาตรวจ Trigger ตัวไหนก่อน ไม่ต้องเริ่มไล่หาสาเหตุใหม่ตั้งแต่ศูนย์เหมือนครั้งแรกที่ตั้งค่า

ชั้นสุดท้ายที่ต้องพึ่งคน ไม่ใช่ระบบอัตโนมัติ

1. เมื่อรับสายโทรเข้า ให้พนักงานบันทึกไว้ว่าเป็นสายจากลูกค้าใหม่หรือลูกค้าเก่า และคุยเรื่องอะไรโดยย่อ
2. เมื่อลูกค้าคนเดิมกลับมาทัก LINE ในภายหลัง ให้แอดมินถามหรือสังเกตบริบทว่าตรงกับสายที่เคยโทรเข้าหรือไม่ เช่น ถามชื่อหรือปัญหาที่เคยคุยไว้
3. บันทึกการเชื่อมโยงนี้ไว้ในระบบที่ทีมขายใช้ เพื่อให้ภายหลังดึงมาวิเคราะห์ได้ว่า Journey แบบข้ามช่องทางนี้เกิดขึ้นบ่อยแค่ไหน
4. ถ้ามีระบบ Call Tracking ที่รู้แคมเปญต้นทางของสายโทรเข้าอยู่แล้ว ให้ผูกข้อมูลนั้นเข้ากับบันทึกของแอดมินด้วย เพื่อให้ภาพรวมสมบูรณ์ที่สุดเท่าที่ทำได้

ภาพที่เป็นจริงได้ กับภาพที่เป็นไปไม่ได้

อย่าเชื่อใครที่บอกว่าตามได้แม่นยำร้อยเปอร์เซ็นต์

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

สิ่งที่ทำได้อย่างสมเหตุสมผลคือลดช่องว่างให้แคบที่สุดเท่าที่จะทำได้ ผ่านการผสมข้อมูลจากหลายแหล่ง ทั้ง Call Tracking, การบันทึกของแอดมิน และ Event บนเว็บ แล้วยอมรับว่าจะมีบางเคสที่เชื่อมโยงไม่ได้อยู่ดี ซึ่งเป็นเรื่องปกติของการวัดผลข้ามช่องทาง

โฟกัสที่คำถามที่ตอบได้จริงก่อน

แทนที่จะพยายามไล่หาความสมบูรณ์แบบในการเชื่อมทุก Journey ให้โฟกัสที่คำถามที่ระบบตอบได้จริงก่อน เช่น แคมเปญไหนสร้างการกดปุ่มโทรมากที่สุด และแคมเปญไหนสร้างการกดปุ่ม LINE มากที่สุด แล้วดูภาพรวมทั้งสองฝั่งประกอบกัน แม้จะไม่รู้ว่าเป็นคนเดียวกันเป๊ะ ๆ ก็ยังให้ทิศทางการตัดสินใจได้

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

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

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

สรุป

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

ธุรกิจที่เข้าใจข้อจำกัดนี้ตั้งแต่ต้น จะวางแผนได้สมเหตุสมผลกว่า คือใช้ Call Tracking และการบันทึกของแอดมินเสริมจุดที่ GTM มองไม่เห็น แทนที่จะรอความสมบูรณ์แบบที่ไม่มีทางเกิดขึ้นจริง

• GTM track ปุ่มโทรได้เหมือนปุ่มอื่น แต่ไม่รู้ผลลัพธ์หลังสายเชื่อมต่อ
• การเชื่อมคนที่โทรกับคนที่เพิ่มเพื่อน LINE ทีหลัง ต้องพึ่งคนบันทึก ไม่ใช่ระบบอัตโนมัติ
• Call Tracking แบบเบอร์ Dynamic ช่วยรู้ที่มาของสายได้ แต่ไม่ได้แก้ช่องว่างทั้งหมด
• โฟกัสคำถามที่ตอบได้จริงก่อน ไม่ไล่หาความสมบูรณ์แบบที่เป็นไปไม่ได้

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