ต่อ UTM เองท้ายลิงก์ กับให้สคริปต์ส่งพารามิเตอร์ข้ามโดเมนอัตโนมัติ แบบไหนรอดกว่า

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

ปัญหานี้เรียกกันว่า Cross-domain Tracking และมีสองวิธีหลักที่ธุรกิจใช้แก้กัน วิธีแรกคือให้คนตั้ง UTM เองทุกลิงก์ที่ข้ามโดเมน วิธีที่สองคือใช้สคริปต์อัตโนมัติที่คอยดึงค่าพารามิเตอร์จาก URL ปัจจุบันไปแปะต่อท้ายลิงก์ปลายทางให้เอง ทั้งสองวิธีมีจุดแข็งจุดอ่อนต่างกัน และธุรกิจขนาดต่างกันก็เหมาะกับวิธีที่ต่างกัน

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

ทำไมการข้ามโดเมนถึงเป็นจุดเสี่ยงพิเศษ

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

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

วิธีที่หนึ่ง ต่อ UTM เองด้วยมือทีละลิงก์

วิธีนี้คือการที่ทีมมีเดียหรือทีมเว็บกำหนด UTM ไว้ตายตัวในลิงก์ที่ข้ามไปยังโดเมนปลายทาง เช่นลิงก์จากหน้า Landing Page ไปหน้าเว็บหลัก จะมี UTM ติดอยู่ในโค้ด HTML ของปุ่มนั้นโดยตรง ไม่ได้ดึงค่าจาก URL ปัจจุบันมาแปะอัตโนมัติ

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

วิธีที่สอง ใช้สคริปต์ส่งพารามิเตอร์ข้ามโดเมนอัตโนมัติ

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

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

เทียบสองวิธีแบบตรง ๆ ให้เลือกง่ายขึ้น

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

หลายธุรกิจใช้สองวิธีผสมกันโดยไม่รู้ตัว

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

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

ทดสอบก่อนใช้จริงทุกครั้ง ไม่ว่าจะเลือกวิธีไหน

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

1. เปิดลิงก์ต้นทางที่มี UTM ครบ แล้วบันทึกค่าที่เห็นไว้เป็นหลักฐานอ้างอิง
2. คลิกไปยังโดเมนถัดไปทีละขั้น จนถึงหน้าสุดท้ายก่อนปุ่มเข้า LINE
3. ตรวจว่าพารามิเตอร์ที่ปรากฏในแต่ละขั้นตรงกับค่าตั้งต้นหรือไม่ ถ้าหายที่จุดไหนให้บันทึกไว้
4. ทดสอบซ้ำด้วยเบราว์เซอร์ที่มีตัวกันโฆษณาเปิดอยู่ เพราะบางสคริปต์ถูกบล็อกได้ในสถานการณ์นี้

ข้อจำกัดจากนโยบายความเป็นส่วนตัวของเบราว์เซอร์ที่กระทบ Cross-domain โดยตรง

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

ทางแก้ที่ทำได้ในทางปฏิบัติคือพึ่งพา UTM และ Click ID ที่อยู่ใน URL เป็นหลัก แทนการพึ่งพา Cookie ข้ามโดเมนเพียงอย่างเดียว เพราะพารามิเตอร์ใน URL ไม่ถูกบล็อกโดยนโยบายความเป็นส่วนตัวแบบเดียวกับ Cookie บันทึกค่าเหล่านี้ลงฐานข้อมูลของธุรกิจเองทันทีที่รับได้ในแต่ละโดเมน แล้วผูกกับ Lead ที่เกิดขึ้นภายหลัง จะเสถียรกว่าการหวังพึ่งกลไก Cookie ที่เบราว์เซอร์ควบคุมอยู่ฝ่ายเดียว

เคสจริง ผ่านหน้าระบบชำระเงินแล้วพารามิเตอร์หายเกลี้ยง

มีธุรกิจหนึ่งที่ Funnel ต้องพาลูกค้าผ่านสามโดเมน คือหน้า Landing Page ของแคมเปญ ตามด้วยระบบจองคิวของผู้ให้บริการภายนอก แล้วจึงค่อยมีปุ่มเข้า LINE ปรากฏขึ้นในขั้นตอนสุดท้าย ทีมมีเดียตั้ง UTM ไว้ถูกต้องตั้งแต่ต้น และมีสคริปต์ส่งพารามิเตอร์ระหว่างโดเมนของตัวเองครบ แต่พอถึงขั้นตอนที่ผ่านระบบจองคิวของผู้ให้บริการภายนอก พารามิเตอร์กลับหายไปทุกครั้งโดยไม่มีข้อยกเว้น

พอไล่ตรวจถึงพบว่าระบบจองคิวนั้นมีการ Redirect ผู้ใช้ผ่านหน้ายืนยันตัวตนของตัวเองก่อน ซึ่งเขียนโค้ดมาให้ล้าง Query String ทั้งหมดออกจาก URL เพื่อเหตุผลด้านความปลอดภัยของระบบเขาเอง ทีมงานไม่มีสิทธิ์แก้โค้ดของผู้ให้บริการภายนอกได้ ทางออกที่ใช้ได้จริงในเคสนี้คือเปลี่ยนมาบันทึกพารามิเตอร์ลงฐานข้อมูลของตัวเองก่อนที่ลูกค้าจะเข้าสู่ระบบจองคิว แล้วผูกด้วยรหัสอ้างอิงที่ระบบจองคิวส่งกลับมาให้แทน ไม่ใช่หวังพึ่ง URL ให้พารามิเตอร์รอดผ่านโดเมนของบุคคลที่สามที่ควบคุมไม่ได้

บทเรียนที่กว้างกว่านั้นคือก่อนวางโครงสร้าง Funnel ที่มีโดเมนของบุคคลที่สามคั่นอยู่ตรงกลาง ควรตรวจสอบล่วงหน้าว่าระบบนั้นมีพฤติกรรมล้าง Query String หรือไม่ และมีรหัสอ้างอิงอะไรที่ส่งกลับมาให้ใช้ผูกข้อมูลแทนได้บ้าง แทนที่จะไปเจอปัญหาตอนแคมเปญเปิดใช้งานจริงแล้วเท่านั้น

จะเลือกวิธีไหนดี ให้ดูจากขนาดและความถี่ของแคมเปญ

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

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

สรุป

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

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

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

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