Praktik terbaik

Perhatikan praktik terbaik berikut saat menggunakan Data Manager API.

Mengirim semua ID pengguna

Baik saat mengirim anggota audiens atau peristiwa dengan UserData, sertakan sebanyak mungkin user_identifiers, termasuk mengirim beberapa ID dari jenis yang sama.

Misalnya, jika Anda memiliki beberapa alamat email untuk satu pengguna, sertakan UserIdentifier terpisah untuk setiap alamat email. Demikian pula, jika Anda memiliki ID dari berbagai jenis untuk pengguna, seperti alamat email, nomor telepon, dan alamat, tambahkan UserIdentifier terpisah untuk setiap ID, hingga jumlah ID maksimum.

Mengoptimalkan permintaan

Untuk mengurangi kemungkinan terlampauinya batas permintaan harian, buat batch sebanyak mungkin item dalam setiap permintaan, hingga batas per permintaan.

Misalnya, jika Anda ingin menambahkan 10.000 anggota audiens ke audiens, tambahkan semua 10.000 anggota dalam daftar audience_members dalam satu IngestAudienceMembersRequest. Mengelompokkan 10.000 anggota dalam satu permintaan lebih efisien daripada mengirim permintaan terpisah untuk menambahkan setiap anggota audiens.

Mengirim permintaan serentak

Untuk mengurangi keseluruhan waktu yang diperlukan untuk menyerap data, kirim permintaan serentak ke IngestionService. Sebaiknya kirim hingga 10 permintaan secara serentak untuk mengurangi kemungkinan melampaui batas permintaan per menit.

Anda dapat mengirim permintaan serentak meskipun permintaan tersebut memiliki destinations yang sama.

Memvalidasi data di sisi klien

Data Manager API menggunakan model fast-fail. Jika ada data dalam permintaan yang gagal dalam validasi sinkron, seluruh permintaan akan gagal dan tidak ada data yang diproses. Selain itu, API memvalidasi permintaan dalam lapisan berurutan, sehingga memperbaiki satu error mungkin akan menampilkan error dari lapisan validasi berikutnya.

Untuk menghindari perjalanan bolak-balik yang berulang dan permintaan yang ditolak, validasi dan bersihkan data Anda sebelum mengirimkannya:

• Hapus nilai kosong sebelum melakukan hashing: Periksa kolom seperti email_address dan phone_number untuk string kosong atau hanya berisi spasi kosong sebelum menghitung hash SHA-256. Melakukan hashing pada string kosong akan menghasilkan hash valid yang lulus pemeriksaan sintaksis, tetapi menurunkan rasio kecocokan.

• Menghapus objek gabungan yang tidak lengkap: Pastikan objek gabungan memiliki semua kolom wajib diisi sebelum menambahkannya ke data. Misalnya, jika objek AddressInfo tidak memiliki salah satu dari empat kolom wajib diisi (given_name, family_name, region_code, atau postal_code), hapus seluruh ID address untuk menghindari error REQUIRED_FIELD_MISSING.

• Validasi kolom encoding dan teks biasa: Pastikan kolom yang di-hash cocok dengan encoding yang dideklarasikan, bukan mengirim teks biasa mentah, dan pastikan kolom yang harus tetap berupa teks biasa (seperti mobile_ids) tidak di-hash.

• Filter stempel waktu di luar batas: Pastikan stempel waktu tidak berada di masa mendatang atau lebih lama dari periode lihat balik konversi tujuan.

  Jika Anda mengirim permintaan menggunakan JSON, pastikan string stempel waktu menggunakan format RFC 3339 dengan selisih zona waktu.

• Bersihkan nomor telepon: Pastikan nomor telepon menyertakan kode negara dan menggunakan format E.164 sebelum di-hash.

• Pangkas data kosong atau terlalu besar: Batasi user_identifiers pada batas per data (10 ID), hapus parameter kustom yang kosong, dan hapus data apa pun yang tidak berisi ID yang valid.

• Verifikasi persyaratan kasus penggunaan: Pastikan setiap peristiwa menyertakan semua kolom wajib diisi untuk tujuan dan kasus penggunaannya (seperti transaction_id untuk konversi online Google Ads). Untuk mengetahui daftar lengkap kolom wajib diisi berdasarkan kasus penggunaan, lihat panduan mengirim peristiwa untuk tujuan Anda di Ringkasan peristiwa.

• Gunakan validateOnly untuk menguji permintaan: Kirim permintaan dengan validateOnly ditetapkan ke true untuk menangkap error fast-fail tanpa menyerap atau menghapus data. Permintaan khusus validasi yang berhasil tidak menjamin tidak akan ada error selama pemrosesan asinkron, jadi terus periksa status permintaan dan diagnostik setelah mengirim permintaan reguler.

Untuk mengetahui aturan normalisasi dan hashing yang mendetail, lihat Memformat data pengguna.

Memeriksa status permintaan dan diagnostik

Ambil dan kumpulkan request_id dari setiap IngestAudienceMembersResponse atau IngestEventsResponse, dan gunakan ID permintaan untuk memeriksa status permintaan dan diagnostik.

Memantau dan memberi tahu kuota

Untuk menghindari penolakan permintaan yang tidak terduga, siapkan peringatan kuota dan pemantauan di Konsol Google Cloud. Pemantauan penggunaan kuota membantu Anda melacak pola konsumsi dan mengoptimalkan pengelompokan permintaan sebelum aplikasi Anda mencapai batas harian atau per menit.

Men-deploy ke produksi

Saat beralih dari pengujian lokal ke workload produksi, gunakan Kredensial Default Aplikasi dengan akun layanan terlampir atau Workload Identity Federation untuk melakukan autentikasi secara non-interaktif dan aman.

Untuk mengetahui detail tentang cara mengonfigurasi autentikasi untuk berbagai lingkungan produksi, lihat Men-deploy ke produksi.