Diagnostik

Berikut alur kerja yang direkomendasikan untuk memverifikasi kualitas upload acara dan audiens Anda serta mengidentifikasi masalah pada data Anda.

1. Mengirim permintaan untuk mengirim peristiwa atau mengirim atau menghapus anggota audiens.

2. Periksa status keseluruhan setiap permintaan. Permintaan yang berhasil memiliki Status dengan code sama dengan 0 (nilai enum OK, respons HTTP 200 OK), dan menampilkan IngestEventsResponse, IngestAudienceMembersResponse, atau RemoveAudienceMembersResponse.

   Jika permintaan tidak berhasil, ubah permintaan untuk mengatasi error dan kirim permintaan lagi.

   Jika permintaan berhasil, ambil request_id respons agar Anda dapat menggunakannya untuk mengambil diagnostik di langkah berikutnya.

3. Tunggu selama 30 menit, lalu kirim permintaan RetrieveRequestStatus untuk setiap request_id yang berhasil.

   Ulangi langkah ini secara berkala untuk setiap request_id hingga status tujuan untuk setiap tujuan mencapai SUCCESS, PARTIAL_SUCCESS, atau FAILURE. Gunakan algoritma backoff eksponensial untuk menunggu di antara setiap permintaan.

4. Tinjau setiap RetrieveRequestStatusResponse untuk mengonfirmasi bahwa upload Anda berfungsi dengan benar dan mengidentifikasi masalah apa pun pada data Anda.

5. Perbaiki masalah data.

6. Kembali ke langkah 1 dan ulangi hingga Anda mengatasi semua masalah terkait upload.

Kirim permintaan

RetrieveRequestStatusRequest memerlukan satu nilai request_id. Kirim permintaan status terpisah untuk setiap ID permintaan yang Anda ambil dari permintaan penyerapan yang berhasil.

Otorisasi

RetrieveRequestStatusRequest tidak menerima akun tujuan atau header permintaan. Sebagai gantinya, Data Manager API mengidentifikasi tujuan dari permintaan penyerapan asli yang terkait dengan request_id dan memverifikasi bahwa pemanggil memiliki akses ke operating_account di setiap Destination.

Untuk memeriksa status permintaan, kredensial yang digunakan dalam RetrieveRequestStatusRequest harus memenuhi persyaratan berikut untuk operating_account setiap tujuan dari permintaan penyerapan asli:

• Jalur akses yang identik: Kredensial harus memiliki akses ke setiap operating_account menggunakan jalur akses yang sama persis yang ditentukan dalam permintaan penyerapan asli.

  Misalnya, jika permintaan penyerapan untuk operating_account Google Ads menentukan akun pengelola induk sebagai login_account, kredensial juga harus memiliki akses ke operating_account melalui akun pengelola yang sama. Meskipun Akun Google yang terkait dengan kredensial memiliki akses langsung ke operating_account turunan, permintaan akan gagal dengan error PERMISSION_DENIED jika akun tersebut tidak memiliki akses melalui akun pengelola login_account yang ditentukan selama penyerapan.

• Tingkat akses yang memadai: Akun Google yang terkait dengan kredensial harus memiliki tingkat akses atau peran dengan izin untuk menyerap data ke dalam operating_account.

  Misalnya, di Google Ads, Akun Google harus memiliki tingkat akses Admin atau Standar. Permintaan dengan kredensial untuk akun dengan tingkat akses Hanya baca akan gagal dengan error PERMISSION_DENIED.

Strategi polling

Kirim RetrieveRequestStatusRequest secara berkala menggunakan algoritma backoff eksponensial hingga request_status mencapai SUCCESS, FAILURE, atau PARTIAL_SUCCESS untuk setiap tujuan dalam permintaan asli. Proses ini mungkin memerlukan waktu hingga 24 jam, meskipun Data Manager API mungkin selesai memproses beberapa permintaan hanya dalam waktu 30 menit.

Berikut adalah contoh konfigurasi waktu tunggu awal dan percobaan ulang yang wajar, yang menyeimbangkan keaktifan dan penggunaan kuota:

Setelan	Nilai
Waktu tunggu sebelum permintaan diagnostik pertama (menit)	30
Pengganda backoff	1.3
Backoff maksimum (menit)	60 (1 jam)
Waktu total maksimum (menit)	1440 (24 jam)

Berikut adalah urutan permintaan dan waktu yang berlalu dengan konfigurasi ini:

Tambahkan sejumlah kecil jitter acak ke penundaan backoff untuk mencegah masalah "thundering herd" saat banyak klien mencoba ulang secara bersamaan.

Tinjau respons

request_status_per_destination dalam RetrieveRequestStatusResponse berisi entri terpisah untuk setiap tujuan dalam permintaan penyerapan yang sesuai.

Misalnya, jika IngestAudienceMembersRequest Anda berisi 3 entri dalam daftar destinations untuk mengirim data ke 3 audiens yang berbeda, respons status akan berisi 3 entri dalam request_status_per_destination (satu entri per audiens).

Memeriksa status tujuan secara keseluruhan

Sebagai langkah pertama, periksa kolom request_status untuk menentukan apakah Data Manager API telah selesai memproses data untuk destination dari RequestStatusPerDestination.

Berikut adalah kemungkinan nilai request_status:

• PROCESSING: Data untuk tujuan masih diproses. Peringatan dan error tidak diisi untuk tujuan pada tahap ini.

• SUCCESS: Pemrosesan permintaan untuk tujuan selesai tanpa error. Periksa peringatan yang ditandai selama pemrosesan.

• FAILURE: Semua data untuk tujuan gagal karena error. Periksa peringatan dan error untuk menentukan alasan semua data gagal. Periksa juga peringatan yang ditandai selama pemrosesan.

• PARTIAL_SUCCESS: Beberapa data untuk tujuan berhasil, tetapi data lainnya gagal karena error. Periksa error untuk mengetahui alasan beberapa data gagal. Periksa juga peringatan yang ditandai selama pemrosesan.

Memeriksa status peristiwa atau audiens per tujuan

Periksa kolom status yang sesuai dengan jenis permintaan penyerapan. Hanya satu kolom berikut yang disetel di setiap RequestStatusPerDestination:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

Status penyerapan peristiwa

Kolom events_ingestion_status diisi jika permintaan adalah IngestEventsRequest.

Periksa record_count dari IngestEventStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

Status penyerapan anggota audiens

Kolom audience_members_ingestion_status diisi jika permintaan adalah IngestAudienceMembersRequest. Berikut kolom IngestAudienceMembersStatus yang harus diperiksa untuk setiap jenis data audiens. Hanya satu kolom ini yang ditetapkan.

composite_data_ingestion_status

Periksa record_countIngestCompositeDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

Periksa data_type_counts untuk mengonfirmasi bahwa jumlah ID sesuai dengan yang Anda harapkan. Daftar ini memberikan perincian semua ID yang diterima (seperti alamat email, nomor telepon, alamat fisik, dan alamat IP) oleh DataType.

Jika permintaan memiliki jumlah data yang memadai, upload_match_rate_range akan berisi rentang rasio kecocokan untuk data dalam permintaan.

google_user_id_data_ingestion_status

Periksa record_count dari IngestGoogleUserIdDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup record yang berhasil dan gagal.

Periksa google_user_id_count untuk mengonfirmasi bahwa jumlah ID pengguna Google yang diterima sesuai dengan ekspektasi Anda.

mobile_data_ingestion_status

Periksa record_countIngestMobileDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup record yang berhasil dan gagal.

Periksa mobile_id_count untuk mengonfirmasi bahwa jumlah Mobile ID yang diterima sesuai dengan ekspektasi Anda.

pair_data_ingestion_status

Periksa record_count dari IngestPairDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

Periksa pair_id_count untuk mengonfirmasi bahwa jumlah ID PAIR yang diterima sesuai dengan ekspektasi Anda.

partner_provided_id_data_ingestion_status

Periksa record_countIngestPartnerProvidedIdDataStatus untuk mengonfirmasi bahwa total jumlah data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

Periksa partner_provided_id_count untuk mengonfirmasi apakah jumlah ID yang diberikan partner yang diterima sesuai dengan harapan Anda.

ppid_data_ingestion_status

Periksa record_count dari IngestPpidDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

Periksa ppid_count untuk mengonfirmasi bahwa jumlah PPID yang diterima sesuai dengan ekspektasi Anda.

user_data_ingestion_status

Periksa record_count dari IngestUserDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan ekspektasi Anda. record_count mencakup data yang berhasil dan gagal.

Periksa user_identifier_count untuk mengonfirmasi bahwa jumlah ID pengguna yang diterima sesuai dengan ekspektasi Anda.

Jika permintaan memiliki jumlah data yang memadai, upload_match_rate_range akan berisi rentang rasio kecocokan untuk data dalam permintaan.

user_id_data_ingestion_status

Periksa record_countIngestUserIdDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

Periksa user_id_count untuk mengonfirmasi bahwa jumlah ID pengguna yang diterima sesuai dengan ekspektasi Anda.

Status penghapusan anggota audiens

Kolom audience_members_removal_status diisi jika permintaan adalah RemoveAudienceMembersRequest. Berikut kolom RemoveAudienceMembersStatus yang harus diperiksa untuk setiap jenis data audiens. Hanya satu kolom ini yang ditetapkan.

composite_data_removal_status

Status penghapusan untuk Data gabungan

google_user_id_data_removal_status

Status penghapusan untuk data ID pengguna Google

mobile_data_removal_status

Status penghapusan untuk data seluler.

pair_data_removal_status

Status penghapusan untuk data PAIR.

partner_provided_id_data_removal_status

Status penghapusan untuk Data ID yang disediakan partner

ppid_data_removal_status

Status penghapusan untuk data PPID.

user_data_removal_status

Status penghapusan untuk data pengguna.

user_id_data_removal_status

Status penghapusan untuk data ID Pengguna

Periksa record_count untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup record yang berhasil dan gagal.

Selain itu, periksa user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count, atau partner_provided_id_count untuk mengonfirmasi jumlah total ID yang diterima.

Untuk data gabungan, periksa data_type_counts untuk mengonfirmasi bahwa jumlah ID sesuai dengan harapan Anda. Daftar ini memberikan perincian semua ID yang diterima (seperti alamat email, nomor telepon, alamat fisik, dan alamat IP) menurut DataType.

Memeriksa peringatan dan error

Selain kolom status untuk tujuan dan jenis permintaan, RetrieveRequestStatusResponse berisi perincian peringatan dan error untuk permintaan.

• Error menunjukkan bahwa API menolak sepenuhnya rekaman.
• Peringatan menunjukkan bahwa API tidak menolak data, tetapi harus mengabaikan sebagian data catatan.

Misalnya, jika Event berisi data UserIdentifier terenkripsi dan AdIdentifiers seperti gclid, dan data UserIdentifier tidak dapat didekripsi, Data Manager API tetap memproses rekaman menggunakan AdIdentifiers, tetapi menampilkan peringatan PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Namun, jika Event tidak berisi AdIdentifiers dan data UserIdentifier tidak dapat didekripsi, Data Manager API akan menolak seluruh rekaman dan melaporkan error PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR karena Event yang valid harus memiliki setidaknya salah satu dari ad_identifiers atau user_data.

Berikut adalah kolom respons yang berisi informasi peringatan dan error. Kolom ini diisi saat status keseluruhan tujuan mencapai SUCCESS, PARTIAL_SUCCESS, atau FAILURE.

warning_info

Objek WarningInfo. Kolom warning_counts-nya berisi daftar objek WarningCount. Setiap WarningCount berisi reason dengan jenis peringatan, dan record_count yang menunjukkan jumlah data yang memiliki jenis peringatan tersebut.

Periksa warning_info meskipun status tujuan keseluruhan adalah SUCCESS.

error_info

Objek ErrorInfo. Kolom error_counts-nya berisi daftar objek ErrorCount. Setiap ErrorCount berisi reason dengan jenis error, dan record_count yang menunjukkan jumlah data yang gagal karena jenis error tersebut.