แนวทางปฏิบัติแนะนำ

โปรดคำนึงถึงแนวทางปฏิบัติแนะนำต่อไปนี้เมื่อใช้ Data Manager API

ส่งตัวระบุผู้ใช้ทั้งหมด

ไม่ว่าจะส่งสมาชิกในกลุ่มเป้าหมายหรือเหตุการณ์ด้วย UserData ให้ใส่ user_identifiers ให้มากที่สุดเท่าที่จะเป็นไปได้ ซึ่งรวมถึงการส่งตัวระบุหลายรายการที่เป็นประเภทเดียวกัน

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

คำขอเพิ่มประสิทธิภาพ

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

เช่น หากต้องการเพิ่มสมาชิกในกลุ่มเป้าหมาย 10,000 คนลงในกลุ่มเป้าหมาย ให้เพิ่มสมาชิกทั้ง 10,000 คนในรายการ audience_members ใน IngestAudienceMembersRequest รายการเดียว การรวมสมาชิกทั้ง 10,000 รายไว้ในคำขอเดียวจะมีประสิทธิภาพมากกว่าการส่งคำขอแยกต่างหากเพื่อเพิ่มสมาชิกในกลุ่มเป้าหมายแต่ละราย

ส่งคำขอหลายรายการพร้อมกัน

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

คุณส่งคำขอหลายรายการพร้อมกันได้แม้ว่าคำขอจะมี destinations เดียวกันก็ตาม

ตรวจสอบข้อมูลฝั่งไคลเอ็นต์

Data Manager API ใช้โมเดล Fast-Fail หากระเบียนใดๆ ในคำขอไม่ผ่านการตรวจสอบแบบซิงโครนัส คำขอทั้งหมดจะล้มเหลวและจะไม่มีการประมวลผลระเบียนใดๆ นอกจากนี้ API จะตรวจสอบคำขอในชั้นการตรวจสอบตามลำดับ ดังนั้นการแก้ไขข้อผิดพลาดหนึ่งอาจแสดงข้อผิดพลาดจากชั้นการตรวจสอบที่ตามมา

เพื่อหลีกเลี่ยงการส่งข้อมูลไป-กลับซ้ำๆ และคำขอที่ถูกปฏิเสธ ให้ตรวจสอบและล้างข้อมูลก่อนส่ง โดยทำดังนี้

• ตัดค่าที่ว่างเปล่าออกก่อนแฮช: ตรวจสอบช่องต่างๆ เช่น email_address และ phone_number เพื่อหาค่าว่างหรือสตริงที่มีเฉพาะเว้นวรรคก่อนคำนวณแฮช SHA-256 การแฮชสตริงว่างจะสร้างแฮชที่ถูกต้องซึ่งผ่านการตรวจสอบไวยากรณ์ แต่จะส่งผลเสียต่ออัตราการจับคู่

• ทิ้งออบเจ็กต์แบบผสมที่ไม่สมบูรณ์: ตรวจสอบว่าออบเจ็กต์แบบผสมมีช่องที่ต้องกรอกทั้งหมดก่อนที่จะเพิ่มลงในระเบียน เช่น หากออบเจ็กต์ AddressInfo ไม่มีช่องที่ต้องกรอก 4 ช่อง (given_name, family_name, region_code หรือ postal_code) ให้ทิ้งตัวระบุ address ทั้งหมดเพื่อหลีกเลี่ยงข้อผิดพลาด REQUIRED_FIELD_MISSING

• ตรวจสอบฟิลด์การเข้ารหัสและข้อความธรรมดา: ตรวจสอบว่าฟิลด์ที่แฮชตรงกับ encoding ที่ประกาศไว้แทนที่จะส่งข้อความธรรมดา และตรวจสอบว่าฟิลด์ที่ต้องเป็นข้อความธรรมดา (เช่น mobile_ids) ไม่ได้แฮช

• กรองการประทับเวลาที่อยู่นอกขอบเขต: ตรวจสอบว่าการประทับเวลาไม่ได้อยู่ในอนาคตหรือเก่ากว่ากรอบเวลามองย้อนกลับของ Conversion ของปลายทาง

  หากคุณส่งคำขอโดยใช้ JSON โปรดตรวจสอบว่าสตริงการประทับเวลาใช้รูปแบบ RFC 3339 ที่มีการชดเชยเขตเวลา

• ล้างหมายเลขโทรศัพท์: ตรวจสอบว่าหมายเลขโทรศัพท์มีรหัสประเทศและใช้รูปแบบ E.164 ก่อนแฮช

• ตัดระเบียนที่ว่างเปล่าหรือมีขนาดใหญ่เกินไป: จำกัด user_identifiers ไว้ที่ขีดจำกัดต่อระเบียน (ตัวระบุ 10 รายการ) ทิ้งพารามิเตอร์ที่กำหนดเองที่ว่างเปล่า และละเว้นระเบียนที่มีตัวระบุที่ถูกต้องเป็น 0 รายการ

• ยืนยันข้อกำหนดของ Use Case: ตรวจสอบว่าแต่ละเหตุการณ์มีช่องที่จำเป็นทั้งหมดสำหรับปลายทางและ Use Case (เช่น transaction_id สำหรับ Conversion ออนไลน์ของ Google Ads) ดูรายการช่องที่ต้องกรอกทั้งหมดตามกรณีการใช้งานได้ที่คู่มือการส่งเหตุการณ์สำหรับปลายทางในภาพรวมเหตุการณ์

• ใช้ validateOnly เพื่อทดสอบคำขอ: ส่งคำขอโดยตั้งค่า validateOnly เป็น true เพื่อตรวจจับข้อผิดพลาดที่ทำให้ดำเนินการต่อไม่ได้โดยไม่ต้องนำเข้าหรือนำข้อมูลออก คำขอแบบตรวจสอบความถูกต้องเท่านั้นที่สำเร็จไม่ได้รับประกันว่าจะไม่มีข้อผิดพลาดระหว่างการประมวลผลแบบอะซิงโครนัส ดังนั้นโปรดตรวจสอบสถานะคำขอและการวินิจฉัยต่อไปหลังจากส่งคำขอปกติ

ดูกฎการแปลงเป็นรูปแบบมาตรฐานและการแฮชโดยละเอียดได้ที่จัดรูปแบบข้อมูลผู้ใช้

ตรวจสอบสถานะคำขอและการวินิจฉัย

บันทึกและรวบรวม request_id จากแต่ละ IngestAudienceMembersResponse หรือ IngestEventsResponse และใช้รหัสคำขอเพื่อตรวจสอบสถานะคำขอและการวินิจฉัย

ตรวจสอบและแจ้งเตือนเกี่ยวกับโควต้า

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

ทำให้ใช้งานได้จริง

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

ดูรายละเอียดเกี่ยวกับการกำหนดค่าการตรวจสอบสิทธิ์สำหรับสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ต่างๆ ได้ที่ทำให้ใช้งานได้จริง