GA4 Ecommerce Tracking แบบ Step-by-Step

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

GA4 Ecommerce Tracking คืออะไร และทำไม Event ต้องเรียงลำดับให้ถูก

GA4 มี schema เฉพาะสำหรับ ecommerce ที่กำหนดชื่อ event และโครงสร้างข้อมูลไว้ตายตัว เพื่อให้ระบบสร้างรายงาน funnel และ retention ได้อัตโนมัติโดยไม่ต้องตั้งค่ารายงานเองทุกจุด หัวใจของเรื่องนี้คือ event แต่ละตัวต้องเกิดตามลำดับที่ลูกค้าทำจริง ตั้งแต่เห็นสินค้า ใส่ตะกร้า เริ่มเช็คเอาต์ ไปจนจ่ายเงินสำเร็จ ถ้าลำดับสลับหรือขาดตอนไหนไป รายงาน funnel ที่ GA4 สร้างให้อัตโนมัติจะเพี้ยนทันที เพราะระบบตีความจากลำดับ event ไม่ใช่จากการเดา

จุดที่ต้องเข้าใจก่อนคือ event เหล่านี้ไม่ใช่แค่ label ที่ตั้งชื่ออะไรก็ได้ แต่มีชื่อและ parameter ที่ GA4 กำหนดไว้ตายตัว ถ้าตั้งชื่อเอง เช่น "add_cart" แทน "add_to_cart" ระบบจะไม่จัดเข้ารายงาน ecommerce มาตรฐานให้ และคุณจะเสียฟีเจอร์อย่างรายงาน Purchase Journey หรือ Ecommerce Purchases ที่ GA4 สร้างให้ฟรีไปโดยเปล่าประโยชน์

4 Event หลักของ GA4 Ecommerce: จาก View Item ถึง Purchase

ก่อนลงมือตั้งค่า ให้ทำความเข้าใจว่าแต่ละ event ควรยิงตอนไหน และมีความหมายอะไรกับธุรกิจ

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

สังเกตว่าช่องว่างระหว่าง add_to_cart กับ begin_checkout และระหว่าง begin_checkout กับ purchase คือจุดที่บอกว่าร้านของคุณเสียลูกค้าตรงขั้นตอนไหนมากที่สุด ถ้าไม่มี 4 event นี้ครบ คุณจะเห็นแค่ยอดขายรวม แต่ไม่รู้เลยว่าควรไปแก้ตรงไหนก่อน

Event เสริมที่ควรรู้จักไว้นอกเหนือจาก 4 ตัวหลัก

นอกจาก view_item, add_to_cart, begin_checkout และ purchase ที่เป็นแกนหลัก GA4 ยังมี event เสริมที่ช่วยให้เห็นภาพลูกค้าได้ละเอียดขึ้น เช่น view_item_list ที่ยิงตอนลูกค้าเลื่อนดูหน้ารายการสินค้าโดยยังไม่คลิกเข้ารายละเอียด select_item ตอนคลิกเลือกสินค้าจากรายการ add_shipping_info และ add_payment_info ที่ยิงระหว่างขั้นตอนเช็คเอาต์ก่อนถึง purchase และ refund สำหรับกรณีลูกค้าคืนสินค้าหรือขอเงินคืน ธุรกิจที่เพิ่งเริ่มไม่จำเป็นต้องยิงครบทุกตัวตั้งแต่วันแรก แต่ควรรู้ไว้ว่ามีอยู่ เพราะเมื่อธุรกิจโตขึ้นและอยากรู้รายละเอียดของ funnel มากขึ้น เช่น อัตราการคืนเงินต่อหมวดสินค้า event เหล่านี้คือสิ่งที่ต้องกลับมาเพิ่ม

ข้อควรระวังคือ event เสริมเหล่านี้ต้องใช้ item-scoped parameters ชุดเดียวกับ 4 event หลัก ไม่ใช่คิดโครงสร้างข้อมูลใหม่ทุกครั้งที่เพิ่ม event เพราะ GA4 จะเชื่อมโยง event ต่าง ๆ เข้าด้วยกันผ่าน item_id ที่ต้องตรงกันในทุก event ที่เกี่ยวกับสินค้าชิ้นเดียวกัน

Item-Scoped Parameters ที่ต้องมีในทุก Event

นอกจากชื่อ event ให้ถูก แต่ละ event ยังต้องแนบข้อมูลระดับสินค้า (item-scoped parameters) ไปด้วยเสมอ ไม่งั้น GA4 จะรู้แค่ว่ามีคนซื้อ แต่ไม่รู้ว่าซื้อสินค้าอะไร พารามิเตอร์หลักที่ต้องมีในทุก event ได้แก่

• item_id — รหัสสินค้าที่ไม่ซ้ำกัน ใช้จับคู่กับฐานข้อมูลสต็อกของร้าน
• item_name — ชื่อสินค้าที่อ่านแล้วเข้าใจได้ทันทีในรายงาน
• price — ราคาต่อหน่วยของสินค้าตอนนั้น ไม่ใช่ราคารวมทั้งตะกร้า
• quantity — จำนวนชิ้นที่ใส่ตะกร้าหรือซื้อในรายการนั้น

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

GTM DataLayer เชื่อมกับ GA4 Event ยังไง

ถ้าคุณใช้ Google Tag Manager คุมการยิง event ทั้งหมด สิ่งที่เว็บต้องทำคือ push ข้อมูลเข้า dataLayer ก่อน แล้ว GTM tag ของ GA4 จะไปดึงค่าจาก dataLayer นั้นมาส่งต่อ ตัวอย่างโครงสร้างข้อมูลตอนลูกค้าจ่ายเงินสำเร็จหน้าตาประมาณนี้ (เป็นตัวอย่างโครงสร้างเพื่อความเข้าใจ ไม่ใช่โค้ดที่รันจริงในหน้านี้):

dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-20260721-0091",
    value: 1290,
    currency: "THB",
    items: [
      { item_id: "SKU-001", item_name: "เสื้อยืดคอกลม", price: 390, quantity: 2 },
      { item_id: "SKU-014", item_name: "หมวกแก๊ป", price: 510, quantity: 1 }
    ]
  }
});

สังเกตว่า transaction_id เป็นฟิลด์สำคัญที่มักถูกมองข้าม เพราะมันคือกุญแจที่ทำให้ GA4 รู้ว่าการยิง event สองครั้งคือ order เดียวกันหรือคนละ order กัน ถ้าไม่มีค่านี้ หรือค่านี้ไม่คงที่ตลอดเวลาที่หน้า thank-you ยังเปิดอยู่ ปัญหาที่จะตามมาคือสิ่งที่อธิบายในหัวข้อถัดไป

ข้อผิดพลาดที่สร้างความเสียหายที่สุด: Purchase Event ยิงซ้ำตอนรีเฟรชหน้า Thank You

ปัญหาที่พบบ่อยที่สุดและสร้างความเสียหายต่อความน่าเชื่อถือของข้อมูลมากที่สุดคือ purchase event ถูกตั้งให้ยิงทุกครั้งที่มีคนเปิดหน้า "ขอบคุณที่สั่งซื้อ" แทนที่จะยิงแค่ครั้งเดียวต่อหนึ่งรายการสั่งซื้อจริง ลองนึกภาพว่าลูกค้าสั่งซื้อสำเร็จ แล้วกดรีเฟรชหน้าเพราะเน็ตช้า หรือกด back แล้วกด forward กลับมา หรือแชร์ลิงก์หน้า thank-you ให้เพื่อนดู ทุกครั้งที่หน้านั้นถูกเปิดซ้ำ ถ้า trigger ผูกกับการเปิดหน้าแบบง่าย ๆ ระบบจะยิง purchase event ซ้ำทุกครั้ง ทำให้ยอดขายใน GA4 พองตัวขึ้นเรื่อย ๆ โดยไม่มีใครสังเกตจนกว่าจะมีคนเทียบตัวเลขกับความจริง

ทางแก้ในเชิงหลักการคือเปลี่ยนเงื่อนไขของ trigger จาก "ทุกครั้งที่หน้านี้ถูกเปิด" เป็น "ยิงครั้งเดียวต่อหนึ่ง transaction_id" นั่นหมายถึงต้องมีกลไกจดจำว่า transaction_id ตัวนี้เคยถูกยิงไปแล้วหรือยัง เช่น เก็บค่าไว้ชั่วคราวในฝั่งเบราว์เซอร์แล้วเช็กก่อนยิงทุกครั้ง หรือให้ฝั่งเซิร์ฟเวอร์เป็นคนสร้างหน้า thank-you เฉพาะตอน order เพิ่งสำเร็จจริงเท่านั้น ไม่ใช่ทุกครั้งที่ URL นั้นถูกเรียก หลักการสำคัญคือ purchase ต้องผูกกับ "เหตุการณ์การชำระเงินสำเร็จ" ไม่ใช่ผูกกับ "การแสดงผลของหน้าเว็บ" เพราะสองอย่างนี้ไม่ใช่สิ่งเดียวกัน

วิธีตรวจจับ: เทียบยอด Revenue ใน GA4 กับยอดเงินเข้าบัญชีจริง

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

1. เปิดรายงาน Revenue ใน GA4 ของสัปดาห์ที่ผ่านมา แล้วจดยอดรวมไว้
2. เปิดยอดขายจริงจากระบบหลังบ้านร้านค้า หรือยอดเงินเข้าบัญชี/ยอดสั่งซื้อที่ยืนยันแล้วในช่วงเวลาเดียวกัน
3. เทียบสองตัวเลขนี้ ถ้า GA4 รายงานสูงกว่ายอดจริงเกิน 10-15% อย่างสม่ำเสมอทุกสัปดาห์ ให้สงสัยไว้ก่อนว่า purchase event น่าจะยิงซ้ำ ไม่ใช่ร้านขายดีขึ้นจริง
4. ถ้าสงสัย ให้เปิดรายงาน transaction_id ราย order แล้วดูว่ามี transaction_id ซ้ำกันที่ถูกนับเป็นหลาย purchase event หรือไม่ ถ้าเจอซ้ำคือหลักฐานยืนยันชัดเจน

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

อีกเครื่องมือที่ช่วยเช็กได้ละเอียดกว่ารายงานปกติคือ GA4 DebugView ซึ่งแสดง event แบบเรียลไทม์พร้อม parameter ทุกตัวที่แนบมาด้วย เปิดหน้านี้ไว้แล้วลองสั่งซื้อสินค้าจริงด้วยตัวเองหนึ่งรายการ จากนั้นลองกดรีเฟรชหน้า thank-you อีกสองสามครั้งทันที ถ้าเห็น purchase event ยิงซ้ำขึ้นมาในหน้า DebugView ตามจำนวนครั้งที่รีเฟรช นั่นคือหลักฐานตรงที่สุดว่า trigger ยังผูกกับการแสดงผลหน้าเว็บอยู่ ไม่ใช่ผูกกับ transaction_id ให้แก้ก่อนเปิดงบโฆษณาเพิ่ม เพราะยิ่งใช้งบเยอะขึ้นเท่าไหร่ ความเสียหายจากข้อมูลที่พองตัวก็ยิ่งมากขึ้นตามไปด้วย

สรุป: เช็คลิสต์ก่อนเปิดแคมเปญด้วย Ecommerce Data ที่เชื่อถือได้

ก่อนใช้ตัวเลข GA4 Ecommerce ไปตัดสินใจเรื่องงบโฆษณาหรือสต็อกสินค้า ให้เช็กตามลิสต์นี้ก่อน

• ยิงครบ 4 event หลัก: view_item, add_to_cart, begin_checkout, purchase
• ทุก event แนบ item_id, item_name, price, quantity ให้ครบ
• purchase event ผูกกับ transaction_id และยิงครั้งเดียวต่อ order เท่านั้น
• เทียบยอด Revenue ใน GA4 กับยอดเงินจริงทุกสัปดาห์
• เมื่อแก้เว็บหรือเปลี่ยนระบบตะกร้า ให้ทดสอบ event ซ้ำทุกครั้งก่อนปล่อยจริง

ถ้ายังไม่มั่นใจว่าค่าที่ใช้อยู่ตอนนี้ให้ผลตอบแทนคุ้มค่าแค่ไหน ลองใช้ CPA/ROAS Calculator คำนวณจากยอดขายที่ตรวจสอบแล้วว่าถูกต้องจริง และถ้ากำลังวางแผนงบโฆษณาต่อ อ่านเพิ่มที่ Google Ads Budget Calculator ประกอบกับบทความ คู่มือตั้งค่า GA4 ฉบับสมบูรณ์ และ Google Ads Conversion Tracking ติดตั้งยังไงให้แม่นยำ เพื่อให้ทั้งสองระบบวัดผลตรงกันตั้งแต่ต้นทาง