Utenti più suscettibili

Questo report è un riepilogo della suscettibilità per singolo utente su 12 mesi: una riga per ogni persona che ha ricevuto almeno una simulazione nell’ultimo anno, con conteggi e percentuali di clic, credenziali e segnalazioni, la serie corrente di clic e un elenco concatenato degli ultimi 5 risultati. La finestra temporale è di 12 mesi di calendario (mezzanotte UTC dello stesso giorno del mese di dodici mesi fa), non una durata di 365 giorni. Configurazione, credenziali, paginazione e nuovi tentativi in caso di limite di frequenza sono gli stessi della guida alla connettività Power BI / Excel. Aggiungere prima la query condivisa Fn_FetchAll; questo report la richiama per nome.

​

Ambiti della chiave richiesti

Questo report utilizza l’elenco operativo dei risultati per singola persona, non la famiglia di anteprime di reportistica. Una chiave a cui è stato concesso solo reporting:read non può chiamare GET /v1/simulation_results (l’API restituisce 403). Vedere scegliere la granularità corretta.

​

Endpoint di origine

Filtri consentiti nell’elenco dei risultati: limit, page_token, simulation, entity. In questo elenco non sono disponibili delivered_after / start_date, quindi gli ultimi 12 mesi vengono applicati in Power Query dopo la scansione completa. Campi utilizzati in ogni risultato: 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.

​

Granularità

Una riga per ogni entità che ha almeno un risultato con delivered_at negli ultimi 12 mesi di calendario. Una persona individuata come destinataria ma a cui non è mai stato recapitato nulla non compare. Qui le simulazioni multiple per la stessa persona vengono aggregate. Budget di richieste: una scansione paginata di tutti i risultati delle simulazioni dell’organizzazione, più una scansione delle entità. Impostare sempre limit = "500".

​

Precedenza dei risultati (last_5_assessments)

Ciascuno dei cinque risultati recapitati più recenti (delivered_at in ordine decrescente) viene riepilogato come YYYY-MM-DD: <outcome>. Prevale il primo timestamp corrispondente, a partire da quello con priorità più alta: Solo recapitato è no action (il messaggio è arrivato; la persona non ha fatto nulla). Una persona che ha cliccato e in seguito ha segnalato è clicked: la segnalazione non prevale su un’interazione a rischio in questo elenco. Le righe contrassegnate come bot ricevono comunque un’etichetta di risultato in base ai timestamp presenti; semplicemente non incrementano i conteggi di clic / credenziali. Serie corrente di clic: scorrere gli stessi risultati recapitati dal più recente al meno recente e contare le righe consecutive in cui clicked_at non è nullo e bot_activity_detected non è true. Fermarsi alla prima riga che non soddisfa la condizione.

​

Mappatura delle colonne

I nomi delle colonne legacy provengono dall’esportazione del precedente provider. I campi /v1 sono i nomi dell’API pubblica; la query ricava conteggi e percentuali. Chiave di join mantenuta per un modello a schema a stella: entity_id.

​

Divergenze rispetto all’esportazione legacy

• L’attività dei bot è esclusa dai conteggi di clic e credenziali. L’esportazione di un precedente provider contava le interazioni di scanner automatici / bot come clic e invii di credenziali. Questa query no. Un risultato con bot_activity_detected = true è comunque una simulazione recapitata: viene conteggiato in total_received e negli aggregati delle segnalazioni, ma è trattato come non-clic e non-invio: è omesso da clicks / credential_submissions e interrompe la serie corrente di clic. Non “correggere” questo comportamento contando i bot per allinearsi all’esportazione legacy.
• La segnalazione non prevale su un clic in last_5_assessments. Una persona che ha cliccato e in seguito ha segnalato viene etichettata come clicked.
• Le informazioni aggiuntive della directory sono omesse, non impostate a null. Reparto e campi simili non sono presenti in /v1.
• Nessun filtro temporale lato server. GET /v1/simulation_results non ha delivered_after. La query scorre tutti i risultati, poi mantiene delivered_at negli ultimi 12 mesi di calendario. Un’organizzazione con un ampio storico può consumare una parte maggiore del budget di frequenza per chiave rispetto a un elenco filtrato.

​

Passaggi successivi