Memeriksa status permintaan dan diagnostik

Permintaan untuk mengirim peristiwa atau anggota audiens diproses secara asinkron. Respons penyerapan yang berhasil akan menampilkan request_id dan menunjukkan bahwa permintaan memenuhi semua persyaratan dan diterima untuk diproses. Namun, kode ini tidak menunjukkan apakah data dalam permintaan berhasil diproses.

Gunakan request_id yang ditampilkan dengan RetrieveRequestStatus untuk memeriksa status upload dan meninjau diagnostik.

Berikut alur kerja yang direkomendasikan untuk memeriksa status permintaan Anda dan memverifikasi kondisi upload peristiwa dan audiens Anda:

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

2. Memeriksa status keseluruhan setiap permintaan penyerapan. 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 memeriksa status pemrosesan di langkah berikutnya.

   Catatan: Anda hanya dapat memeriksa status dan mengambil diagnostik untuk permintaan yang berhasil dan tidak memiliki validate_only yang ditetapkan ke true.

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

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

   Tips: Coba permintaan di browser Anda menggunakan API Explorer.

   Ulangi langkah ini secara berkala untuk setiap request_id hingga status tujuan untuk setiap tujuan mencapai SUCCESS, PARTIAL_SUCCESS, atau FAILED. Ikuti strategi polling yang direkomendasikan untuk menunggu di antara setiap permintaan.

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

5. Perbaiki masalah data.

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

Memeriksa status tujuan secara keseluruhan

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).

Periksa kolom request_status di setiap RequestStatusPerDestination untuk menentukan apakah Data Manager API telah selesai memproses data untuk tujuan tersebut.

Berikut adalah kemungkinan nilai request_status:

• PROCESSING: Data untuk tujuan masih diproses. Peringatan dan error tidak diisi untuk tujuan pada tahap ini. Lanjutkan polling hingga status mencapai status terminal.

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

• FAILED: 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 yang lain gagal karena error. Periksa error untuk mengetahui alasan beberapa data gagal. Periksa juga peringatan yang ditandai selama pemrosesan.

Tinjau diagnostik

Setelah request_status untuk tujuan mencapai SUCCESS, FAILED, atau PARTIAL_SUCCESS, tinjau diagnostik mendetail dalam respons untuk memverifikasi jumlah dan memecahkan masalah.

Memeriksa status peristiwa atau audiens per tujuan

Periksa kolom status yang sesuai dengan jenis permintaan penyerapan. Hanya satu dari kolom berikut yang ditetapkan 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 dari kolom ini yang ditetapkan.

composite_data_ingestion_status

Periksa record_count dari IngestCompositeDataStatus 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 ekspektasi Anda. 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 ekspektasi Anda. record_count mencakup data 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_count dari IngestMobileDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup data yang berhasil dan gagal.

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

pair_data_ingestion_status

Periksa record_count dari IngestPairDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan ekspektasi 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_count dari IngestPartnerProvidedIdDataStatus untuk mengonfirmasi bahwa jumlah total 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 ekspektasi 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_count dari IngestUserIdDataStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan ekspektasi 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 dari 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 diberikan 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 ekspektasi Anda. record_count mencakup data 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) oleh 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 sepenuhnya menolak data.

• Peringatan menunjukkan bahwa API tidak menolak data, tetapi harus mengabaikan sebagian data dari data tersebut.

Misalnya, jika Event berisi data UserIdentifier terenkripsi dan AdIdentifiers seperti gclid, dan data UserIdentifier tidak dapat didekripsi, Data Manager API akan tetap memproses data 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 data 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 tujuan keseluruhan mencapai SUCCESS, PARTIAL_SUCCESS, atau FAILED.

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.

Strategi polling

Kirim RetrieveRequestStatusRequest secara berkala menggunakan algoritma backoff eksponensial hingga request_status mencapai SUCCESS, FAILED, atau PARTIAL_SUCCESS untuk setiap tujuan dalam permintaan awal. 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)
Total waktu maksimum (menit)	1440 (24 jam)

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

Grafik

Data

Upaya	Waktu Sejak Permintaan Penyerapan (jj.mm)	Penundaan Sebelum Percobaan	Catatan
1	00:30	30,0 mnt	Pemeriksaan awal untuk ketersediaan status
2	01:09	39,0 mnt
3	01.59	50,7 mnt
4	02:59	60,0 mnt	Penundaan kini dibatasi hingga 1 jam
5	03:59	60,0 mnt
6	04:59	60,0 mnt
7	05:59	60,0 mnt
8	06:59	60,0 mnt
9	07:59	60,0 mnt
10	08:59	60,0 mnt
11	09:59	60,0 mnt
12	10:59	60,0 mnt
13	11:59	60,0 mnt	Tanda 12 jam
14	12:59	60,0 mnt
15	13:59	60,0 mnt
16	14:59	60,0 mnt
17	15:59	60,0 mnt
18	16:59	60,0 mnt
19	17:59	60,0 mnt
20	18:59	60,0 mnt
21	19:59	60,0 mnt
22	20:59	60,0 mnt
23	21:59	60,0 mnt
24	22:59	60,0 mnt
25	23.59	60,0 mnt	Permintaan terakhir sebelum total waktu maksimum 24 jam

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

Persyaratan 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 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.