แนวทางปฏิบัติแนะนำ
ขอแนะนําว่าคุณไม่ควรลงทะเบียนรหัสผู้ใช้เป็นมิติข้อมูลที่กําหนดเอง
การสร้างมิติข้อมูล High Cardinality ที่กําหนดเองที่ไม่จำเป็น เช่น รหัสผู้ใช้ จะส่งผลเสียต่อรายงานและทําให้ข้อมูลรวมอยู่ในแถว (other)
แต่ให้ใช้ฟีเจอร์ User-ID แทน
วิเคราะห์ข้อมูลที่อิงตามผู้ใช้
ข้อมูลด้านล่างนี้จะอธิบายฟีเจอร์ที่คุณสามารถใช้เพื่อโต้ตอบและวิเคราะห์ข้อมูลที่อิงตามผู้ใช้ได้
|
กรณีการใช้งาน |
ฟีเจอร์ |
|---|---|
|
ฉันต้องการสํารวจกลุ่มผู้ใช้และเจาะลึกลงไปในกิจกรรมของผู้ใช้แต่ละราย |
การสำรวจผู้ใช้ |
|
ฉันต้องการตรวจสอบพร็อพเพอร์ตี้ผู้ใช้ในขณะที่รวบรวมข้อมูล แก้ปัญหาที่เกิดขึ้น และทำความเข้าใจพฤติกรรมของผู้ใช้ขณะที่ผู้ใช้สํารวจเว็บไซต์หรือแอป |
DebugView |
|
ฉันต้องการกรองการรายงานที่ซ้ำกันตามรหัสผู้ใช้ออก ฉันต้องการเปรียบเทียบผู้ใช้ที่ลงชื่อเข้าใช้และผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ |
ยืนยันข้อมูลระบุตัวตนในการรายงาน ใน Universal Analytics ระบบจะใช้รหัสผู้ใช้ในรายงานรหัสผู้ใช้ที่เฉพาะเจาะจงเท่านั้น ดังนั้นจึงมีการบันทึกรหัสผู้ใช้เป็นมิติข้อมูลที่กําหนดเองที่จะใช้ในข้อมูลพร็อพเพอร์ตี้ที่ไม่ใช่รหัสผู้ใช้ และเปรียบเทียบการเข้าชม ใน GA4 ที่มี User-ID ในข้อมูลระบุตัวตนในการรายงาน การกรองรหัสผู้ใช้ที่ซ้ำกันออกจะปรากฏในรายงานทั้งหมด เปรียบเทียบผู้ใช้ที่ลงชื่อเข้าใช้และผู้ใช้ที่ไม่ได้ลงชื่อเข้าใช้ |
|
ฉันต้องการสร้างกลุ่มเป้าหมายรีมาร์เก็ตติ้งตามรหัสผู้ใช้ |
สร้างกลุ่มเป้าหมายรีมาร์เก็ตติ้งตามข้อมูล User-ID |
| ฉันต้องการดูข้อมูลระดับผู้ใช้ตามรหัสผู้ใช้ |
BigQuery Export ของ GA4 มีทั้งรหัสไคลเอ็นต์ (user_pseudo_id) และรหัสผู้ใช้ (user_id) ในสคีมา |
| ฉันต้องการรวมข้อมูล Analytics กับข้อมูลจากบุคคลที่หนึ่ง (เช่น ข้อมูล CRM) เพื่อให้ฉันวัด Conversion ออฟไลน์ได้ | BigQuery Export |
| ฉันต้องการเรียกใช้การวิเคราะห์เพิ่มเติมกับข้อมูล GA4 (เช่น การใช้งานโมเดล ML) และนําเข้าข้อมูลเชิงลึกกลับไปยัง Google Analytics | BigQuery Export และการนําเข้าข้อมูลเหตุการณ์ออฟไลน์ |