เชื่อมช่องว่างระหว่าง UI ของ Google Analytics กับ BigQuery Export

Minhaz Kazi ผู้ประสานงานนักพัฒนาแอป Google Analytics – เมษายน 2023

"แต่ทำไมตัวเลขถึงไม่ตรงกับ UI"

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

"แล้วมันมีไว้ที่ไหน"

ด้วยโพสต์นี้ เราจะพยายามเปิดเผยทั้ง 2 อย่าง

ก่อนที่จะลงรายละเอียดว่าตัวเลขแตกต่างกันอย่างไร คุณต้องทำความเข้าใจจุดประสงค์ของข้อมูลการส่งออกเหตุการณ์ BigQuery ก่อน ผู้ใช้ Google Analytics ส่งข้อมูลที่รวบรวมไว้ให้ GA ผ่านวิธีการรวบรวมข้อมูลแบบใดแบบหนึ่ง ได้แก่ Google Tag, Google Tag Manager, Measurement Protocol, SDK และการนำเข้าข้อมูล เมื่อพิจารณาจากการตั้งค่าพร็อพเพอร์ตี้ GA แล้ว Google Analytics จะเพิ่มมูลค่าจํานวนมากให้ข้อมูลที่รวบรวมได้ก่อนที่จะเข้าถึงแพลตฟอร์มการรายงานมาตรฐาน ซึ่งรวมถึงรายงานมาตรฐาน การสํารวจ และ Data API การเพิ่มมูลค่าเหล่านี้อาจรวมถึงการรวม Google Signals, การประมาณ, การระบุแหล่งที่มาของการเข้าชม, การคาดการณ์ ฯลฯ

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

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

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

ทดสอบผลิตภัณฑ์

โปรดยืนยันว่าข้อมูลเหล่านั้นไม่ได้อิงตามข้อมูลตัวอย่าง เพื่อให้สามารถเปรียบเทียบข้อมูล BigQuery Export กับรายงานมาตรฐาน รายงาน Data API หรือรายงานการสำรวจได้อย่างแม่นยำ การสุ่มตัวอย่างข้อมูลใน GA4 จะให้รายละเอียดเพิ่มเติมและวิธีจัดการกับการสุ่มตัวอย่าง

ผู้ใช้ที่ใช้งานอยู่

หากนับผู้ใช้ทั้งหมดที่บันทึกเหตุการณ์อย่างน้อย 1 เหตุการณ์ในพร็อพเพอร์ตี้ GA4 คุณจะเห็นเมตริกผู้ใช้ทั้งหมด แม้ว่าเมตริกผู้ใช้ทั้งหมดจะแสดงในการสํารวจใน UI ของ GA4 แต่เมตริกผู้ใช้หลักที่ใช้ในการรายงานใน GA4 คือผู้ใช้ที่ใช้งานอยู่ ใน UI ของ GA4 และในรายงาน หากพูดถึงเฉพาะผู้ใช้ ก็มักจะหมายถึงผู้ใช้ที่ใช้งานอยู่ ดังนั้นเมื่อคำนวณจำนวนผู้ใช้จากข้อมูล BigQuery คุณจะต้องกรองและเก็บเฉพาะผู้ใช้ที่ใช้งานอยู่ไว้เพื่อให้ตัวเลขเปรียบเทียบกับ UI ของ GA ได้ นอกจากนี้ วิธีการคำนวณจะแตกต่างกันไปตามข้อมูลระบุตัวตนในการรายงานที่คุณเลือกด้วย

การใช้งานทางเทคนิค

ในข้อมูลการส่งออกเหตุการณ์ BigQuery หากคุณนับจำนวนรหัสผู้ใช้ที่ไม่ซ้ำกัน คุณจะเห็นจำนวนผู้ใช้ทั้งหมด ต่อไปนี้คือตัวอย่างคำค้นหาที่แสดงทั้งผู้ใช้ทั้งหมดและผู้ใช้ใหม่ตาม user_pseudo_id

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

หากต้องการเลือกเฉพาะผู้ใช้ที่ใช้งานอยู่ ให้จำกัดการค้นหาเป็นเหตุการณ์ที่ is_active_user เท่ากับ true ดังนี้

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

Google Analytics ใช้อัลกอริทึม HyperLogLog++ (HLL++) เพื่อประมาณ Cardinality สำหรับเมตริกทั่วไป ซึ่งรวมถึงผู้ใช้ที่ใช้งานอยู่และเซสชัน ซึ่งหมายความว่าเมื่อคุณดูจำนวนที่ไม่ซ้ำกันของเมตริกเหล่านี้ใน UI หรือผ่าน API ค่าเหล่านี้เป็นค่าประมาณที่มีความแม่นยำในระดับหนึ่ง ใน BigQuery คุณจะคํานวณ Cardinality ที่แน่นอนสําหรับเมตริกเหล่านี้ได้ เนื่องจากคุณมีสิทธิ์เข้าถึงข้อมูลแบบละเอียด เมตริกจึงแตกต่างกันในจำนวนที่น้อย ที่ช่วงความเชื่อมั่น 95% ความแม่นยำอาจเป็น ±1.63% สำหรับจำนวนเซสชัน ระดับความแม่นยำจะแตกต่างกันไปสำหรับเมตริกต่างๆ และจะเปลี่ยนไปตามช่วงความเชื่อมั่น โปรดดู HLL++ Sketches สำหรับระดับความแม่นยำของช่วงความเชื่อมั่นต่างๆ สำหรับพารามิเตอร์ความแม่นยำที่แตกต่างกันของ HLL++

การใช้งานทางเทคนิค

ดูการประมาณจำนวนที่ไม่ซ้ำกันใน Google Analytics เพื่อทำความเข้าใจวิธีใช้ HLL++ ใน Google Analytics และวิธีจำลองฟังก์ชันการทำงานด้วยคำค้นหา BigQuery

ความล่าช้าในการเก็บรวบรวมข้อมูล

ระบบจะสร้างตารางการส่งออกรายวันหลังจากที่ GA รวบรวมเหตุการณ์ทั้งหมดของวัน ตารางรายวันจะอัปเดตหลังจากวันที่ของตารางได้สูงสุด 72 ชั่วโมง ด้วยเหตุการณ์ที่มีการประทับเวลาด้วยวันที่ในตาราง อ่านรายละเอียดเกี่ยวกับเรื่องนี้และดูตัวอย่าง ซึ่งไม่เป็นปัญหาหากการใช้ Firebase SDK หรือ Measurement Protocol ส่งเหตุการณ์ออฟไลน์หรือเหตุการณ์ล่าช้า คุณอาจเห็นความแตกต่างระหว่างแพลตฟอร์มการรายงานมาตรฐานและ BigQuery อัปเดตภายใน 72 ชั่วโมง สําหรับการใช้งานดังกล่าว คุณควรเปรียบเทียบข้อมูลที่เก่ากว่า 72 ชั่วโมง

รายงาน High Cardinality

สมมติว่าคุณกำลังดูรายงานผ่านรายงานมาตรฐานหรือ Data API รายงานจะแสดงข้อมูลจำนวนมากและมีมิติข้อมูลที่มีจำนวนสมาชิกในเซ็ตสูง มิติข้อมูล High Cardinality อาจทําให้รายงานมี Cardinality เกินขีดจำกัดสําหรับตารางที่เกี่ยวข้อง เมื่อเกิดกรณีนี้ขึ้น Google Analytics จะจัดกลุ่มค่าที่พบไม่บ่อยไว้ด้วยกันแล้วติดป้ายกํากับเป็น (อื่นๆ)

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

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

การจัดกลุ่มแถว (อื่นๆ) นี้จะเกิดขึ้นในโมดูลการรายงานและ Data API เท่านั้นเมื่อรายงานมีค่าเกินขีดจำกัดของจำนวนสมาชิกในเซ็ต หากคำนวณจาก BigQuery คุณจะได้รับข้อมูลข้อมูลจากการสังเกตการณ์โดยตรง ซึ่งเป็นแถวที่ละเอียดที่สุดเสมอ อ่านเพิ่มเติมเกี่ยวกับแถว (อื่นๆ) และแนวทางปฏิบัติแนะนําเกี่ยวกับวิธีหลีกเลี่ยงแถวดังกล่าว

Google Signals

การเปิดใช้งาน Google Signals ในพร็อพเพอร์ตี้ GA4 มีข้อดีหลายอย่าง ซึ่งรวมถึงการทำซ้ำผู้ใช้ในแพลตฟอร์มและอุปกรณ์ต่างๆ หากคุณไม่ได้รวบรวม User-ID หรือเปิดใช้งาน Google Signals แล้วมีคนดูเว็บไซต์ใน 3 เว็บเบราว์เซอร์ที่แตกต่างกัน Google Analytics จะระบุแหล่งที่มาของกิจกรรมดังกล่าวไปยังผู้ใช้ 3 ราย และ BigQuery Export จะมี user_pseudo_id แยกกัน 3 รายการ ในทางตรงกันข้าม เมื่อเปิดใช้งาน Google Signals และผู้ใช้เข้าสู่ระบบบัญชี Google บัญชีเดียวในทั้ง 3 เบราว์เซอร์ Google Analytics จะระบุว่ากิจกรรมนั้นมาจากผู้ใช้1 คน และนับรวมในแพลตฟอร์มการรายงานมาตรฐาน อย่างไรก็ตาม BigQuery จะยังคงแสดง user_pseudo_id แยกกัน 3 รายการเนื่องจากข้อมูล Google Signals จะไม่แสดงใน BigQuery Export ดังนั้น รายงานที่มีข้อมูล Google Signals มีแนวโน้มที่จะมีจำนวนผู้ใช้น้อยกว่าเมื่อเทียบกับ BigQuery Export

วิธีที่ดีที่สุดในการลดผลกระทบนี้คือติดตั้งใช้งาน User-ID ในพร็อพเพอร์ตี้ GA4 ควบคู่กับการเปิดใช้งาน Google Signals การดำเนินการนี้จะดูแลให้มีการกรองข้อมูลที่ซ้ำกันออกก่อน โดยอิงตาม user_id สำหรับผู้ใช้ที่ลงชื่อเข้าใช้ ระบบจะป้อนข้อมูลในช่อง user_id ใน BigQuery และใช้เพื่อการคำนวณได้ อย่างไรก็ตาม สำหรับผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ (เช่น เซสชันที่ไม่มี user_id) ระบบจะยังใช้ Google Signals เพื่อการกรองข้อมูลที่ซ้ำกันออก

นอกจากนี้ โปรดทราบว่ารายงานบางรายการในแพลตฟอร์มการรายงานมาตรฐานอาจมีการใช้เกณฑ์ และไม่ได้แสดงผลข้อมูลบางอย่าง ข้อมูลส่วนใหญ่ที่อาจอยู่ภายใต้เกณฑ์มักจะไม่มีใน BigQuery Export

โหมดความยินยอมและข้อมูลโดยประมาณ

โหมดความยินยอมในเว็บไซต์และแอปบนอุปกรณ์เคลื่อนที่ช่วยให้คุณแจ้งสถานะความยินยอมให้ใช้คุกกี้หรือตัวระบุแอปของผู้ใช้กับ Google ได้ เมื่อผู้เข้าชมปฏิเสธความยินยอม GA4 จะเติมเต็มช่องว่างของการเก็บรวบรวมข้อมูลด้วยการประมาณเหตุการณ์สําคัญและการประมาณด้านพฤติกรรม ไม่มีข้อมูลโดยประมาณในการส่งออกเหตุการณ์ BigQuery เมื่อมีการใช้โหมดความยินยอม ชุดข้อมูล BigQuery จะมีคําสั่ง ping ที่ไม่มีคุกกี้ซึ่ง GA รวบรวมไว้ และแต่ละเซสชันจะมี user_pseudo_id ที่แตกต่างกัน การสร้างรูปแบบดังกล่าวจะทำให้การรายงานมาตรฐานและข้อมูลแบบละเอียดใน BigQuery มีความแตกต่างกันตามการประมาณ เช่น ตามการประมาณด้านพฤติกรรม คุณอาจเห็นจํานวนผู้ใช้ที่ใช้งานอยู่น้อยกว่าเมื่อเทียบกับ BigQuery Export เนื่องจากการประมาณอาจพยายามคาดการณ์เซสชันหลายรายการจากผู้ใช้ที่ไม่ให้ความยินยอมแต่ละราย

ขอย้ำอีกครั้งว่าหากต้องการลดผลกระทบจากปัญหานี้ คุณควรติดตั้งใช้งาน User-ID ในพร็อพเพอร์ตี้ GA4 ระบบจะส่งออก user_id และมิติข้อมูลที่กําหนดเองไปยัง BigQuery โดยไม่คํานึงถึงสถานะความยินยอมของผู้ใช้

ข้อมูลการระบุแหล่งที่มาของการเข้าชม

ในข้อมูลการระบุแหล่งที่มาของการเข้าชม BigQuery จะพร้อมใช้งานในระดับผู้ใช้ (การเข้าชมครั้งแรก) และระดับเหตุการณ์ ข้อมูลเหล่านี้คือข้อมูลที่รวบรวม อย่างไรก็ตาม เนื่องจาก Google Analytics ใช้รูปแบบการระบุแหล่งที่มาของตัวเองในระดับเซสชัน ข้อมูลดังกล่าวจึงไม่มีอยู่ใน BigQuery Export โดยตรง หรือจะคำนวณด้วยข้อมูลที่มีอยู่ได้อย่างแม่นยำที่สุด คุณอาจพิจารณารวมชุดข้อมูล BigQuery เข้ากับข้อมูลจากบุคคลที่หนึ่งที่เกี่ยวข้อง และสร้างรูปแบบการระบุแหล่งที่มาของคุณเอง ทั้งนี้ขึ้นอยู่กับกรณีการใช้งานของคุณ ในอนาคต ข้อมูลที่รวบรวมไว้เพิ่มเติมสําหรับการระบุแหล่งที่มาของการเข้าชมอาจใช้งานได้ผ่านการส่งออกเหตุการณ์ของ BigQuery

ข้อผิดพลาดในการคำนวณที่พบบ่อย

• วิธีการคำนวณ: เมื่อคำนวณเมตริกต่างๆ ใน BigQuery โปรดตรวจสอบว่าคุณใช้วิธีการที่ถูกต้อง เช่น
  • วิธีมาตรฐานในการนับเซสชันสําหรับพร็อพเพอร์ตี้ Google Analytics 4 จะนับชุดค่าผสมที่ไม่ซ้ำกันของ user_pseudo_id/user_id กับ ga_session_id โดยไม่คำนึงถึงกรอบเวลา ใน Universal Analytics เซสชันจะรีเซ็ตตอนเที่ยงคืน ถ้าคุณทำตามรูปแบบ UA คำนวณเซสชันสำหรับแต่ละวัน แล้วบวกกันเพื่อให้ได้จำนวนเซสชันรวม คุณก็จะนับเซสชันที่เกิดขึ้นเป็นเวลาหลายวันซ้ำ
  • วิธีการคำนวณจำนวนผู้ใช้จะต้องได้รับการอัปเดต ทั้งนี้ขึ้นอยู่กับข้อมูลระบุตัวตนในการรายงานที่คุณเลือก
• ขอบเขตมิติข้อมูลและเมตริก: ตรวจสอบว่าการคำนวณใช้ขอบเขตระดับผู้ใช้ เซสชัน สินค้า หรือเหตุการณ์ที่ถูกต้อง
• เขตเวลา: ใน BigQuery Export event_date ใช้สําหรับเขตเวลาการรายงาน ขณะที่ event_timestamp คือการประทับเวลา UTC ในหน่วยไมโครวินาที ดังนั้นหากมีการใช้ event_timestamp ในการค้นหา ก็จะต้องปรับเขตเวลาการรายงานที่ถูกต้องเมื่อเปรียบเทียบกับจำนวน UI
• ขีดจํากัดการกรองและการส่งออกข้อมูล: หากคุณตั้งค่าการกรองข้อมูลสําหรับการส่งออกเหตุการณ์ BigQuery หรือการส่งออกเหตุการณ์รายวันเกินขีดจํากัด ข้อมูลการส่งออกเหตุการณ์ BigQuery จะไม่ตรงกับแพลตฟอร์มการรายงานมาตรฐาน

ด้วยเหตุนี้ UNNEST ในโพสต์นี้ยังมีส่วนเล็กๆ น้อยๆ จากทั้งหมด หวังว่าคุณจะเลือกโซลูชันที่เหมาะสมสำหรับโปรเจ็กต์ DISTINCT ของคุณ FROM ตามหลักเกณฑ์ที่นี่ได้ หากมีคำถาม คุณสามารถเข้าร่วมเซิร์ฟเวอร์ GA Discord ได้ ซึ่งเป็นที่ที่ยินดีรับคำค้นหามากที่สุด