Un cliente in attesa di un codice percepisce accodamento, consegna, lettura e inserimento come un unico ritardo. Separa questi intervalli prima di stabilire se una registrazione lenta dipende dalla consegna del messaggio o dal flusso di verifica nel complesso.
Quali timestamp devo raccogliere?
Raccogli gli eventi del ciclo di vita di Verify tramite una sottoscrizione webhook. Salva i timestamp contenuti nel payload.
I payload degli eventi identificano queste fasi:
| Evento | Timestamp | Cosa registra |
|---|---|---|
verify.verification.created | created_at | La verifica è stata creata |
verify.attempt.sent | sent_at | Bird ha consegnato un codice di verifica a un canale |
verify.attempt.delivered | delivered_at | Il canale ha segnalato la consegna |
verify.attempt.undelivered | failed_at | Il tentativo con quel codice è fallito |
verify.verification.verified | verified_at | Il destinatario ha inviato il codice corretto |
verify.verification.failed | failed_at | Il piano di consegna non è riuscito a recapitare un codice |
Conserva il tipo di evento insieme a ogni timestamp. I due campi failed_at descrivono ambiti diversi: un singolo tentativo e il piano di consegna della verifica.
Deduplica le consegne usando webhook-id, che identifica un evento e resta stabile tra i retry. Usa timestamp del payload per ordinare gli eventi, perché l'ordine di consegna può variare.
Quale intervallo risponde alla mia domanda?
Usa sent-to-delivered per i tempi di consegna segnalati. Usa created-to-verified per i tempi di verifica completata.
| Intervallo | Cosa include |
|---|---|
created_at a sent_at | Tempo prima che il canale accetti un codice di verifica, inclusi eventuali fallimenti precedenti del canale |
sent_at a delivered_at | Elaborazione dopo l'accettazione del canale e intervallo di consegna segnalato |
created_at a verified_at | L'attesa completa, incluse lettura e inserimento del codice |
Un timestamp sent non indica sempre la sottomissione al carrier. Per SMS, il canale di Bird accetta il tentativo prima che la pipeline SMS a valle lo invii al carrier.
I report di consegna sono indicativi. Carrier e provider di posta differiscono in ciò che confermano e nella rapidità con cui lo segnalano.
Confronta lo stesso canale e mercato nel tempo. Le differenze tra paesi possono riflettere convenzioni di segnalazione oltre che la velocità di consegna.
Un evento verified conferma che il codice è stato ricevuto e usato. Il suo intervallo misura il completamento, non solo la consegna del messaggio.
Come associo gli eventi quando i codici vengono reinviati?
Raggruppa gli eventi per verification_id, canale e indirizzo del destinatario. Escludi le coppie che restano ambigue.
Gli eventi pubblici di Verify non contengono un identificatore di tentativo. Un reinvio o un cambio di canale crea un altro tentativo sotto lo stesso identificatore di verifica.
Un evento sent e il relativo evento delivered hanno valori webhook-id diversi. Quell'header deduplica gli eventi. Non collega le fasi di un tentativo.
L'ordine dei timestamp può separare sequenze semplici. Invii ripetuti allo stesso indirizzo sullo stesso canale possono sovrapporsi. Il solo ordinamento non dimostra quale consegna corrisponda.
Segna quei campioni come ambigui invece di assegnare una latenza precisa al tentativo. L'intervallo created-to-verified della verifica resta una misurazione separata.
Un canale non disponibile o limitato può fallire senza un evento sent. Richiedi sent_at prima di calcolare un intervallo sent-to-delivered.
Perché i miei dati possono differire dalla dashboard?
La dashboard può misurare un intervallo diverso. Può anche includere tentativi diversi rispetto al tuo report basato sugli eventi.
La dashboard misura il tempo dalla creazione del tentativo alla risoluzione per i tentativi qualificanti addebitati e consegnati. Esclude i timeout di consegna corretti da quel campione di latenza perché i loro tempi di risoluzione non sono consegne misurate.
La sua finestra di report usa il momento dell'addebito. Un report basato sugli eventi che usa il momento dell'invio può quindi includere un insieme diverso di tentativi.
La latenza memorizzata riflette lo stato di consegna al momento della lettura dell'addebito. Un aggiornamento di consegna successivo può lasciare quel campione invariato.
Un percentile è null quando non esistono campioni qualificanti. Mantieni questa distinzione invece di mostrare zero, che implicherebbe una consegna istantanea.
Confronta la stessa finestra di report prima di indagare una discrepanza. Usa gli eventi webhook quando la tua applicazione ha bisogno di un proprio intervallo e raggruppamento.
Come devo segnalare codici lenti e mancanti?
Riporta i tempi insieme ai tentativi non consegnati e alle verifiche non completate.
Un report di latenza che include solo i tentativi consegnati omette le persone i cui codici non sono mai arrivati. Mantieni quei fallimenti visibili accanto al riepilogo dei tempi.
L'evento verify.verification.failed copre i piani di consegna esauriti. La scadenza e l'esaurimento dei tentativi con codice errato non emettono quell'evento, quindi non è un conteggio completo di mancata conversione.
Traccia la creazione della verifica e il completamento riuscito nella tua applicazione. Tieni le sessioni non risolte separate invece di assegnare loro una durata di consegna inventata.
Suddividi i tentativi per canale e mercato del destinatario. Quando presenti, carrier e mcc_mnc identificano la rete di gestione. Entrambi sono null per email, WhatsApp e Telegram.
Un failover di canale può spiegare il codice in ritardo di un cliente. Esamina la sequenza dei tentativi prima di attribuire l'intero ritardo al tempo di consegna di un singolo canale.
In breve
Scegli l'intervallo di cui hai bisogno.
Il tempo di consegna segnalato e il tempo di verifica completata rispondono a domande diverse. Il completamento include la lettura e l'inserimento del codice.
Associa i tentativi con cautela.
Gli eventi identificano la verifica ma non ogni singolo tentativo. Invii ripetuti sullo stesso canale possono rendere l'associazione ambigua.
Mostra i fallimenti accanto al report di latenza.
Le sole consegne riuscite escludono i codici mai arrivati. Riporta separatamente i tentativi non consegnati e le verifiche incomplete.
Confronta traffico omogeneo.
I report di consegna variano per canale e mercato. Registra le regole di intervallo e campionamento prima di confrontare i percentili.