Verify

Bagaimana cara mengukur berapa lama OTP saya sampai ke penerima?

Bandingkan timestamp sent dan delivered dari Verify untuk waktu pengiriman yang dilaporkan, dan timestamp created dan verified untuk pengalaman verifikasi secara keseluruhan.

Pelanggan yang menunggu kode mengalami antrean, pengiriman, membaca, dan memasukkan kode sebagai satu keterlambatan. Pisahkan interval-interval tersebut sebelum memutuskan apakah pendaftaran yang lambat disebabkan oleh pengiriman pesan atau alur verifikasi secara keseluruhan.

Timestamp mana yang harus saya kumpulkan?

Kumpulkan event siklus hidup Verify melalui langganan webhook. Simpan timestamp dari payload-nya.

Payload event mengidentifikasi tahapan-tahapan berikut:

EventTimestampYang dicatat
verify.verification.createdcreated_atVerifikasi dibuat
verify.attempt.sentsent_atBird menyerahkan kode verifikasi ke channel
verify.attempt.delivereddelivered_atChannel melaporkan pengiriman
verify.attempt.undeliveredfailed_atPercobaan kode verifikasi tersebut gagal
verify.verification.verifiedverified_atPenerima mengirimkan kode yang benar
verify.verification.failedfailed_atRencana pengiriman tidak dapat mengirimkan kode

Simpan tipe event bersama setiap timestamp. Dua field failed_at menggambarkan cakupan yang berbeda: satu percobaan dan rencana pengiriman verifikasi.

Deduplikasi pengiriman menggunakan webhook-id, yang mengidentifikasi event dan tetap stabil saat percobaan ulang. Gunakan timestamp dari payload saat mengurutkan event, karena urutan pengiriman dapat berubah.

Interval mana yang menjawab pertanyaan saya?

Gunakan sent-to-delivered untuk waktu pengiriman yang dilaporkan. Gunakan created-to-verified untuk waktu verifikasi yang selesai.

IntervalYang termasuk
created_at ke sent_atWaktu sebelum channel menerima kode verifikasi, mungkin termasuk kegagalan channel sebelumnya
sent_at ke delivered_atPemrosesan setelah penerimaan channel dan interval pengiriman yang dilaporkan
created_at ke verified_atKeseluruhan waktu tunggu, termasuk membaca dan memasukkan kode

Timestamp sent tidak selalu menandai pengiriman ke operator. Untuk SMS, channel Bird menerima percobaan sebelum pipeline SMS hilir mengirimkannya ke operator.

Laporan pengiriman bersifat indikatif. Operator dan penyedia kotak surat berbeda dalam apa yang mereka konfirmasi dan seberapa cepat mereka melaporkannya.

Bandingkan channel dan pasar yang sama dari waktu ke waktu. Perbedaan antar negara dapat mencerminkan konvensi pelaporan selain kecepatan pengiriman.

Event verified mengonfirmasi bahwa kode telah diterima dan digunakan. Intervalnya mengukur penyelesaian, bukan pengiriman pesan saja.

Bagaimana cara memasangkan event saat kode dikirim ulang?

Kelompokkan event berdasarkan verification_id, channel, dan alamat penerima. Kecualikan pasangan yang tetap ambigu.

Event publik Verify tidak memiliki identifier percobaan. Pengiriman ulang atau pergantian channel membuat percobaan baru di bawah identifier verifikasi yang sama.

Event sent dan event delivered-nya memiliki nilai webhook-id yang berbeda. Header tersebut mendeduplikasi event. Header tersebut tidak menghubungkan tahapan-tahapan satu percobaan.

Urutan timestamp dapat memisahkan rangkaian sederhana. Pengiriman berulang ke alamat yang sama pada channel yang sama dapat tumpang tindih. Pengurutan saja tidak membuktikan pengiriman mana yang cocok.

Tandai sampel tersebut sebagai ambigu alih-alih menetapkan latensi percobaan yang tepat. Interval created-to-verified verifikasi tetap menjadi pengukuran terpisah.

Channel yang tidak tersedia atau dibatasi dapat gagal tanpa event sent. Pastikan sent_at ada sebelum menghitung interval sent-to-delivered.

Mengapa angka saya bisa berbeda dari dashboard?

Dashboard dapat mengukur interval yang berbeda. Dashboard juga dapat mencakup percobaan yang berbeda dari laporan event Anda.

Dashboard mengukur dari pembuatan percobaan hingga resolusi untuk percobaan berbayar dan terkirim yang memenuhi syarat. Dashboard mengecualikan timeout pengiriman yang dikoreksi dari sampel latensi tersebut karena waktu resolusinya bukan pengiriman yang terukur.

Jendela pelaporannya menggunakan waktu penagihan. Laporan berbasis event yang menggunakan waktu kirim dapat mencakup kumpulan percobaan yang berbeda.

Latensi yang tersimpan mencerminkan status pengiriman saat tagihan dibaca. Pembaruan pengiriman yang lebih baru dapat membiarkan sampel tersebut tidak berubah.

Persentil bernilai null jika tidak ada sampel yang memenuhi syarat. Pertahankan perbedaan tersebut alih-alih menampilkan nol, yang akan menyiratkan pengiriman instan.

Bandingkan jendela pelaporan yang sama sebelum menyelidiki ketidaksesuaian. Gunakan event webhook jika aplikasi Anda membutuhkan interval dan pengelompokan sendiri.

Bagaimana cara melaporkan kode yang lambat dan hilang?

Laporkan waktu bersama percobaan yang tidak terkirim dan verifikasi yang tidak selesai.

Laporan latensi yang hanya berisi percobaan yang terkirim mengabaikan orang yang kodenya tidak pernah sampai. Tampilkan kegagalan tersebut di samping ringkasan waktu.

Event verify.verification.failed mencakup rencana pengiriman yang habis. Kedaluwarsa dan habisnya percobaan kode yang salah tidak memicu event tersebut, sehingga bukan hitungan nonkonversi yang lengkap.

Lacak pembuatan verifikasi dan penyelesaian yang berhasil di aplikasi Anda. Pisahkan sesi yang belum terselesaikan alih-alih menetapkan durasi pengiriman yang dibuat-buat.

Pecah percobaan berdasarkan channel dan pasar penerima. Jika dilaporkan, carrier dan mcc_mnc mengidentifikasi jaringan yang menangani. Keduanya bernilai null untuk email, WhatsApp, dan Telegram.

Failover channel dapat menjelaskan keterlambatan kode pelanggan. Periksa urutan percobaan sebelum memperlakukan seluruh keterlambatan sebagai waktu pengiriman satu channel.

Singkatnya

  1. Pilih interval yang Anda butuhkan.

    Waktu pengiriman yang dilaporkan dan waktu verifikasi yang selesai menjawab pertanyaan yang berbeda. Penyelesaian mencakup membaca dan memasukkan kode.

  2. Pasangkan percobaan dengan hati-hati.

    Event mengidentifikasi verifikasi, bukan setiap percobaan. Pengiriman berulang pada channel yang sama dapat membuat pemasangan menjadi ambigu.

  3. Tampilkan kegagalan di samping laporan latensi.

    Pengiriman yang berhasil saja tidak mencakup kode yang tidak pernah sampai. Laporkan percobaan yang tidak terkirim dan verifikasi yang tidak selesai secara terpisah.

  4. Bandingkan trafik yang setara.

    Laporan pengiriman berbeda menurut channel dan pasar. Catat interval dan aturan sampel Anda sebelum membandingkan persentil.

Bangun di jaringan yang sama.

Kunci API uji coba langsung tersedia untuk Anda. Akses produksi terbuka saat Anda menambahkan metode pembayaran dan memverifikasi pengirim.

Ide Anda berikutnya.
Siap terhubung.