วัดผล Landing Page และปรับ CRO

ใช้คู่มือนี้วัดผล Landing Page, หน้าสินค้า และ Checkout ของ Brand ที่เปิด Landing page measurement เพื่อหาว่าคนติดตรงไหน และเลือกสิ่งที่จะปรับต่อจากข้อมูลจริง

เริ่มจากเส้นทาง เข้าหน้า → กดซื้อ → เข้า Checkout → เริ่มกรอกชื่อ → สั่งซื้อสำเร็จ (Purchase) → ชำระแล้ว โดยแยกพฤติกรรมบนหน้าเว็บออกจากผลออเดอร์ที่ระบบบันทึกสำเร็จแล้ว

ภาพรวมเส้นทางและเหตุการณ์

เริ่มดูข้อมูลที่ไหน

เลือก Brand, หน้า, เวอร์ชันที่เผยแพร่, ช่วงวัน และ source/campaign ให้ตรงกันก่อนเทียบตัวเลข เวลาใน AdWaffle อิงประเทศไทย และรายงานรีเฟรชทุกหนึ่งนาที

อย่าคาดว่าตัวเลขทุกเครื่องมือต้องเท่ากัน: consent, ad blocker, นิยาม session และเวลาส่งข้อมูลต่างกัน รายงาน AdWaffle แยก browser behavior ออกจากผลออเดอร์ที่ server ยืนยัน

เมื่อไรจึงนับ Purchase

สำหรับออเดอร์ public ที่เริ่มใช้การวัดผลแบบใหม่นี้ ส่งฟอร์มแล้วระบบบันทึกออเดอร์สำเร็จ = Purchase ไม่ต้องรอร้านยืนยัน และไม่ต้องรอชำระเงิน

• order_created และ purchase เป็นสองชื่อ event ของการบันทึกออเดอร์เดียวกัน ไม่ใช่สองยอดซื้อ; นับ distinct order ID
• การกดปุ่มก่อนบันทึกสำเร็จ, validation error หรือ API ล้มเหลวไม่ใช่ Purchase
• order_paid เกิดเมื่อบันทึกชำระแล้ว เช่น COD อาจเกิดภายหลัง การยกเลิก/คืนเงินมี event แยก
• เริ่มใช้กับออเดอร์ใหม่หลัง deploy ไม่เปลี่ยนเวลา Purchase หรือสร้าง event ย้อนหลังให้ออเดอร์เก่า ช่วงที่มีข้อมูลสองรุ่นควรแยกวิเคราะห์ตามวันเริ่มใช้งาน

Events ที่ใช้ตัดสินใจ

ระบบเก็บ exposure ของ CTA แทนการเก็บ view ของทุกบล็อก จึงไม่มี block_view และตาราง Block Reach ในการวัดผลรูปแบบนี้ ข้อมูลเก่าไม่ได้ถูกลบ จึงอาจยังพบชื่อ event นี้ในช่วงย้อนหลังของเครื่องมือภายนอก

ขอบเขตของ “เริ่มกรอกชื่อ”

• นับเมื่อช่องมีข้อความที่ไม่ใช่ช่องว่าง การแตะช่องอย่างเดียวไม่นับ
• ครั้งเดียวต่อ checkout_attempt_id ใน session/ขอบเขต checkout เดิม การพิมพ์ต่อ ลบแล้วพิมพ์ใหม่ เปลี่ยน focus หรือ reload ไม่เพิ่ม count; การเก็บ marker ข้าม reload ต้องใช้ sessionStorage ได้
• การเริ่ม attempt ใหม่ รวมการเปลี่ยนหน้า/บล็อกข้อเสนอ/รูปแบบฟอร์ม/เวอร์ชัน หรือเริ่ม session ใหม่ นับใหม่ได้ การสลับแพ็กเกจในบล็อกเดิมไม่จำเป็นต้องเป็น attempt ใหม่ การถอน consent แล้วให้ใหม่เริ่มชุดการวัดใหม่
• Autofill ที่ไม่เกิด input event และค่าที่ระบบใส่ไว้ตั้งแต่แรกไม่นับเป็นการเริ่มกรอกที่สังเกตได้
• ไม่ส่งชื่อ ตัวอักษร ความยาวข้อความ หรือค่าฟิลด์ไปใน analytics ส่งเพียง field_key: name กับรหัส attempt/session และบริบทหน้า
• ต้องให้ Analytics consent และเปิด measurement v2; event นี้ไม่ใช่ Meta Lead, Subscribe หรือ Purchase และไม่ส่งเป็น ad conversion ใหม่
• ไม่มีข้อมูลย้อนหลังจากก่อนเปิดใช้ event นี้ อย่าเทียบศูนย์ของช่วงก่อนเริ่มเก็บว่าเป็น abandonment

Metrics และตัวหาร

ใช้ชนิดตัวหารให้ตรงกันเสมอ: Views, Sessions, Attempts และ Orders เป็นคนละหน่วย การเอาจำนวน events ที่ยิงทั้งหมดมาหารกันอาจทำให้ rate เกินจริง

วิธีทำงานใน AdWaffle

1. เลือกวันที่เริ่ม session, หน้า/เวอร์ชัน และแคมเปญที่ต้องการวิเคราะห์
2. ดู funnel หลัก page_view → buy_click → initiate_checkout → purchase เพื่อเลือกจุดที่ควรตรวจ
3. ดูการ์ด “เริ่มกรอกชื่อ (attempts)” ประกอบกับจำนวนเข้า checkout “—” หมายถึงยังไม่มี metric นี้ในรายงานที่ใช้อยู่
4. เปรียบเทียบ CTA CTR แบบ inline / sticky แล้วตรวจ scroll depth ก่อนตัดสินใจย้ายเนื้อหา
5. เปิดเปรียบเทียบฟอร์มสั้น/ยาว ดูทั้ง completion, errors และเวลาของ attempts ที่ส่งสำเร็จ แยก service contact_only และรูปแบบเก่า/ไม่ทราบรูปแบบออก
6. Drill down ใน Mixpanel เพื่อดูขั้นเริ่มกรอกชื่อ และใช้ Clarity ตรวจประสบการณ์ก่อน checkout

Funnel ใน AdWaffle นับ sessions ตามลำดับที่กำหนด ผู้เข้า checkout โดยตรงอาจไม่ผ่านขั้นกดซื้อของ funnel แต่ยังอยู่ใน checkout attempts การเพิ่ม name-start ไม่บังคับให้ historical orders ต้องมี event ใหม่นี้จึงจะนับสำเร็จ

รายงานเป็น cohort ตามวันเริ่ม session และแสดงผลออเดอร์ที่เชื่อมกันถึงเวลาปัจจุบัน ช่วงล่าสุดอาจยังรอชำระหรือยกเลิกภายหลังได้ อย่าเทียบ cohort ใหม่กับ cohort เก่าที่มีเวลาปิดยอดนานกว่าราวกับมีเวลาติดตามเท่ากัน

ตั้ง Funnel ใน Mixpanel

ตรวจว่าใช้ Project Token และ region ที่ถูกต้องก่อนสร้างรายงาน เก็บชื่อรายงานให้ระบุหน้า/ช่วงหลังเริ่มเก็บข้อมูลและหน่วยนับ

Landing funnel: page_view → buy_click → initiate_checkout → purchase ตั้ง session แบบ property-based ด้วย session_id และ hold session_id constant ระบุ conversion window ให้ชัด เช่น 1 วันสำหรับการสั่งซื้อใน session นี้ และแยกการติดตาม order_paid ที่อาจเกิดภายหลังเป็นอีกรายงาน ผลอาจต่างจาก cohort ใน AdWaffle ที่ดูผลถึงปัจจุบัน

Checkout funnel: initiate_checkout → checkout_name_start → purchase ใช้ session/attempt เดียวกัน โดย hold session_id และ checkout_attempt_id constant เลือกตัวเลือกนับ conversion ต่อ session/attempt ที่โปรเจกต์รองรับ ตรวจว่า 1 คนเปิด 2 attempts นับได้ 2 ครั้ง; ถ้า UI นับได้เพียง unique users อย่าเรียกผลนั้นว่า attempt rate ให้ใช้จำนวน distinct attempts จากข้อมูล events หรือรายงาน AdWaffle แทน

Breakdown ทีละมิติ: checkout_form_mode, entry_campaign, entry_content, device, browser หรือเวอร์ชันหน้า หลีกเลี่ยงการแบ่งหลายมิติพร้อมกันจนแต่ละกลุ่มมีข้อมูลน้อย

การเทียบฟอร์มสั้น/ยาวที่คนละหน้า/คนละ campaign เป็น observational comparison ยังสรุปไม่ได้ว่าฟอร์มเป็นสาเหตุของความต่าง หากต้องการพิสูจน์ควรออกแบบ A/B test แยก

ดู GA4, Clarity และ Meta อย่างไร

GA4: ใช้ Realtime ตรวจรับ event หรือ DebugView เมื่อเปิด debug device แล้ว สร้าง Exploration begin_checkout → checkout_name_start สำหรับ behavior ของผู้ใช้ตามวิธีนับของ GA4 อย่าเรียก user funnel ว่า attempt funnel หากไม่ได้ join attempt IDs และอย่าสร้าง checkout_attempt_id เป็น custom dimension เพื่อใช้ breakdown ปกติ เพราะมีค่าจำนวนมาก

Clarity: ใช้ดู landing/product public ที่เปิด replay ได้ ฟอร์มถูก mask และระบบหยุด replay ก่อน checkout รวมถึงไม่บันทึก receipt/slip/bind routes จึงไม่ใช้ Clarity ดูชื่อที่กรอกหรืออธิบายว่าผู้ใช้แก้ช่องไหนใน checkout ให้ใช้ events/error codes ที่ไม่เก็บค่าแทน

Meta: เปิด marketing consent เพื่อ QA การส่ง Pixel/Gateway และตรวจ event ID ของสำเนาเดียวกันให้ตรงกัน HTTP 200 เป็นหลักฐานว่า endpoint ตอบรับ แต่ยังต้องดู Events Manager เพื่อยืนยันการประมวลผล/การนับใน Meta อย่านับ request จาก Browser กับ Gateway เป็นสอง conversions โดยดูจำนวน requests อย่างเดียว

ปิด overlapping automatic events ใน Meta และใช้ mapping ที่ระบบตั้งใจส่ง SubscribedButtonClick ไม่ใช่หลักฐานสมัครสมาชิกหรือยอดซื้อ ตรวจให้แน่ใจว่าตัวโหลด Pixel ใช้เฉพาะ event ที่กำหนดไว้ และทดสอบ event ที่รับจริงหลังเปลี่ยนการตั้งค่า

ขั้นตอนปรับ CRO รายสัปดาห์

จดสมมติฐาน, สิ่งที่เปลี่ยน, หน้า/เวอร์ชัน, วันเริ่ม และ metric หลักก่อนเปลี่ยน ใช้ completion/purchase value เป็นผลลัพธ์ และใช้ name-start/CTR/errors เป็นข้อมูลช่วยวินิจฉัย ไม่ optimize ให้คนเริ่มกรอกชื่อมากขึ้นอย่างเดียว

เช็กลิสต์ก่อนใช้ตัดสินใจงบ

• เปิด measurement v2 และ provider IDs/region ของ Brand ถูกต้อง มี banner และ consent ทำงาน
• ทดลองเปิดหน้าใหม่: ไม่มี block_view, CTA view ยังส่ง, focus ชื่ออย่างเดียวไม่ส่ง name-start, input ครั้งแรกส่งหนึ่งครั้ง และแก้/โหลดใหม่ไม่ยิงซ้ำใน attempt เดิม
• ทดสอบไม่มี consent / ถอน consent: analytics ต้องหยุด; ไม่กรอกข้อมูลลูกค้าจริงเพื่อ QA
• ตรวจ GA4/Mixpanel ว่ารับ name-start จริง และไม่สร้าง Meta Subscribe/Lead/Purchase จากการเริ่มกรอกชื่อ
• ทดสอบสร้างออเดอร์ใน staging แยกจาก production และยืนยัน server outcomes/มูลค่า/การป้องกันซ้ำก่อนนับเป็นยอดขาย
• เลือกช่วงหลังเริ่มเก็บ event ใหม่ ใช้ UTM และตัวกรองตรงกัน ระบุหน่วยและ conversion window ทุกครั้ง

การเก็บ raw events ตามสิทธิ์ปัจจุบัน: Free/Starter 30 วัน, Pro/Agency 90 วัน รายงาน query ได้สูงสุด 90 วัน หากข้อมูลเก่าหมด retention จะไม่สร้าง uniques ย้อนหลังทดแทน