Klient czekający na kod odczuwa kolejkowanie, dostarczenie, odczytanie i wpisanie jako jedno opóźnienie. Rozdziel te interwały, zanim zdecydujesz, czy wolna rejestracja wynika z dostarczania wiadomości, czy z szerszego procesu weryfikacji.
Które znaczniki czasu powinienem zbierać?
Zbieraj zdarzenia cyklu życia Verify przez subskrypcję webhooków. Zapisuj znaczniki czasu z ich ładunków.
Ładunki zdarzeń identyfikują następujące etapy:
| Zdarzenie | Znacznik czasu | Co rejestruje |
|---|---|---|
verify.verification.created | created_at | Weryfikacja została utworzona |
verify.attempt.sent | sent_at | Bird przekazał kod weryfikacyjny do kanału |
verify.attempt.delivered | delivered_at | Kanał zgłosił dostarczenie |
verify.attempt.undelivered | failed_at | Ta próba dostarczenia kodu nie powiodła się |
verify.verification.verified | verified_at | Odbiorca przesłał poprawny kod |
verify.verification.failed | failed_at | Plan dostarczenia nie zdołał dostarczyć kodu |
Zachowuj typ zdarzenia przy każdym znaczniku czasu. Dwa pola failed_at opisują różne zakresy: pojedynczą próbę i plan dostarczenia weryfikacji.
Deduplikuj dostarczenia za pomocą webhook-id, który identyfikuje zdarzenie i pozostaje stały przy ponowieniach. Używaj timestamp z ładunku do porządkowania zdarzeń, ponieważ kolejność dostarczenia może się zmieniać.
Który interwał odpowiada na moje pytanie?
Używaj interwału sent-to-delivered do raportowania czasu dostarczenia. Używaj interwału created-to-verified do pomiaru zakończonej weryfikacji.
| Interwał | Co obejmuje |
|---|---|
created_at do sent_at | Czas przed przyjęciem kodu weryfikacyjnego przez kanał, potencjalnie obejmujący wcześniejsze błędy kanału |
sent_at do delivered_at | Przetwarzanie po przyjęciu przez kanał i raportowany interwał dostarczenia |
created_at do verified_at | Pełny czas oczekiwania, obejmujący odczytanie i wpisanie kodu |
Znacznik czasu sent nie zawsze oznacza przekazanie do operatora. W przypadku SMS kanał Bird przyjmuje próbę, zanim pipeline SMS prześle ją do operatora.
Raporty dostarczenia są orientacyjne. Operatorzy i dostawcy poczty różnią się w tym, co potwierdzają i jak szybko to raportują.
Porównuj ten sam kanał i rynek w czasie. Różnice między krajami mogą wynikać z konwencji raportowania, a nie tylko z prędkości dostarczenia.
Zdarzenie verified potwierdza, że kod został odebrany i użyty. Jego interwał mierzy zakończenie, a nie samo dostarczenie wiadomości.
Jak parować zdarzenia, gdy kody są ponownie wysyłane?
Grupuj zdarzenia według verification_id, kanału i adresu odbiorcy. Wykluczaj pary, które pozostają niejednoznaczne.
Publiczne zdarzenia Verify nie zawierają identyfikatora próby. Ponowna wysyłka lub zmiana kanału tworzy kolejną próbę w ramach tego samego identyfikatora weryfikacji.
Zdarzenie sent i odpowiadające mu zdarzenie delivered mają różne wartości webhook-id. Ten nagłówek deduplikuje zdarzenia. Nie łączy etapów jednej próby.
Kolejność znaczników czasu pozwala rozdzielić proste sekwencje. Powtórne wysyłki na ten sam adres na tym samym kanale mogą się nakładać. Samo porządkowanie nie dowodzi, które dostarczenie pasuje.
Oznacz te próbki jako niejednoznaczne zamiast przypisywać dokładne opóźnienie próby. Interwał created-to-verified weryfikacji pozostaje osobnym pomiarem.
Niedostępny lub ograniczony kanał może zawieść bez zdarzenia sent. Wymagaj sent_at przed obliczaniem interwału sent-to-delivered.
Dlaczego moje wyniki mogą się różnić od dashboardu?
Dashboard może mierzyć inny interwał. Może też obejmować inne próby niż raport oparty na zdarzeniach.
Dashboard mierzy czas od utworzenia próby do jej rozwiązania dla kwalifikujących się naliczonych, dostarczonych prób. Wyklucza skorygowane limity czasu dostarczenia z próbki opóźnień, ponieważ ich czasy rozwiązania nie są mierzonymi dostarczeniami.
Jego okno raportowania opiera się na czasie naliczenia. Raport oparty na zdarzeniach, który używa czasu wysyłki, może więc obejmować inny zbiór prób.
Zapisane opóźnienie odzwierciedla stan dostarczenia w momencie odczytu naliczenia. Późniejsza aktualizacja dostarczenia może pozostawić tę próbkę bez zmian.
Percentyl jest null, gdy nie ma kwalifikujących się próbek. Zachowaj to rozróżnienie zamiast wyświetlać zero, co sugerowałoby natychmiastowe dostarczenie.
Porównaj to samo okno raportowania, zanim zaczniesz badać rozbieżność. Używaj zdarzeń webhookowych, gdy aplikacja potrzebuje własnego interwału i grupowania.
Jak raportować wolne i brakujące kody?
Raportuj czas dostarczenia razem z niedostarczonymi próbami i weryfikacjami, które się nie zakończyły.
Raport opóźnień zawierający tylko dostarczone próby pomija osoby, których kody nigdy nie dotarły. Pokazuj te niepowodzenia obok podsumowania czasu.
Zdarzenie verify.verification.failed obejmuje wyczerpane plany dostarczenia. Wygaśnięcie i wyczerpanie prób z błędnym kodem nie emitują tego zdarzenia, więc nie jest to pełny licznik niekonwersji.
Śledź tworzenie i pomyślne zakończenie weryfikacji w swojej aplikacji. Sesje bez rozwiązania trzymaj osobno, zamiast przypisywać im wymyślony czas dostarczenia.
Rozbij próby według kanału i rynku odbiorcy. Gdy są raportowane, carrier i mcc_mnc identyfikują obsługującą sieć. Oba mają wartość null dla e-maila, WhatsApp i Telegrama.
Przełączenie kanału (failover) może wyjaśniać opóźniony kod klienta. Sprawdź sekwencję prób, zanim potraktujesz całe opóźnienie jako czas dostarczenia jednego kanału.
W skrócie
Wybierz potrzebny interwał.
Raportowany czas dostarczenia i czas zakończenia weryfikacji odpowiadają na różne pytania. Zakończenie obejmuje odczytanie i wpisanie kodu.
Ostrożnie paruj próby.
Zdarzenia identyfikują weryfikację, ale nie poszczególne próby. Powtórne wysyłki na tym samym kanale mogą powodować niejednoznaczne parowanie.
Pokazuj błędy obok raportu opóźnień.
Same udane dostarczenia pomijają kody, które nigdy nie dotarły. Raportuj niedostarczone i niekompletne weryfikacje osobno.
Porównuj porównywalny ruch.
Raporty dostarczenia różnią się w zależności od kanału i rynku. Zapisz interwał i reguły próbkowania przed porównywaniem percentyli.