Diagnostik

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

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

  2. Periksa status keseluruhan setiap permintaan. Permintaan yang berhasil memiliki Status dengan code yang sama dengan 0 (nilai enum OK, HTTP respons 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 sehingga Anda dapat menggunakannya untuk mengambil diagnostik pada 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 baik dan mengidentifikasi masalah pada data Anda.

  5. Perbaiki masalah data.

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

Kirim permintaan

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

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

Berikut contoh waktu tunggu awal dan konfigurasi percobaan ulang yang wajar yang menyeimbangkan penggunaan kuota dan aktivitas:

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 urutan permintaan dan waktu yang berlalu dengan konfigurasi ini:

Grafik

Strategi Polling

Data

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

Tambahkan jitter dalam jumlah kecil dan acak ke penundaan backoff untuk mencegah masalah "kawanan guntur" saat banyak klien mencoba ulang secara bersamaan.

Tinjau respons

The request_status_per_destination dalam a 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 di request_status_per_destination (satu entri per audiens).

Periksa status tujuan keseluruhan

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

Berikut adalah nilai yang mungkin untuk 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 yang lain gagal karena error. Periksa error untuk menentukan alasan beberapa data gagal. Periksa juga peringatan yang ditandai selama pemrosesan.

Periksa status peristiwa atau audiens per tujuan

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

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 akan diperiksa untuk setiap jenis data audiens. Hanya satu 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 harapan Anda. Daftar ini memberikan perincian semua ID yang diterima (seperti alamat email, nomor telepon, alamat fisik dan alamat IP) berdasarkan DataType.

Jika permintaan memiliki jumlah data yang cukup, 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 data yang berhasil dan gagal.

Periksa google_user_id_count untuk mengonfirmasi bahwa jumlah ID pengguna Google yang diterima sesuai dengan harapan 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 ID seluler 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 harapan Anda. record_count mencakup data yang berhasil dan gagal.

Periksa pair_id_count untuk mengonfirmasi bahwa jumlah ID PAIR yang diterima sesuai dengan harapan 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 bahwa jumlah ID yang disediakan 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 harapan Anda.

user_data_ingestion_status

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

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

Jika permintaan memiliki jumlah data yang cukup, 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 total jumlah 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 harapan Anda.

Status penghapusan anggota audiens

Kolom audience_members_removal_status diisi jika permintaan adalah RemoveAudienceMembersRequest. Berikut kolom RemoveAudienceMembersStatus yang akan 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 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) berdasarkan DataType.

Periksa peringatan dan error

Selain kolom status untuk jenis tujuan dan permintaan, the 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.

Misalnya, jika Event berisi data terenkripsi UserIdentifier 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 kolom respons yang berisi informasi peringatan dan error. Kolom ini diisi saat status tujuan keseluruhan mencapai SUCCESS, PARTIAL_SUCCESS, atau FAILURE.

warning_info

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

Daftar objek ErrorCount. Setiap ErrorCount berisi reason dengan jenis error, dan record_count yang menunjukkan jumlah data yang gagal karena jenis error tersebut.