สรุปสั้น ๆ (TL;DR)
- พร็อพเพอร์ตี GA4 แบบมาตรฐานส่งออกรายวันได้สูงสุด 1 ล้านอีเวนต์ต่อวัน พร็อพเพอร์ตีที่เกินซ้ำๆ อาจถูกหยุดการส่งออกรายวัน ส่วน streaming ไม่จำกัดจำนวนอีเวนต์
- การส่งออกแบบ streaming คิด 0.05 ดอลลาร์ต่อ GB และ Google ประมาณว่า 1 GB เท่ากับราว 600,000 อีเวนต์ของ GA4 เป็นบริการแบบ best-effort และตาราง intraday ไม่มีค่าฟิลด์ traffic_source ของผู้ใช้ใหม่
- BigQuery sandbox ใช้ฟรี แต่จำกัดพื้นที่ 10 GiB ตลอดอายุ ตารางหมดอายุหลัง 60 วัน และไม่รองรับ streaming
- การลิงก์ต้องมีสิทธิ์ Editor ขึ้นไปในพร็อพเพอร์ตี GA4 และสิทธิ์ OWNER ในโปรเจกต์ Google Cloud และการเปลี่ยนตำแหน่งที่เก็บข้อมูลภายหลังต้องลิงก์ใหม่หรือใช้ cross-region dataset replication
GA4 BigQuery export คือการส่งข้อมูลดิบระดับอีเวนต์ของ Google Analytics 4 เข้าไปเก็บในโปรเจกต์ Google BigQuery ที่คุณเป็นเจ้าของ แล้วใช้ SQL ดึงข้อมูลออกมาวิเคราะห์ได้เอง พร็อพเพอร์ตี GA4 แบบมาตรฐานเปิดใช้ได้ฟรี แต่การส่งออกรายวันจำกัดไว้ที่ 1 ล้านอีเวนต์ต่อวัน และเมื่อใช้เกินโควตาฟรี คุณต้องจ่ายค่าพื้นที่เก็บข้อมูล ค่าคิวรี และค่า streaming (ถ้าเปิดใช้) ให้ BigQuery
หน้าจอ GA4 แสดงรายงานที่สรุปรวมมาแล้ว ส่วนการส่งออกให้ข้อมูลทุกแถวของทุกอีเวนต์พร้อมพารามิเตอร์ คุณจึงสร้างเซสชันขึ้นใหม่เองได้ เชื่อมข้อมูล GA4 กับ CRM หรือค่าโฆษณาได้ และเก็บประวัติไว้นานเท่าที่ต้องการ บทความนี้อธิบายว่าการส่งออกมีข้อมูลอะไรบ้าง มีค่าใช้จ่ายเท่าไร ลิงก์พร็อพเพอร์ตีอย่างไร ตารางมีโครงสร้างแบบไหน และคิวรีแรกๆ ที่นักการตลาดมักเขียนมีอะไรบ้าง
GA4 BigQuery export มีข้อมูลอะไรบ้าง
เมื่อลิงก์พร็อพเพอร์ตีแล้ว Google จะสร้างชุดข้อมูล (dataset) ในโปรเจกต์ BigQuery ของคุณ แล้วเขียนตารางลงไป แต่ละแถวคือหนึ่งอีเวนต์ เช่น page_view, purchase, form_submit หรืออีเวนต์ที่คุณกำหนดเอง เอกสารช่วยเหลือของ Google ระบุว่าข้อมูลนี้เป็นข้อมูลดิบและไม่ผ่านการสุ่มตัวอย่าง จึงไม่มีปัญหาเรื่อง sampling แบบที่บางครั้งเจอใน Explorations ของ GA4
คุณเลือกได้ว่าจะให้ข้อมูลเข้ามาบ่อยแค่ไหน มีตัวเลือกความถี่สามแบบ และเปิดแบบรายวันกับแบบ streaming พร้อมกันได้
การส่งออกรายวัน (Daily export)
การส่งออกรายวันจะเขียนตารางวันละหนึ่งตาราง ชื่อ events_YYYYMMDD ซึ่งเก็บอีเวนต์ของเมื่อวาน Google ระบุว่าโดยปกติข้อมูลจะมาถึงภายในช่วงกลางบ่ายตามเขตเวลาที่ตั้งไว้ในพร็อพเพอร์ตี และอาจล่าช้ากว่านั้นได้ อีเวนต์ที่ส่งถึง Google ช้าก็ยังถูกเขียนลงในตารางรายวันที่เพิ่งสร้างได้ ตารางที่คุณคิวรีเมื่อวันอังคารจึงอาจมีแถวเพิ่มขึ้นเล็กน้อยในวันพฤหัสบดี ถ้าแดชบอร์ดของคุณอ่านตารางของเมื่อวานตั้งแต่เช้าตรู่ ก็มักจะยังไม่เจอข้อมูล
การส่งออกแบบ Streaming
Streaming จะเขียนอีเวนต์ลงในตาราง intraday ชื่อ events_intraday_YYYYMMDD ภายในไม่กี่นาทีหลังเก็บข้อมูล และตาราง intraday จะถูกลบเมื่อตารางรายวันของวันนั้นเสร็จสมบูรณ์ Google ระบุว่า streaming เป็นบริการแบบ best-effort ที่ไม่มีเป้าหมายด้านความครบถ้วน และอาจมีข้อมูลขาดหาย รายละเอียดหนึ่งที่คนมักพลาดคือฟิลด์ traffic_source ซึ่งบอกว่าผู้ใช้ใหม่มาจากช่องทางไหนเป็นครั้งแรกจะไม่มีค่าในตาราง intraday ใช้ streaming สำหรับการตรวจสอบแบบเกือบเรียลไทม์ เช่น ดูว่าแคมเปญที่เพิ่งเปิดเก็บข้อมูลได้หรือยัง แล้วใช้ตารางรายวันกับทุกอย่างที่ต้องรายงาน
Fresh Daily (เฉพาะ Analytics 360)
พร็อพเพอร์ตี Analytics 360 มีตัวเลือกที่สามคือ Fresh Daily ซึ่งอัปเดตเป็นชุดตลอดวัน โดยทั่วไปภายใน 60 นาที พร็อพเพอร์ตีแบบมาตรฐานไม่มีตัวเลือกนี้
ตารางข้อมูลผู้ใช้
นอกจากตารางอีเวนต์แล้ว การลิงก์ยังส่งออกตารางระดับผู้ใช้ได้ด้วย (pseudonymous_users_ และ users_) ซึ่งอธิบายข้อมูลของผู้ใช้แทนที่จะเป็นอีเวนต์แต่ละรายการ งานวิเคราะห์การตลาดส่วนใหญ่เริ่มจากตารางอีเวนต์ จึงเก็บตารางเหล่านี้ไว้เป็นขั้นที่สอง
ขีดจำกัดของโควตาฟรีและค่าใช้จ่าย
สำหรับพร็อพเพอร์ตีแบบมาตรฐาน GA4 ไม่เก็บค่าบริการการส่งออก ค่าใช้จ่ายและขีดจำกัดอยู่ที่สองจุด คือขีดจำกัดการส่งออกของ GA4 และราคาของ BigQuery เอง
- เพดาน 1 ล้านอีเวนต์ต่อวัน พร็อพเพอร์ตีแบบมาตรฐานมีขีดจำกัดการส่งออกรายวัน (แบบ batch) อยู่ที่ 1 ล้านอีเวนต์ Google ระบุว่าพร็อพเพอร์ตีที่เกินขีดจำกัดซ้ำๆ อาจถูกหยุดการส่งออกรายวัน และวันที่ขาดไปจะไม่ถูกประมวลผลย้อนหลัง การส่งออกแบบ streaming ไม่จำกัดจำนวนอีเวนต์ ส่วนพร็อพเพอร์ตี Analytics 360 ส่งออกได้สูงสุด 2 หมื่นล้านอีเวนต์ต่อวัน
- ค่า streaming คิดในอัตรา 0.05 ดอลลาร์สหรัฐต่อกิกะไบต์ Google ให้ตัวเลขคร่าวๆ ว่า 1 GB เท่ากับประมาณ 600,000 อีเวนต์ของ GA4 เว็บไซต์ที่ส่ง 3 ล้านอีเวนต์ต่อเดือนจึงใช้ streaming ราว 5 GB หรือประมาณ 0.25 ดอลลาร์ต่อเดือน ยังไม่รวมค่าพื้นที่และค่าคิวรี ตัวเลขนี้เป็นตัวอย่างที่คำนวณจากอัตราที่ Google เผยแพร่ ไม่ใช่ใบเสนอราคา
- พื้นที่เก็บข้อมูลและคิวรี BigQuery คิดค่าบริการสองส่วน คือการเก็บข้อมูลและการประมวลผลคิวรี การส่งออกทุกครั้งเพิ่มพื้นที่ที่ใช้ และทุกคิวรีที่รันจะสแกนข้อมูล โควตาประมวลผลฟรีคือ 1 TiB ของข้อมูลที่คิวรีต่อเดือน
ถ้าพร็อพเพอร์ตีของคุณส่งอีเวนต์เกิน 1 ล้านในวันที่มีคนเข้าเยอะ วิธีแรกที่ Google แนะนำคือการกรองอีเวนต์ในการตั้งค่าลิงก์ การตัดอีเวนต์ที่ไม่เคยนำไปวิเคราะห์ออก เช่น scroll หรือ user_engagement ถ้าคุณไม่ได้ใช้ ช่วยให้การส่งออกรายวันอยู่ใต้เพดาน ตรวจเรื่องนี้ก่อนช่วงลดราคา เพราะปริมาณอีเวนต์อาจพุ่งสูงกว่าวันปกติมาก
Sandbox กับบัญชีเรียกเก็บเงิน
คุณส่งออกข้อมูล GA4 ไปยัง BigQuery sandbox ได้โดยไม่ต้องผูกวิธีชำระเงิน เหมาะสำหรับการทดลอง แต่ขีดจำกัดของ sandbox มีผลมากเมื่อใช้งานจริง
ตามเอกสาร sandbox ของ Google Cloud แซนด์บ็อกซ์ให้พื้นที่เก็บข้อมูลแบบจำกัดตลอดอายุ 10 GiB (ลบข้อมูลแล้วโควตาไม่คืน) และประมวลผลคิวรีได้ 1 TiB ต่อเดือน ตาราง วิว และพาร์ทิชันจะหมดอายุอัตโนมัติหลัง 60 วัน แซนด์บ็อกซ์ไม่รองรับ streaming และไม่รองรับคำสั่ง DML อย่าง UPDATE หรือ DELETE
การหมดอายุใน 60 วันคือข้อจำกัดที่สำคัญที่สุดสำหรับนักการตลาด ถ้าลิงก์พร็อพเพอร์ตีกับโปรเจกต์ sandbox แล้วลืมไป คุณจะมีข้อมูลดิบย้อนหลังแค่สองเดือนล่าสุดเสมอ ซึ่งทำให้เหตุผลหลักของการส่งออกหายไป ถ้าจะใช้นานกว่าช่วงทดลอง ให้ผูกบัญชีเรียกเก็บเงินกับโปรเจกต์ Google Cloud เมื่อเปิด billing แล้ว โควตาคิวรีฟรีรายเดือนยังใช้ได้เหมือนเดิม และคุณจ่ายเฉพาะส่วนที่เกิน
ตารางด้านล่างสรุปตัวเลือกต่างๆ ทุกแถวมาจากเอกสารช่วยเหลือของ GA4 และ BigQuery ของ Google
| ตัวเลือก | สิ่งที่ได้ | ข้อจำกัดหลัก |
|---|---|---|
| ส่งออกรายวัน | ตาราง events_YYYYMMDD วันละหนึ่งตาราง เก็บอีเวนต์ดิบของเมื่อวาน | 1 ล้านอีเวนต์ต่อวันสำหรับพร็อพเพอร์ตีแบบมาตรฐาน |
| ส่งออกแบบ Streaming | ตาราง events_intraday อัปเดตภายในไม่กี่นาที | 0.05 ดอลลาร์ต่อ GB แบบ best-effort ไม่มีฟิลด์แหล่งที่มาของผู้ใช้ใหม่ |
| Fresh Daily | อัปเดตเป็นชุดตลอดวัน โดยทั่วไปภายใน 60 นาที | เฉพาะพร็อพเพอร์ตี Analytics 360 |
| BigQuery sandbox | โปรเจกต์ฟรีที่ไม่ต้องผูกวิธีชำระเงิน | พื้นที่ 10 GiB ตลอดอายุ ตารางหมดอายุใน 60 วัน ไม่มี streaming |
วิธีลิงก์ GA4 กับ BigQuery
ตรวจสิทธิ์ให้พร้อมก่อนเริ่ม เพราะถ้าสิทธิ์ไม่ครบจะสร้างลิงก์ไม่ได้
- ใน Google Cloud สร้างหรือเลือกโปรเจกต์ แล้วเปิดใช้ BigQuery API
- ตรวจสอบสิทธิ์ คุณต้องมีบทบาท Editor ขึ้นไปในพร็อพเพอร์ตี GA4 และบัญชี Google ที่ใช้ต้องมีสิทธิ์ OWNER ในโปรเจกต์ Google Cloud
- ใน GA4 เปิด Admin หา BigQuery links ใต้หัวข้อ Product links แล้วคลิก Link
- เลือกโปรเจกต์ BigQuery จากรายการ
- เลือกตำแหน่งที่เก็บข้อมูล (data location) อย่างระมัดระวัง วิธีเปลี่ยนภายหลังตามเอกสารของ Google คือลบลิงก์ สำรองข้อมูลแล้วสร้างชุดข้อมูลใหม่ในตำแหน่งใหม่ แล้วลิงก์ใหม่ ซึ่งทำให้การส่งออกหยุดชั่วคราวและข้อมูลอาจขาดช่วง ทางเลือกที่ Google ระบุไว้เพื่อย้ายชุดข้อมูลโดยไม่ขาดช่วงคือ cross-region dataset replication
- เลือกสตรีมข้อมูลที่จะรวม และตัดอีเวนต์ที่ไม่ต้องการออก
- สำหรับสตรีมแอป ตัดสินใจว่าจะรวมตัวระบุโฆษณา (advertising identifiers) หรือไม่
- เลือกแบบรายวัน แบบ streaming หรือทั้งสองแบบ จากนั้นตรวจทานแล้วกดส่ง
Google ระบุว่าข้อมูลควรเริ่มเข้ามาภายใน 24 ชั่วโมง การส่งออกสะสมประวัติตั้งแต่วันที่คุณลิงก์ พร็อพเพอร์ตีที่ลิงก์วันนี้จึงจะมีข้อมูลดิบหนึ่งวันในวันพรุ่งนี้ และมีหนึ่งปีในปีหน้า นี่คือเหตุผลที่หนักแน่นที่สุดที่ควรลิงก์ให้เร็ว แม้ยังไม่มีใครวางแผนจะคิวรีไปอีกหลายเดือน
ถ้าคุณยังจัดระเบียบการตั้งค่า GA4 ไม่เสร็จ ให้แก้การติดแท็กก่อนจะพึ่งพาข้อมูลส่งออก อีเวนต์ซ้ำ ค่า purchase ที่หายไป และชื่ออีเวนต์ที่ไม่สม่ำเสมอ จะถูกส่งเข้า BigQuery ตามที่เก็บมาทุกประการ บริการตรวจสอบและย้ายระบบ GA4 คือจุดที่ควรแก้ปัญหาเหล่านี้
พื้นฐานโครงสร้างตารางอีเวนต์
ครั้งแรกที่เห็นโครงสร้างตาราง อาจรู้สึกแปลกเพราะมีฟิลด์ซ้อนกันและฟิลด์ที่ซ้ำได้ แต่เมื่อเข้าใจคอลัมน์หลักห้าหกคอลัมน์แล้ว คิวรีส่วนใหญ่จะใช้รูปแบบเดียวกัน
- event_date วันที่ในรูปแบบสตริง YYYYMMDD ตามเขตเวลาของพร็อพเพอร์ตี
- event_timestamp ตัวเลขจำนวนเต็มหน่วยไมโครวินาทีตามเวลา UTC ของเวลาที่บันทึกอีเวนต์
- event_name ชื่ออีเวนต์ เช่น page_view หรือ purchase
- event_params เรคคอร์ดแบบซ้ำได้ แต่ละรายการมี key และ value โดย value มีฟิลด์ที่เป็นไปได้สี่แบบ (string_value, int_value, float_value, double_value) และจะมีค่าเฉพาะฟิลด์ที่ตรงกับชนิดของพารามิเตอร์
- user_pseudo_id รหัสนามแฝงของเบราว์เซอร์หรืออินสแตนซ์ของแอป ส่วน user_id จะมีค่าก็ต่อเมื่อคุณส่งรหัสของตัวเองเข้าไป
- device และ geo เรคคอร์ดที่เก็บประเภทอุปกรณ์ ระบบปฏิบัติการ เบราว์เซอร์ รวมถึงประเทศ ภูมิภาค และเมือง
- traffic_source แหล่งที่มาที่ได้ผู้ใช้คนนั้นมาเป็นครั้งแรก ค่านี้ไม่เปลี่ยนในการเข้าชมครั้งต่อๆ ไป จึงไม่ใช่แหล่งที่มาของเซสชัน
- collected_traffic_source และ session_traffic_source_last_click ข้อมูลแคมเปญที่เก็บมาพร้อมอีเวนต์ (UTM, gclid) และแหล่งที่มาของเซสชันแบบคลิกสุดท้าย
- ecommerce และ items ค่าระดับธุรกรรม และหนึ่งรายการต่อสินค้าแต่ละชิ้นในอีเวนต์
เพราะ event_params เป็นฟิลด์ซ้ำได้ คุณจึงต้องอ่านพารามิเตอร์ด้วย UNNEST ถ้าต้องการ URL ของหน้าจากอีเวนต์ page_view ให้หาใน event_params ที่มี key เป็น page_location แล้วเอาค่า string_value พารามิเตอร์ ga_session_id ก็ใช้วิธีเดียวกัน แต่ใช้ int_value
คอลัมน์ traffic_source เป็นต้นเหตุของตัวเลขผิดที่พบบ่อยที่สุด นักวิเคราะห์ที่จัดกลุ่มเซสชันด้วย traffic_source.source กำลังจัดกลุ่มตามแหล่งที่มาครั้งแรกของผู้ใช้ ผู้ใช้ที่กลับมาจากแคมเปญโฆษณาจึงถูกนับให้กับช่องทางที่พาเขามาครั้งแรก สำหรับรายงานช่องทางระดับเซสชัน ให้ใช้ session_traffic_source_last_click หรือพารามิเตอร์แคมเปญที่เก็บมาแทน
คิวรีที่นักการตลาดใช้บ่อย
เซสชัน
BigQuery ไม่มีคอลัมน์เซสชัน เซสชันคือการจับคู่ระหว่าง user_pseudo_id กับพารามิเตอร์อีเวนต์ ga_session_id คุณจึงนับจำนวนคู่ที่ไม่ซ้ำกันของสองค่านี้ ผลลัพธ์ควรใกล้เคียงกับหน้าจอ GA4 แต่จะไม่ตรงกันพอดี รายงาน GA4 กับข้อมูลดิบที่ส่งออกคำนวณด้วยวิธีต่างกัน และหน้าจออาจมีการประมวลผลที่ข้อมูลส่งออกไม่มี ตกลงกันภายในทีมว่าตัวเลขไหนเป็นมาตรฐานของการรายงาน แทนที่จะพยายามบังคับให้ตรงกัน
Attribution และรายงานช่องทาง
เมื่อมี source และ medium ระดับเซสชัน คุณสร้างการจัดกลุ่มช่องทางของตัวเองได้ เทียบมุมมองแบบ first-touch กับ last-click คู่กันได้ และเชื่อม conversion ของ GA4 กับข้อมูลค่าใช้จ่าย Google Ads ที่โหลดเข้าโปรเจกต์เดียวกันได้ ตรงนี้คือจุดที่การส่งออกคุ้มค่าที่สุดสำหรับสื่อโฆษณา เพราะคุณคำนวณต้นทุนต่อ conversion รายแคมเปญด้วยนิยาม conversion ของคุณเอง ไม่ใช่นิยามที่ตั้งไว้ในหน้าจอ GA4 ถ้า paid search เป็นส่วนใหญ่ของงบ การใช้ข้อมูลนี้ควบคู่กับ บริการดูแลโฆษณา Google Ads ที่เป็นระบบจะทำให้ตัวเลขนำไปใช้ได้จริง ไม่ใช่แค่มีไว้ดู
Funnel
Funnel ใน SQL คือลำดับอีเวนต์ต่อผู้ใช้หรือต่อเซสชัน เช่น view_item ตามด้วย add_to_cart ตามด้วย begin_checkout แล้วจึง purchase คุณกำหนดกรอบเวลาเองได้ และเลือกได้ว่าแต่ละขั้นต้องเกิดตามลำดับหรือไม่ Explorations ใน GA4 ก็ทำแบบนี้ได้ แต่ใน BigQuery คุณบันทึกตรรกะไว้ รันกับข้อมูลหลายเดือน และส่งผลต่อไปยังเครื่องมืออื่นได้
การวิเคราะห์หน้า Landing page และเนื้อหา
การดึง page_location จาก page_view แรกของแต่ละเซสชันจะได้รายการหน้า landing page พร้อมจำนวนเซสชัน การมีส่วนร่วม และ conversion เมื่อนำไปรวมกับข้อมูลการค้นหา คุณจะเห็นว่าหน้า organic ไหนพาเซสชันที่เกิด conversion เข้ามา ซึ่งเป็นข้อมูลตั้งต้นที่มีประโยชน์สำหรับ การตรวจสอบ SEO
มีนิสัยหนึ่งที่ช่วยประหยัดเงินในทุกคิวรี คือเลือกเฉพาะคอลัมน์ที่ต้องใช้ และกรองตามวันที่ของตาราง (ใช้ _TABLE_SUFFIX กับตาราง wildcard events_*) BigQuery คิดเงินตามจำนวนไบต์ที่ประมวลผล การใช้ SELECT * กับตารางหนึ่งปีจึงสแกนข้อมูลมากกว่าคิวรีที่อ่านสามคอลัมน์จากข้อมูลหนึ่งเดือนหลายเท่า
เมื่อไรควรใช้ Looker Studio ต่อกับ BigQuery
Looker Studio เชื่อมต่อกับ GA4 ได้โดยตรง และสำหรับเว็บไซต์ขนาดเล็กหลายแห่งก็เพียงพอแล้ว การใช้ BigQuery เป็นแหล่งข้อมูลเหมาะเมื่อคุณต้องการสิ่งที่ตัวเชื่อมต่อโดยตรงทำได้ไม่ดี เช่น การรวม GA4 กับข้อมูล CRM ค่าโฆษณา หรือยอดขายออฟไลน์ การใช้นิยามเซสชันหรือช่องทางของตัวเอง การเก็บประวัติให้นานกว่าการตั้งค่าระยะเวลาเก็บข้อมูลใน GA4 หรือการนำการคำนวณหนักๆ มาใช้ซ้ำโดยไม่ชนขีดจำกัดของการรายงาน
สิ่งที่ต้องแลกคือค่าใช้จ่ายและการดูแล ทุกครั้งที่แดชบอร์ดโหลดหรือมีการเปลี่ยนตัวกรอง Looker Studio จะส่งคิวรีไปที่ BigQuery และคิวรีเหล่านั้นสแกนข้อมูล รูปแบบที่นิยมคือเขียน scheduled query ที่สร้างตารางสรุปขนาดเล็ก (เซสชัน conversion และรายได้ แยกตามวัน ช่องทาง และ landing page) แล้วให้ Looker Studio อ่านจากตารางนั้นแทนอีเวนต์ดิบ แดชบอร์ดจะโหลดเร็วขึ้นและค่าคิวรีก็ต่ำ
สิ่งนี้มีความหมายอย่างไรสำหรับนักการตลาดไทย
สำหรับธุรกิจไทย การส่งออกมีประโยชน์ที่สุดในจุดที่ GA4 อย่างเดียวทำไม่ได้ คือการเชื่อมพฤติกรรมบนเว็บไซต์เข้ากับลีดจาก LINE OA การโทรสอบถาม หรือยอดขายที่ปิดแบบออฟไลน์ ถ้าคุณโหลดข้อมูลเหล่านั้นเข้าโปรเจกต์ BigQuery เดียวกัน ก็เชื่อมกับ GA4 ได้ผ่าน user_id หรือรหัสคลิกที่เก็บไว้ในฟอร์ม มีสองเรื่องที่ต้องระวัง ข้อแรก เลือกตำแหน่งที่เก็บข้อมูลอย่างตั้งใจตั้งแต่ตอนลิงก์ เพราะการเปลี่ยนภูมิภาคในภายหลังต้องลิงก์ใหม่ (ซึ่งข้อมูลอาจขาดช่วง) หรือตั้ง cross-region replication ข้อสอง ตรวจว่าชื่อหน้าภาษาไทยและ URL ภาษาไทยที่ถูกเข้ารหัสแสดงผลถูกต้องในคิวรี เพราะ page_location เก็บ URL แบบเข้ารหัสตามที่เก็บมา
คำถามที่พบบ่อย
GA4 BigQuery export ฟรีหรือไม่
ตัวการส่งออกฟรีสำหรับพร็อพเพอร์ตี GA4 แบบมาตรฐาน แต่ BigQuery คิดค่าพื้นที่เก็บข้อมูล การประมวลผลคิวรี และ streaming โควตาคิวรีฟรีคือ 1 TiB ของข้อมูลที่ประมวลผลต่อเดือน และ streaming คิด 0.05 ดอลลาร์ต่อ GB
ถ้าพร็อพเพอร์ตีส่งอีเวนต์เกิน 1 ล้านต่อวันจะเกิดอะไรขึ้น
พร็อพเพอร์ตีแบบมาตรฐานที่เกินขีดจำกัดการส่งออกรายวัน 1 ล้านอีเวนต์ซ้ำๆ อาจถูกหยุดการส่งออกรายวัน และวันที่ขาดไปจะไม่ถูกประมวลผลย้อนหลัง คุณตัดอีเวนต์ออกในการตั้งค่าลิงก์เพื่อให้อยู่ใต้เพดานได้ หรือใช้ streaming ซึ่งไม่จำกัดจำนวนอีเวนต์
ใช้ BigQuery sandbox ระยะยาวได้หรือไม่
Sandbox ใช้ทดลองได้ แต่ไม่เหมาะกับการเก็บข้อมูลระยะยาว เพราะตารางหมดอายุหลัง 60 วันและพื้นที่จำกัดที่ 10 GiB อีกทั้งยังไม่รองรับ streaming ให้ผูกบัญชีเรียกเก็บเงินถ้าต้องการเก็บประวัติ
ทำไมจำนวนเซสชันใน BigQuery ไม่ตรงกับรายงาน GA4
ตัวเลขใน BigQuery คำนวณจากอีเวนต์ดิบ ส่วนรายงาน GA4 ประมวลผลต่างออกไป ส่วนต่างเล็กน้อยจึงเป็นเรื่องปกติ ตรวจว่าคุณนับคู่ user_pseudo_id กับ ga_session_id ที่ไม่ซ้ำกัน และใช้ฟิลด์แหล่งที่มาระดับเซสชันแทน traffic_source
เริ่มต้นใช้งาน
ลิงก์พร็อพเพอร์ตีตั้งแต่ตอนนี้ แม้จะยังไม่เขียนคิวรี เพราะประวัติข้อมูลดิบเริ่มนับจากวันที่คุณเชื่อมต่อเท่านั้น ใช้โปรเจกต์ที่เปิด billing เลือกตำแหน่งที่เก็บข้อมูลครั้งเดียวให้ถูก กรองอีเวนต์ที่จะไม่มีวันนำไปวิเคราะห์ออก และสร้างตารางสรุปก่อนจะวางแดชบอร์ดไว้ด้านบน ถ้าการติดแท็ก GA4 ของคุณยังต้องแก้ไขก่อนที่ข้อมูลส่งออกจะน่าเชื่อถือ ทีมของเราช่วยได้ผ่าน บริการตรวจสอบการตั้งค่าและย้ายระบบ GA4
