ลูกค้าคลิกโฆษณาแล้วไปทัก LINE เรารู้ได้ยังไงว่ามาจาก UTM ไหน

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

ปัญหาไม่ได้อยู่ที่ตัวโฆษณาหรือตัว LINE OA เอง แต่อยู่ที่ช่วงกลางทาง คนกดโฆษณาบนแพลตฟอร์มหนึ่ง ระบบโฆษณารู้จักเขาผ่าน Click ID กับ UTM แต่พอเขากดปุ่มไป LINE แล้วเพิ่มเพื่อน ระบบ LINE รู้จักเขาผ่าน user id ซึ่งเป็นคนละรหัสกันโดยสิ้นเชิง ถ้าไม่มีอะไรมาเชื่อมสองฝั่งนี้ไว้ คุณจะได้แค่ตัวเลขคลิกฝั่งหนึ่ง กับตัวเลขคนเพิ่มเพื่อนอีกฝั่งหนึ่ง ที่ไม่มีวันรู้ว่าใครมาจากใคร

บทความนี้จะพาไปดูสองแนวทางหลักที่ใช้แก้ปัญหานี้ คือผูกข้อมูลฝั่ง Client-side กับผูกฝั่ง Server-side พร้อมข้อดีข้อเสียที่ทำให้ธุรกิจแต่ละขนาดควรเลือกไม่เหมือนกัน ไม่มีทางไหนที่ 'ถูกกว่า' อีกทางเสมอไป ขึ้นอยู่กับว่าทีมของคุณมีทรัพยากรฝั่งไหนพร้อมกว่ากัน

ทำไมคลิกโฆษณากับการเพิ่มเพื่อน LINE ถึงเป็นคนละโลกกัน

แพลตฟอร์มโฆษณาอย่าง Google, Meta หรือ TikTok มองเห็นแค่ช่วงตั้งแต่คนเห็นโฆษณาจนถึงคนคลิกลิงก์ ข้อมูลที่มันเก็บได้คือ Click ID กับพารามิเตอร์ที่คุณแปะไว้ในลิงก์ หลังจากนั้นเมื่อคนกดเข้า LINE แล้วเพิ่มเพื่อน ระบบของ LINE จะสร้าง user id ให้กับบัญชีนั้นซึ่งเป็นรหัสที่ไม่มีความสัมพันธ์อะไรเลยกับ Click ID ตัวเดิม สองระบบนี้ไม่เคยคุยกันโดยธรรมชาติ

จุดที่ทำให้เรื่องซับซ้อนขึ้นอีกคือ พฤติกรรมจริงของคนไม่ได้ตรงไปตรงมาเหมือนไดอะแกรมในสไลด์ บางคนกดโฆษณาแล้วเข้า LINE ทันที บางคนเห็นโฆษณาในมือถือแต่ไปเพิ่มเพื่อนจากคอมพิวเตอร์อีกเครื่องตอนเย็น บางคนแคปหน้าจอโฆษณาส่งให้เพื่อนแล้วเพื่อนเป็นคนกดแทน ทุกกรณีนี้ทำให้ Click ID กับ LINE user id ไม่ได้เกิดขึ้นในเซสชันเดียวกันเสมอไป

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

Client-side กับ Server-side: ต่างกันตรงไหนกันแน่

พูดให้ง่ายที่สุด Client-side คือการฝากข้อมูล UTM ไว้กับตัวลิงก์และหน้าเว็บที่ผู้ใช้เดินผ่าน ให้ตัวเบราว์เซอร์หรือแอปเป็นคนพาข้อมูลนั้นเดินทางไปจนถึงจุดที่กดเข้า LINE ส่วน Server-side คือการให้เซิร์ฟเวอร์ของคุณเป็นคนบันทึกความเชื่อมโยงไว้ก่อน แล้วค่อยส่งต่อให้ระบบ LINE OA หรือระบบหลังบ้านดึงไปใช้ทีหลัง โดยที่ผู้ใช้ไม่ต้องพาข้อมูลนั้นติดตัวไปเอง

ความต่างนี้ไม่ใช่แค่เรื่องเทคนิค แต่ส่งผลต่อความน่าเชื่อถือของข้อมูลด้วย ฝั่ง Client-side พึ่งพาสิ่งที่อยู่นอกการควบคุมของคุณ เช่น การตั้งค่าเบราว์เซอร์ การบล็อก Cookie หรือพฤติกรรมคัดลอกลิงก์ของผู้ใช้ ส่วนฝั่ง Server-side พึ่งพาการออกแบบระบบของคุณเองเป็นหลัก ซึ่งควบคุมได้มากกว่าแต่ก็ต้องลงแรงติดตั้งมากกว่าเช่นกัน

ผูก UTM กับ LINE user id แบบ Client-side ทำยังไง

แนวทางนี้อาศัยหลักการง่าย ๆ คือให้พารามิเตอร์ที่ติดมากับลิงก์โฆษณา 'เดินทาง' ไปพร้อมกับผู้ใช้จนถึงจุดที่เขากดเข้า LINE โดยไม่หลุดหายไประหว่างทาง

1. ตั้ง Tracking Link เฉพาะของแต่ละแคมเปญที่มี utm_source, utm_medium, utm_campaign ครบ แทนที่จะใช้ลิงก์ LINE ตรงตัวเดียวกันทุกแคมเปญ
2. ให้หน้าเว็บที่คั่นกลาง (ถ้ามี) อ่านค่า UTM จาก URL แล้วแนบต่อเข้าไปในลิงก์ปุ่ม 'แชทกับเรา' ก่อนส่งต่อไป LINE ไม่ใช่แค่แสดงปุ่มลิงก์ LINE ตายตัว
3. ถ้าใช้ LINE Login หรือ LIFF ในหน้าเว็บ ให้บันทึกค่า UTM ไว้ในพารามิเตอร์ของ LIFF URL เพื่อให้ค่าที่อ่านได้ตอนเปิดแอปยังพกข้อมูลเดิมมาด้วย
4. ตั้งค่า Timeout ของการเก็บ UTM ไว้ชั่วคราว (เช่นในตัวแปรของหน้าเว็บ) ให้เหมาะกับพฤติกรรมจริง ไม่สั้นเกินจนคนที่เลื่อนดูหน้าเว็บก่อนกดปุ่มเสียข้อมูลไป

ผูกแบบ Server-side เมื่อไหร่ถึงควรเลือกทางนี้

ธุรกิจที่ยิงหลายแคมเปญพร้อมกัน มีหลายทีมดูแลคนละแคมเปญ หรือเป็นเอเจนซี่ที่ดูแลลูกค้าหลายเจ้า มักเจอปัญหาว่าฝั่ง Client-side หลุดบ่อยเกินกว่าจะเชื่อรายงานได้ กรณีแบบนี้การย้ายมาใช้ Server-side ช่วยลดความเสี่ยงได้มาก เพราะข้อมูลไม่ต้องพึ่งพฤติกรรมของผู้ใช้ระหว่างทาง

1. สร้างตัวระบุชั่วคราว (เช่น token สั้น ๆ) ผูกกับ UTM ตอนที่ผู้ใช้กด Tracking Link แล้วบันทึกคู่ความสัมพันธ์นี้ไว้ในฐานข้อมูลฝั่งเซิร์ฟเวอร์ทันที
2. ส่ง token นั้นไปพร้อมกับลิงก์ที่พาไปเพิ่มเพื่อน LINE แทนที่จะพก UTM เต็มรูปแบบไปด้วย เพื่อลดโอกาสที่พารามิเตอร์ยาวจะหลุดระหว่างทาง
3. เมื่อ Add Friend หรือ Webhook Event ของ LINE ยิงกลับมาพร้อม user id ให้ระบบดึง token ที่แนบมาไปเทียบกับตารางที่บันทึกไว้ในขั้นแรก เพื่อดึงค่า UTM เดิมกลับมาผูกกับ user id นั้น
4. เก็บ Log การจับคู่ทุกครั้งไว้ตรวจสอบย้อนหลังได้ เผื่อวันไหนตัวเลข Add Friend กับตัวเลขที่ map ได้ไม่ตรงกัน จะได้สืบต้นตอได้ว่าหลุดที่ขั้นไหน

จุดที่ mapping มักหลุดระหว่างทาง ไม่ว่าจะเลือกแบบไหน

• คนคัดลอกลิงก์จากโฆษณาไปวางในแอปแชทอื่นก่อนกดจริง บางแอปตัดพารามิเตอร์ท้าย URL ทิ้งโดยอัตโนมัติ
• คนพิมพ์ค้นหาชื่อ LINE OA เองแทนที่จะกดลิงก์ตรง ทำให้ไม่มีข้อมูลต้นทางติดมาเลยตั้งแต่แรก
• หน้าเว็บที่คั่นกลางโหลดช้าหรือมี Redirect หลายชั้น จนพารามิเตอร์บางตัวหายไประหว่างการส่งต่อ
• ทีมการตลาดเปลี่ยนชื่อ utm_campaign กลางแคมเปญโดยไม่แจ้งทีมที่ดูแลระบบหลังบ้าน ทำให้ตารางจับคู่ฝั่ง Server-side อ้างอิงชื่อเก่าที่ไม่มีอยู่แล้ว
• Token ฝั่ง Server-side หมดอายุก่อนที่ผู้ใช้จะกดเพิ่มเพื่อนจริง เช่นเปิดลิงก์ค้างไว้หลายชั่วโมงก่อนกลับมากดต่อ

ตัวอย่างสมมติ: ผูกได้กี่เปอร์เซ็นต์ถึงจะเริ่มเชื่อรายงานได้

ลองดูตัวอย่างสมมติเพื่อให้เห็นภาพว่าตัวเลขระดับไหนนับว่าใช้งานได้จริง สมมติเดือนนี้มีคนกดลิงก์จากแคมเปญทั้งหมด 1,000 ครั้ง แล้วมีคนเพิ่มเพื่อน LINE จริง 620 คน จากนั้นในจำนวน 620 คนนี้ ระบบ map UTM กลับไปหาแคมเปญต้นทางได้สำเร็จ 540 คน อีก 80 คนกลายเป็น 'ไม่ทราบที่มา'

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

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

สิ่งที่ต้องระวังเรื่อง Privacy เมื่อผูก user id กับข้อมูลต้นทาง

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

อีกเรื่องที่มักถูกมองข้ามคือ Retention หรือระยะเวลาที่เก็บข้อมูล token/mapping นี้ไว้ ควรกำหนดให้ชัดว่าจะเก็บนานแค่ไหนแล้วลบทิ้ง แทนที่จะปล่อยให้สะสมไปเรื่อย ๆ โดยไม่มีการทบทวน เพราะข้อมูลที่เก็บไว้นานเกินความจำเป็นคือความเสี่ยงที่ไม่มีใครได้ประโยชน์เพิ่มขึ้นเลย

QA อะไรบ้างก่อนจะเริ่มเชื่อตัวเลขที่ map ได้

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

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

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

สรุป

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

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

• Client-side ติดตั้งง่ายกว่าแต่เสี่ยงข้อมูลหลุดเมื่อคัดลอกลิงก์หรือเปลี่ยนอุปกรณ์
• Server-side ควบคุมได้มากกว่าแต่ต้องมีทีมเทคนิคดูแลตารางจับคู่
• ทดสอบ Journey จริงและตั้งชื่อแคมเปญให้สม่ำเสมอ ก่อนเชื่อตัวเลขที่ map ได้

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