Diagnostik

Berikut alur kerja yang direkomendasikan untuk memverifikasi kualitas upload peristiwa 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 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 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.

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 dapat menyelesaikan pemrosesan beberapa permintaan dalam waktu 30 menit.

Berikut contoh waktu tunggu awal dan konfigurasi 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

Strategi Polling

Data

Upaya Waktu Sejak Permintaan Penyerapan (jj:mm) Penundaan Sebelum Percobaan Catatan
1 00:30 30,0 mnt Pertama, periksa 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 sedikit jitter acak ke penundaan penghentian untuk mencegah masalah "kawanan guntur" 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 keseluruhan tujuan

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 ada error. Periksa peringatan yang ditandai selama pemrosesan.

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

  • PARTIAL_SUCCESS: Beberapa catatan untuk tujuan berhasil, tetapi yang lain gagal karena error. Periksa error untuk menentukan 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 ditetapkan di setiap RequestStatusPerDestination:

Status penyerapan peristiwa

Kolom events_ingestion_status diisi jika permintaan adalah IngestEventsRequest.

Periksa record_count IngestEventStatus untuk mengonfirmasi bahwa jumlah total data yang diterima sesuai dengan harapan Anda. record_count mencakup catatan 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.

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 ekspektasi Anda.

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

mobile_data_ingestion_status

Periksa record_countIngestMobileDataStatus 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 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.

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_id_data_ingestion_status

Periksa record_count dari IngestUserIdDataStatus 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.

user_data_removal_status
Status penghapusan untuk data pengguna.
mobile_data_removal_status
Status penghapusan untuk data seluler.
pair_data_removal_status
Status penghapusan untuk data PAIR.
ppid_data_removal_status
Status penghapusan untuk data PPID.
user_id_data_removal_status
Status penghapusan untuk data ID Pengguna

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

Selain itu, periksa user_identifier_count, mobile_id_count, atau pair_id_count untuk mengonfirmasi jumlah total ID pengguna, ID seluler, atau ID PAIR yang diterima.

Periksa 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 data.
  • Peringatan menunjukkan bahwa API tidak menolak data, tetapi harus mengabaikan sebagian data catatan.

Misalnya, jika Event untuk konversi offline Google Ads berisi data terenkripsi UserIdentifier 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 data dan melaporkan error PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR karena Event konversi offline Google Ads 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 FAILURE.

warning_info

Daftar objek WarningCount. Setiap WarningCount berisi reason dengan jenis peringatan, dan record_count yang menunjukkan jumlah catatan yang memiliki jenis peringatan tersebut.

Periksa warning_info meskipun status tujuan secara 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.