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

Minhaz Kazi ผู้ประสานงานนักพัฒนาซอฟต์แวร์ของ Google Analytics – เมษายน ปี 2023

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

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

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

ด้วยโพสต์นี้ เราจะพยายามอธิบายทั้งสองสิ่งพร้อมกัน

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

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

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

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

การสุ่มตัวอย่าง

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

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

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

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

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

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

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

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

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

รายงาน High Cardinality

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

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

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

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

Google Signals

การเปิดใช้งาน Google Signals ในพร็อพเพอร์ตี้ GA4 มีประโยชน์หลายประการดังนี้ การกรองผู้ใช้ที่ซ้ำกันในแพลตฟอร์มและอุ��กรณ์ต่างๆ หากคุณไม่รวบรวมผู้ใช้ รหัสหรือเปิดใช้งาน Google Signals แล้วผู้ใช้ดูเว็บไซต์ของคุณใน เว็บเบราว์เซอร์ที่แตกต่างกัน Google Analytics จะระบุแหล่งที่มาของกิจกรรมนั้นเป็น ผู้ใช้ที่ต่างกัน และ 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 คำนวณเซสชันสำหรับ 1 ���ัน แล้วเพิ่มเซสชัน เพื่อให้ได้จำนวนเซสชันทั้งหมด คุณจะต้องนับเซสชัน เซสชันที่ครอบคลุมหลายๆ วัน
  • จำนวนผู้ใช้ขึ้นอยู่กับข้อมูลระบุตัวตนในการรายงานที่คุณเลือก จะต้องอัปเดตวิธีการคำนวณ
• ขอบเขตมิติข้อมูลและเมตริก: ตรวจสอบให้แน่ใจว่าการคำนวณของคุณใช้ แก้ไขขอบเขตระดับผู้ใช้ เซสชัน รายการ หรือเหตุการณ์
• เขตเวลา: ใน BigQuery Export ค่า event_date จะเป็นเวลาของการรายงาน ขณะที่ event_timestamp คือการประทับเวลา UTC ในหน่วยไมโครวินาที สไตรค์ ตามหลักการแล้ว หากมีผู้ใช้ event_timestamp ในการค้นหา ก็จะต้องมีการปรับเปลี่ยนให้ เขตเวลาการรายงานที่ถูกต้องเมื่อเปรียบเทียบกับตัวเลข UI
• ขีดจํากัดการกรองและการส่งออกข้อมูล: หากคุณตั้งค่าการกรองข้อมูลสําหรับ การส่งออกเหตุการณ์ BigQuery หรือการส่งออกเหตุการณ์รายวันมีจำนวนเกินกำหนดแล้ว ข้อมูลการส่งออกเหตุการณ์ BigQuery จะไม่จับคู่กับมาตรฐาน แพลตฟอร์มการรายงาน

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