Najbardziej podatni użytkownicy

Ten raport to zestawienie podatności na poziomie poszczególnych użytkowników z ostatnich 12 miesięcy: jeden wiersz na każdą osobę, która w ciągu ostatniego roku otrzymała co najmniej jedną symulację, wraz z liczbą i odsetkiem kliknięć, podanych poświadczeń i zgłoszeń, bieżącą serią kliknięć oraz połączoną listą wyników z ostatnich 5 symulacji. Okno czasowe obejmuje 12 miesięcy kalendarzowych (północ UTC w tym samym dniu miesiąca dwanaście miesięcy wcześniej), a nie okres 365 dni. Konfiguracja, poświadczenia, stronicowanie i ponawianie po przekroczeniu limitu żądań są takie same jak w przewodniku po łączności z Power BI / Excel. Najpierw dodaj wspólne zapytanie Fn_FetchAll; ten raport wywołuje je po nazwie.

​

Wymagane zakresy klucza

Ten raport korzysta z operacyjnej listy wyników na poziomie poszczególnych osób, a nie z rodziny podglądów raportowych. Klucz z uprawnieniem wyłącznie reporting:read nie może wywołać GET /v1/simulation_results (API zwraca 403). Zobacz wybór odpowiedniego poziomu szczegółowości.

​

Punkty końcowe źródła

Filtry dozwolone na liście wyników: limit, page_token, simulation, entity. Na tej liście nie ma delivered_after / start_date, więc ostatnie 12 miesięcy jest stosowane w Power Query po pobraniu wszystkich danych. Pola używane w każdym wyniku: id, simulation, entity, status, targeted_at, delivered_at, bounced_at, opened_at, clicked_at, attachment_opened_at, credential_submitted_at, reported_at, reported_before_interaction, bot_activity_detected, email_subject, sender_email, difficulty_level, created_at, updated_at.

​

Poziom szczegółowości

Jeden wiersz na każdą encję, która ma co najmniej jeden wynik z delivered_at w ciągu ostatnich 12 miesięcy kalendarzowych. Osoba, która była celem, ale nie otrzymała wiadomości, nie pojawia się w raporcie. Wiele symulacji dla tej samej osoby jest tu zagregowanych w jeden wiersz. Budżet żądań: jedno stronicowane przejście przez wszystkie wyniki symulacji w organizacji oraz jedno przejście przez encje. Zawsze ustawiaj limit = "500".

​

Pierwszeństwo wyników (last_5_assessments)

Każdy z pięciu ostatnich dostarczonych wyników (delivered_at malejąco) jest podsumowywany jako YYYY-MM-DD: <outcome>. Wygrywa pierwszy pasujący znacznik czasu, zaczynając od najwyższego priorytetu: Wynik „tylko dostarczono” to no action (wiadomość dotarła, a osoba nic nie zrobiła). Osoba, która kliknęła, a później zgłosiła wiadomość, ma wynik clicked — na tej liście zgłoszenie nie ma pierwszeństwa przed ryzykowną interakcją. Wiersze oznaczone jako boty nadal otrzymują etykietę wyniku na podstawie obecnych znaczników czasu; po prostu nie zwiększają liczby kliknięć ani podanych poświadczeń. Bieżąca seria kliknięć: przejdź przez te same dostarczone wyniki od najnowszego i policz kolejne wiersze, w których clicked_at ma wartość inną niż null oraz bot_activity_detected nie jest true. Zatrzymaj się na pierwszym niespełniającym warunku.

​

Mapowanie kolumn

Nazwy kolumn starego systemu pochodzą z eksportu poprzedniego dostawcy. Pola /v1 to publiczne nazwy API; zapytanie wylicza liczby i odsetki. Klucz złączenia zachowany na potrzeby modelu gwiazdy: entity_id.

​

Różnice względem eksportu ze starego systemu

• Aktywność botów jest wyłączona z liczby kliknięć i podanych poświadczeń. Eksport poprzedniego dostawcy liczył interakcje automatycznych skanerów i botów jako kliknięcia i podanie poświadczeń. To zapytanie tego nie robi. Wynik z bot_activity_detected = true nadal jest dostarczoną symulacją — jest wliczany do total_received oraz do zagregowanych zgłoszeń — ale jest traktowany jako brak kliknięcia i brak podania poświadczeń: jest pomijany w clicks / credential_submissions i przerywa bieżącą serię kliknięć. Nie „naprawiaj” tego, wliczając boty w celu dopasowania do eksportu ze starego systemu.
• Zgłoszenie nie ma pierwszeństwa przed kliknięciem w last_5_assessments. Osoba, która kliknęła, a później zgłosiła wiadomość, otrzymuje etykietę clicked.
• Dodatkowe dane katalogowe są pomijane, a nie ustawiane na null. Dział i podobne pola nie występują w /v1.
• Brak filtra czasu po stronie serwera. GET /v1/simulation_results nie ma delivered_after. Zapytanie przechodzi przez wszystkie wyniki, a następnie zachowuje delivered_at z ostatnich 12 miesięcy kalendarzowych. Duża organizacja z długą historią może zużyć większą część budżetu limitu żądań przypadającego na klucz niż w przypadku listy z filtrem.

​

Następne kroki