Mest mottagliga användare

Den här rapporten är en sammanställning av mottagligheten per användare under 12 månader: en rad per person som har fått minst en simulering under det senaste året, med antal och andelar för klick, inloggningsuppgifter och rapporteringar, en aktuell klickserie samt en sammanfogad lista över de fem senaste resultaten. Tidsfönstret är 12 kalendermånader (midnatt UTC samma dag i månaden tolv månader tillbaka), inte en period på 365 dagar. Konfiguration, autentiseringsuppgifter, paginering och återförsök vid hastighetsbegränsning är desamma som i anslutningsguiden för Power BI / Excel. Lägg först till den delade frågan Fn_FetchAll. Den här rapporten anropar den vid namn.

​

Nödvändiga nyckelbehörigheter

Den här rapporten använder den operativa resultatlistan per person, inte familjen av förhandsgranskningar för rapportering. En nyckel som endast har beviljats reporting:read kan inte anropa GET /v1/simulation_results (API:et returnerar 403). Se välj rätt detaljnivå.

​

Källändpunkter

Tillåtna filter i resultatlistan: limit, page_token, simulation, entity. Den här listan har ingen delivered_after / start_date, så de senaste 12 månaderna tillämpas i Power Query efter att hela listan har hämtats. Fält som används för varje resultat: 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.

​

Detaljnivå

En rad per entitet som har minst ett resultat med delivered_at under de senaste 12 kalendermånaderna. En person som har varit måltavla men aldrig fått något levererat visas inte. Flera simuleringar för samma person slås samman här. Förfrågningsbudget: en paginerad genomgång av alla simuleringsresultat i organisationen, plus en genomgång av entiteter. Ange alltid limit = "500".

​

Resultatprioritet (last_5_assessments)

Vart och ett av de fem senast levererade resultaten (delivered_at i fallande ordning) sammanfattas som YYYY-MM-DD: <outcome>. Den första matchande tidsstämpeln gäller, med högsta prioritet först: Enbart levererat är no action (meddelandet kom fram, men personen gjorde ingenting). En person som klickade och senare rapporterade är clicked. Rapportering väger inte tyngre än en riskfylld interaktion i den här listan. Rader som har flaggats som bot får ändå en resultatetikett utifrån de tidsstämplar som finns, men de räknas inte in i antalet klick eller inloggningsuppgifter. Aktuell klickserie: gå igenom samma levererade resultat med de nyaste först och räkna på varandra följande rader där clicked_at inte är null och bot_activity_detected inte är true. Sluta vid första raden som inte uppfyller villkoret.

​

Kolumnmappning

Namnen på de äldre kolumnerna kommer från din tidigare leverantörs export. /v1-fälten är de offentliga API-namnen. Frågan härleder antal och andelar. Kopplingsnyckel som behålls för en stjärnschemamodell: entity_id.

​

Avvikelser från den äldre exporten

• Botaktivitet undantas från antalet klick och inloggningsuppgifter. En tidigare leverantörs export räknade interaktioner från automatiska skannrar och botar som klick och inloggningsuppgifter. Den här frågan gör inte det. Ett resultat med bot_activity_detected = true är fortfarande en levererad simulering – det räknas i total_received och i de aggregerade rapporteringarna – men det behandlas som ett icke-klick och en icke-inskickning: det utelämnas från clicks / credential_submissions och det bryter en aktuell klickserie. “Åtgärda” inte detta genom att räkna med botar för att matcha den äldre exporten.
• Rapportering väger inte tyngre än ett klick på last_5_assessments. En person som klickade och senare rapporterade får etiketten clicked.
• Katalogtillägg utelämnas, anges inte som null. Avdelning och liknande fält finns inte i /v1.
• Inget tidsfilter på serversidan. GET /v1/simulation_results har ingen delivered_after. Frågan går igenom alla resultat och behåller sedan delivered_at under de senaste 12 kalendermånaderna. En stor organisation med lång historik kan förbruka mer av budgeten för hastighetsbegränsning per nyckel än en filtrerad lista skulle göra.

​

Nästa steg