Mest modtagelige brugere

Denne rapport er en 12-måneders opgørelse over modtagelighed pr. bruger: én række for hver person, der har modtaget mindst én simulering i det seneste år, med antal og andele for klik, legitimationsoplysninger og rapporteringer, en aktuel klikserie og en sammenkædet liste over de seneste 5 resultater. Perioden er 12 kalendermåneder (midnat UTC på samme dag i måneden tolv måneder tilbage), ikke en varighed på 365 dage. Opsætning, legitimationsoplysninger, paginering og genforsøg ved hastighedsbegrænsning er de samme som i vejledningen til Power BI/Excel-forbindelse. Tilføj først den delte Fn_FetchAll-forespørgsel; denne rapport kalder den ved navn.

​

Påkrævede nøgleomfang

Denne rapport bruger den operationelle resultatliste pr. person, ikke familien af rapporteringsforhåndsvisninger. En nøgle, der kun har fået tildelt reporting:read, kan ikke kalde GET /v1/simulation_results (API’en returnerer 403). Se vælg det rette granularitetsniveau.

​

Kildeendepunkter

Tilladte filtre på resultatlisten: limit, page_token, simulation, entity. Der er ingen delivered_after/start_date på denne liste, så de seneste 12 måneder anvendes i Power Query efter gennemløbet af hele listen. Felter, der bruges på hvert 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.

​

Granularitet

Én række pr. entitet, der har mindst ét resultat med delivered_at i de seneste 12 kalendermåneder. En person, der er målrettet, men aldrig har fået leveret en simulering, vises ikke. Flere simuleringer for den samme person samles her i én række. Anmodningsbudget: ét pagineret gennemløb af alle simuleringsresultater i organisationen plus ét gennemløb af entiteter. Angiv altid limit = "500".

​

Resultatprioritet (last_5_assessments)

Hvert af de fem seneste leverede resultater (delivered_at faldende) opsummeres som YYYY-MM-DD: <outcome>. Det første matchende tidsstempel gælder, med højeste prioritet først: Kun leveret er no action (meddelelsen nåede frem; personen gjorde ingenting). En person, der klikkede og senere rapporterede, er clicked – en rapportering vejer ikke tungere end en risikabel interaktion på denne liste. Rækker, der er markeret som bot, får stadig en resultatetiket ud fra de tidsstempler, der findes; de tæller blot ikke med i antallet af klik og legitimationsoplysninger. Aktuel klikserie: gennemgå de samme leverede resultater med de nyeste først, og tæl på hinanden følgende rækker, hvor clicked_at ikke er null og bot_activity_detected ikke er true. Stop ved det første brud.

​

Kolonnetilknytning

Navnene på de tidligere kolonner stammer fra din tidligere udbyders eksport. /v1-felter er de offentlige API-navne; forespørgslen udleder antal og andele. Sammenkædningsnøgle bevaret til en stjerneskemamodel: entity_id.

​

Afvigelser fra den tidligere eksport

• Botaktivitet er udeladt fra antallet af klik og legitimationsoplysninger. En tidligere udbyders eksport talte automatiserede interaktioner fra scannere/bots som klik og indsendelser af legitimationsoplysninger. Det gør denne forespørgsel ikke. Et resultat med bot_activity_detected = true er stadig en leveret simulering – det tæller med i total_received og i de rapporterede aggregater – men det behandles som et ikke-klik og en ikke-indsendelse: det udelades fra clicks/credential_submissions, og det afbryder en aktuel klikserie. Forsøg ikke at “rette” dette ved at tælle bots med for at matche den tidligere eksport.
• Rapportering vejer ikke tungere end et klik på last_5_assessments. En person, der klikkede og senere rapporterede, får etiketten clicked.
• Katalogtillæg udelades, de sættes ikke til null. Afdeling og lignende felter findes ikke på /v1.
• Intet tidsfilter på serversiden. GET /v1/simulation_results har ingen delivered_after. Forespørgslen gennemløber alle resultater og beholder derefter delivered_at i de seneste 12 kalendermåneder. En stor organisation med lang historik kan bruge mere af budgettet for hastighedsbegrænsning pr. nøgle, end en filtreret liste ville gøre.

​

Næste trin