Verify

Hoe meet ik hoe lang mijn OTP's erover doen om aan te komen?

Vergelijk de sent- en delivered-timestamps van Verify voor de gerapporteerde bezorgtijd, en de created- en verified-timestamps voor de volledige verificatie-ervaring.

Een klant die op een code wacht, ervaart wachtrij, bezorging, lezen en invoeren als één vertraging. Scheid die intervallen voordat je besluit of een trage aanmelding aan berichtbezorging ligt of aan de bredere verificatiestroom.

Welke timestamps moet ik verzamelen?

Verzamel de Verify-lifecycle-events via een webhook-abonnement. Sla de timestamps uit hun payload op.

De event-payloads identificeren deze fasen:

EventTimestampWat het registreert
verify.verification.createdcreated_atDe verificatie is aangemaakt
verify.attempt.sentsent_atBird heeft een verificatiecode aan een kanaal overhandigd
verify.attempt.delivereddelivered_atHet kanaal heeft bezorging gerapporteerd
verify.attempt.undeliveredfailed_atDie verificatiecodepoging is mislukt
verify.verification.verifiedverified_atDe ontvanger heeft de juiste code ingediend
verify.verification.failedfailed_atHet bezorgplan kon geen code bezorgen

Bewaar het eventtype bij elke timestamp. De twee failed_at-velden beschrijven verschillende scopes: één poging en het bezorgplan van de verificatie.

Dedupliseer bezorgingen met webhook-id, dat een event identificeert en stabiel blijft bij retries. Gebruik timestamp uit de payload om events te ordenen, omdat de bezorgvolgorde kan veranderen.

Welk interval beantwoordt mijn vraag?

Gebruik sent-to-delivered voor gerapporteerde bezorgtiming. Gebruik created-to-verified voor voltooide verificatietiming.

IntervalWat het omvat
created_at tot sent_atTijd voordat het kanaal een verificatiecode accepteerde, mogelijk inclusief eerdere kanaalfouten
sent_at tot delivered_atVerwerking na kanaalacceptatie en het gerapporteerde bezorginterval
created_at tot verified_atDe volledige wachttijd, inclusief het lezen en invoeren van de code

Een sent-timestamp markeert niet altijd het moment van indienen bij de carrier. Bij SMS accepteert het kanaal van Bird de poging voordat de downstream SMS-pipeline deze bij de carrier indient.

Bezorgrapporten zijn indicatief. Carriers en mailboxproviders verschillen in wat ze bevestigen en hoe snel ze dat rapporteren.

Vergelijk hetzelfde kanaal en dezelfde markt over tijd. Verschillen tussen landen kunnen rapportageconventies weerspiegelen naast bezorgsnelheid.

Een verified-event bevestigt dat de code is ontvangen en gebruikt. Het interval meet voltooiing in plaats van alleen berichtbezorging.

Hoe koppel ik events wanneer codes opnieuw worden verzonden?

Groepeer events op verification_id, kanaal en ontvangersadres. Sluit paren uit die dubbelzinnig blijven.

De publieke events van Verify bevatten geen pogingsidentificatie. Een resend of kanaalwisseling maakt een nieuwe poging aan onder dezelfde verificatie-identificatie.

Een sent-event en het bijbehorende delivered-event hebben verschillende webhook-id-waarden. Die header dedupliseert events. Hij verbindt niet de fasen van een poging.

Timestampvolgorde kan eenvoudige reeksen scheiden. Herhaalde verzendingen naar hetzelfde adres op hetzelfde kanaal kunnen overlappen. Volgorde alleen bewijst niet welke bezorging erbij hoort.

Markeer die steekproeven als dubbelzinnig in plaats van een precieze pogingslatentie toe te kennen. Het created-to-verified-interval van de verificatie blijft een aparte meting.

Een niet-beschikbaar of beperkt kanaal kan falen zonder een sent-event. Vereist sent_at voordat je een sent-to-delivered-interval berekent.

Waarom kunnen mijn cijfers afwijken van het dashboard?

Het dashboard kan een ander interval meten. Het kan ook andere pogingen bevatten dan je eventrapport.

Het dashboard meet de tijd van pogingsaanmaak tot afhandeling voor kwalificerende gefactureerde, bezorgde pogingen. Het sluit gecorrigeerde bezorgtimeouts uit van die latentiesteekproef omdat hun afhandelingstijden geen gemeten bezorgingen zijn.

Het rapportagevenster gebruikt het factureringsmoment. Een eventgebaseerd rapport dat op verzendtijd filtert, kan daardoor een andere set pogingen bevatten.

De opgeslagen latentie weerspiegelt de bezorgstatus op het moment dat de facturering wordt gelezen. Een latere bezorgupdate kan die steekproef ongewijzigd laten.

Een percentiel is null als er geen kwalificerende steekproeven bestaan. Behoud dat onderscheid in plaats van nul te tonen, wat onmiddellijke bezorging zou impliceren.

Vergelijk hetzelfde rapportagevenster voordat je een discrepantie onderzoekt. Gebruik webhook-events wanneer je applicatie een eigen interval en groepering nodig heeft.

Hoe rapporteer ik trage en ontbrekende codes?

Rapporteer timing naast niet-bezorgde pogingen en verificaties die niet zijn voltooid.

Een latentierapport met alleen bezorgde pogingen laat de mensen weg wier codes nooit zijn aangekomen. Houd die fouten zichtbaar naast de timingsamenvatting.

Het verify.verification.failed-event dekt uitgeputte bezorgplannen. Verloop en uitputting van pogingen met een onjuiste code genereren dat event niet, dus het is geen volledige niet-conversietelling.

Houd verificatie-aanmaak en geslaagde voltooiing bij in je applicatie. Houd onafgehandelde sessies apart in plaats van er een verzonnen bezorgduur aan toe te kennen.

Splits pogingen uit per kanaal en ontvangermarkt. Wanneer gerapporteerd, identificeren carrier en mcc_mnc het verwerkende netwerk. Beide zijn null voor e-mail, WhatsApp en Telegram.

Een kanaalfailover kan de late code van een klant verklaren. Bekijk de pogingsreeks voordat je de hele vertraging behandelt als de bezorgtijd van één kanaal.

Kort gezegd

  1. Kies het interval dat je nodig hebt.

    Gerapporteerde bezorgtijd en voltooide verificatietijd beantwoorden verschillende vragen. Voltooiing omvat het lezen en invoeren van de code.

  2. Koppel pogingen voorzichtig.

    Events identificeren de verificatie, maar niet elke afzonderlijke poging. Herhaalde verzendingen op hetzelfde kanaal kunnen de koppeling dubbelzinnig maken.

  3. Houd fouten naast het latentierapport.

    Alleen geslaagde bezorgingen sluiten codes uit die nooit zijn aangekomen. Rapporteer niet-bezorgde en onvoltooide verificaties apart.

  4. Vergelijk vergelijkbaar verkeer.

    Bezorgrapporten verschillen per kanaal en markt. Leg je interval- en steekproefregels vast voordat je percentielen vergelijkt.

Bouw op hetzelfde netwerk.

Een test-API-key is direct beschikbaar. Productietoegang wordt ontgrendeld zodra u een betaalmethode toevoegt en een afzender verifieert.

Jouw volgende idee.
Klaar om te verbinden.