Các phương pháp hay nhất

Hãy lưu ý các phương pháp hay nhất sau đây khi sử dụng Data Manager API.

Gửi tất cả giá trị nhận dạng người dùng

Cho dù bạn gửi thành viên trong phân khúc đối tượng hay sự kiện bằng UserData, hãy thêm càng nhiều user_identifiers càng tốt, bao gồm cả việc gửi nhiều giá trị nhận dạng cùng loại.

Ví dụ: nếu bạn có nhiều địa chỉ email cho một người dùng, hãy thêm một thẻ UserIdentifier riêng biệt cho mỗi địa chỉ email. Tương tự, nếu bạn có giá trị nhận dạng thuộc nhiều loại cho một người dùng, chẳng hạn như địa chỉ email, số điện thoại và địa chỉ, hãy thêm một UserIdentifier riêng biệt cho mỗi giá trị nhận dạng, tối đa là số lượng giá trị nhận dạng tối đa.

Tối ưu hoá yêu cầu

Để giảm khả năng vượt quá hạn mức yêu cầu hằng ngày, hãy gộp nhiều mục nhất có thể vào mỗi yêu cầu, tối đa là hạn mức cho mỗi yêu cầu.

Ví dụ: nếu bạn muốn thêm 10.000 thành viên trong phân khúc đối tượng vào một đối tượng, hãy thêm tất cả 10.000 thành viên vào danh sách audience_members trong một IngestAudienceMembersRequest. Việc gộp tất cả 10.000 thành viên vào một yêu cầu duy nhất sẽ hiệu quả hơn so với việc gửi yêu cầu riêng để thêm từng thành viên trong phân khúc đối tượng.

Gửi yêu cầu đồng thời

Để giảm tổng thời gian cần thiết để nhập dữ liệu, hãy gửi các yêu cầu đồng thời đến IngestionService. Bạn nên gửi tối đa 10 yêu cầu cùng lúc để giảm khả năng vượt quá giới hạn số yêu cầu mỗi phút.

Bạn có thể gửi các yêu cầu đồng thời ngay cả khi các yêu cầu đó có cùng destinations.

Xác thực dữ liệu ở phía máy khách

Data Manager API sử dụng mô hình lỗi nhanh. Nếu có bản ghi nào trong một yêu cầu không vượt qua được bước xác thực đồng bộ, thì toàn bộ yêu cầu sẽ không thành công và không có bản ghi nào được xử lý. Ngoài ra, API xác thực các yêu cầu theo các lớp tuần tự, vì vậy, việc khắc phục một lỗi có thể cho thấy lỗi từ một lớp xác thực tiếp theo.

Để tránh việc lặp lại các yêu cầu khứ hồi và bị từ chối, hãy xác thực và dọn dẹp dữ liệu của bạn trước khi gửi:

• Xoá các giá trị trống trước khi băm: Kiểm tra các trường như email_address và phone_number để tìm các chuỗi trống hoặc chỉ có khoảng trắng trước khi tính toán hàm băm SHA-256. Việc băm một chuỗi trống sẽ tạo ra một hàm băm hợp lệ vượt qua các bước kiểm tra cú pháp nhưng lại làm giảm tỷ lệ khớp.

• Bỏ các đối tượng phức hợp chưa hoàn chỉnh: Đảm bảo các đối tượng phức hợp có tất cả các trường bắt buộc trước khi thêm chúng vào bản ghi. Ví dụ: nếu một đối tượng AddressInfo thiếu bất kỳ trường nào trong số 4 trường bắt buộc (given_name, family_name, region_code hoặc postal_code), hãy bỏ toàn bộ giá trị nhận dạng address để tránh lỗi REQUIRED_FIELD_MISSING.

• Xác thực các trường mã hoá và văn bản thuần tuý: Xác minh rằng các trường băm khớp với encoding đã khai báo thay vì gửi văn bản thuần tuý thô và đảm bảo các trường phải giữ nguyên văn bản thuần tuý (chẳng hạn như mobile_ids) không bị băm.

• Lọc dấu thời gian nằm ngoài phạm vi: Đảm bảo dấu thời gian không nằm trong tương lai hoặc cũ hơn giai đoạn xem lại lượt chuyển đổi của đích đến.

  Nếu bạn gửi yêu cầu bằng JSON, hãy đảm bảo chuỗi dấu thời gian sử dụng định dạng RFC 3339 có độ lệch múi giờ.

• Làm sạch số điện thoại: Xác minh rằng số điện thoại có mã quốc gia và sử dụng định dạng E.164 trước khi băm.

• Cắt bớt các bản ghi trống hoặc quá lớn: Giới hạn user_identifiers ở mức giới hạn cho mỗi bản ghi (10 giá trị nhận dạng), bỏ các tham số tuỳ chỉnh trống và bỏ qua mọi bản ghi không chứa giá trị nhận dạng hợp lệ.

• Xác minh các yêu cầu về trường hợp sử dụng: Đảm bảo mỗi sự kiện đều có tất cả các trường bắt buộc cho đích đến và trường hợp sử dụng (chẳng hạn như transaction_id cho lượt chuyển đổi trực tuyến trên Google Ads). Để xem danh sách đầy đủ các trường bắt buộc theo trường hợp sử dụng, hãy xem hướng dẫn gửi sự kiện cho đích đến của bạn trong phần Tổng quan về sự kiện.

• Sử dụng validateOnly để kiểm tra yêu cầu: Gửi yêu cầu có đặt validateOnly thành true để phát hiện lỗi không thành công nhanh mà không cần nhập hoặc xoá dữ liệu. Yêu cầu chỉ xác thực thành công không đảm bảo rằng sẽ không có lỗi trong quá trình xử lý không đồng bộ, vì vậy, hãy tiếp tục kiểm tra trạng thái yêu cầu và thông tin chẩn đoán sau khi gửi yêu cầu thông thường.

Để biết các quy tắc chuẩn hoá và băm chi tiết, hãy xem bài viết Định dạng dữ liệu người dùng.

Kiểm tra trạng thái yêu cầu và thông tin chẩn đoán

Ghi lại và thu thập request_id từ mỗi IngestAudienceMembersResponse hoặc IngestEventsResponse, đồng thời sử dụng mã yêu cầu để kiểm tra trạng thái yêu cầu và thông tin chẩn đoán.

Giám sát và cảnh báo về hạn mức

Để tránh bị từ chối yêu cầu ngoài dự kiến, hãy thiết lập cảnh báo và giám sát hạn mức trong Google Cloud Console. Việc theo dõi mức sử dụng hạn mức giúp bạn theo dõi các kiểu sử dụng và tối ưu hoá việc phân lô yêu cầu trước khi ứng dụng của bạn đạt đến giới hạn hằng ngày hoặc hằng phút.

Triển khai lên kênh phát hành công khai

Khi chuyển từ thử nghiệm cục bộ sang khối lượng công việc thực tế, hãy sử dụng Thông tin xác thực mặc định của ứng dụng có tài khoản dịch vụ đính kèm hoặc Workload Identity Federation để xác thực một cách an toàn và không tương tác.

Để biết thông tin chi tiết về cách định cấu hình quy trình xác thực cho các môi trường thực tế khác nhau, hãy xem bài viết Triển khai lên môi trường thực tế.