ให้เซิร์ฟเวอร์เป็นคนเขียนคุกกี้แทน JavaScript ต่างกันตรงไหนและได้อะไรกลับมา

สมมติร้านสอนภาษาแห่งหนึ่งยิงแอด Meta ไปที่หน้าสมัครคอร์ส แล้วให้กดปุ่มไปคุยต่อใน LINE ลูกค้าคนหนึ่งเปิดหน้านั้นบน iPhone เมื่อวันจันทร์ ยังไม่ทัก แล้วกลับมาทักวันจันทร์ถัดไป รวมเป็น 8 วันหลังคลิกแรก ตอนกลับมาเขาเปิดจากบุ๊กมาร์ก URL ไม่มี fbclid แล้ว และคุกกี้ที่ pixel เขียนไว้ก็ถูก Safari เก็บกวาดไปเมื่อวาน คอร์สราคา 6,900 บาทก้อนนั้นจึงไปอยู่ในช่อง direct

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

สองคนที่เขียนคุกกี้ได้ และเบราว์เซอร์ไม่ปฏิบัติต่อทั้งสองเท่ากัน

วิธีแรกคือสคริปต์ในหน้าเว็บสั่งเขียนด้วย document.cookie ซึ่งเป็นวิธีที่ pixel ส่วนใหญ่ใช้ วิธีที่สองคือเซิร์ฟเวอร์ใส่หัว Set-Cookie ไว้ในคำตอบ HTTP ที่ส่งกลับมาพร้อมหน้าเว็บ ผลลัพธ์ในเครื่องลูกค้าหน้าตาเหมือนกัน แต่เบราว์เซอร์ถือว่าสองแบบนี้คนละชั้นตอนตัดอายุ เพราะสคริปต์เป็นช่องทางที่บริษัทโฆษณาใช้ตามรอยคนข้ามเว็บมานาน

Safari ตัดอายุคุกกี้ฝั่งสคริปต์ด้วยกติกาที่กระทบสายโฆษณาโดยตรง

ตัวเลขที่ต้องจำมีสองตัว ตัวแรกคือคุกกี้ที่เขียนด้วย document.cookie ถูกจำกัดให้อยู่ได้ 7 วันของการใช้ Safari ถ้าลูกค้าไม่กลับมาโต้ตอบกับเว็บนั้นอีก ตัวที่สองคือถ้าลูกค้าเข้ามาด้วยลิงก์ที่มีพารามิเตอร์ติดตามอย่าง fbclid จากโดเมนที่ Safari จัดว่าติดตามข้ามเว็บ คุกกี้ฝั่งสคริปต์ที่เขียนในครั้งนั้นอาจเหลือแค่ 24 ชั่วโมง ซึ่งตรงกับเส้นทางคลิกจากแอดเกือบทุกกรณี ตัวเลขนี้มาจากประกาศของ WebKit ปี 2019 และถูกปรับมาหลายรอบ ตรวจเอกสารล่าสุดก่อนใช้

คุกกี้จากเซิร์ฟเวอร์เลี่ยงสองกติกานี้ได้ แต่ Safari ตรวจด้วยว่าเซิร์ฟเวอร์ที่ตั้งคุกกี้เป็นของเว็บนั้นจริงไหม ถ้าคุณชี้ track.yourshop.com ไปหาผู้ให้บริการภายนอกด้วย CNAME หรือเซิร์ฟเวอร์อยู่ในกลุ่ม IP คนละชุดกับเว็บหลัก Safari อาจลดอายุเหลือ 7 วันอยู่ดี ให้คำตอบมาจากเซิร์ฟเวอร์หรือพร็อกซีที่อยู่หน้าโดเมนหลักของคุณเอง

ภาพใหญ่ของเรื่องนี้อยู่ใน คุกกี้และ pixel เสื่อม ทำไมต้องวัดฝั่งเซิร์ฟเวอร์

สูตรตั้งคุกกี้รหัสคลิก ให้ต่อเข้ากับปุ่ม LINE

1. ให้หน้า landing ถูกเสิร์ฟผ่านจุดที่ควบคุมคำตอบ HTTP ได้ เช่นเซิร์ฟเวอร์เว็บ พร็อกซีหน้าเว็บ หรือ edge function แล้วอ่าน fbclid, gclid และ utm จาก URL ในคำขอแรกที่ลูกค้าเข้ามา (เรื่อง เก็บ fbclid ไม่ให้หลุด)
2. ถ้ามีรหัสคลิก ให้ตอบกลับพร้อมหัว Set-Cookie: lead_ref=ค่ารหัสคลิก; Max-Age=7776000; Path=/; Domain=yourshop.com; Secure; SameSite=Lax เลข 7776000 คือ 90 วันเป็นวินาที ใกล้เคียงอายุของ _fbc ที่ pixel เคยตั้ง ปรับตามรอบซื้อของธุรกิจคุณได้ ถ้าจะส่งค่านี้เข้า Conversions API ของ Meta ให้เก็บรูปแบบ fb.1.เวลามิลลิวินาที.fbclid ตามที่ Meta กำหนดให้ _fbc
3. ออกรหัสผู้เยี่ยมชมสั้น ๆ (visitor id) เก็บในคุกกี้อีกตัว ไว้ผูกกับบทสนทนา อย่าใส่ชื่อ เบอร์โทร หรืออีเมลลงในคุกกี้
4. ชี้ปุ่ม LINE ไปที่ปลายทางของคุณเอง เช่น /go/line ให้เซิร์ฟเวอร์อ่านคุกกี้ บันทึกคู่ (visitor id, รหัสคลิก, เวลา) แล้วรีไดเรกต์ไป LINE พร้อมรหัสสั้นที่ติดไปกับข้อความแรก วิธีไม่ให้ UTM หายระหว่างรีไดเรกต์ดูใน บทความเรื่อง UTM หายหลังรีไดเรกต์
5. เมื่อลูกค้าทักมาพร้อมรหัสสั้นนั้น ฝั่งหลังบ้านใช้รหัสดึงรหัสคลิกกลับมา เพื่อส่งต่อเป็น conversion ตอนปิดการขาย

ปัญหาที่คุกกี้ฝั่งเซิร์ฟเวอร์ช่วยไม่ได้

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

สี่จุดที่ตั้งคุกกี้แล้วแต่อ่านกลับไม่เจอ

• Domain ไม่ครอบ subdomain ตั้งที่ www.yourshop.com แต่หน้า landing อยู่ที่ promo.yourshop.com คุกกี้จะไม่ถูกส่งไปด้วย ให้ตั้ง Domain เป็น yourshop.com
• HttpOnly บนคุกกี้ที่ pixel ต้องอ่าน ถ้าเขียน _fbc หรือ _fbp แบบ HttpOnly สคริปต์ของ Meta จะอ่านไม่ได้ ใช้ HttpOnly เฉพาะคุกกี้ที่มีแต่เซิร์ฟเวอร์ใช้ เช่น visitor id
• SameSite=Strict ทำให้เบราว์เซอร์ไม่แนบคุกกี้เมื่อลูกค้ากลับมาจากลิงก์ภายนอก เช่นกดจากข้อความใน LINE ใช้ Lax แทน
• CDN แคชทั้งหน้า หน้าที่ถูกแคชอาจไม่ผ่านเซิร์ฟเวอร์ของคุณ หรือ CDN ตัด Set-Cookie ทิ้ง ให้ตั้งผ่าน edge function หรือยกเว้นหน้านั้นจากการแคช

ทำเมื่อไรถึงคุ้ม วัดจากข้อมูลที่มีอยู่แล้ว

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

แต่ถ้า iPhone เป็นก้อนใหญ่ของทราฟฟิกแอด และธุรกิจคุณตัดสินใจกันเป็นวัน เช่นคอร์สเรียน คลินิก รถยนต์ งานนี้ให้ผลต่อเนื่องกว่าการไล่แก้ตัวเลข direct ย้อนหลังทุกเดือน ถ้ามี GTM server-side container อยู่แล้ว การตั้งคุกกี้จากตรงนั้นเป็นทางลัดที่ถูกกว่าเขียนระบบใหม่

สรุป

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

ถ้าตัวเลขชี้ว่าควรทำ ให้ทดสอบบน Safari จริงสองรอบ วันที่คลิกกับวันที่ 8 ถ้าคุกกี้ยังอยู่ แปลว่าเซิร์ฟเวอร์ของคุณผ่านด่านตรวจ first-party ของ Safari แล้ว

• คุกกี้เซิร์ฟเวอร์ช่วยเรื่องอายุบน Safari แต่ไม่แก้เรื่องความยินยอม เบราว์เซอร์ในแอป และการเปลี่ยนเครื่อง
• เซิร์ฟเวอร์ต้องเป็น first-party จริงทั้งโดเมนและกลุ่ม IP ไม่ใช่ CNAME ชี้ออกไปที่ผู้ให้บริการ
• ใช้ HttpOnly เฉพาะคุกกี้ที่ฝั่งเซิร์ฟเวอร์ใช้คนเดียว และใช้ SameSite=Lax กับหน้า landing
• วัดว่าคุ้มหรือไม่จากสัดส่วน Safari กับเวลาจากคลิกถึงทัก ก่อนลงมือเขียนโค้ด

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