Risultati, metriche, report ed export
Un report è uno snapshot dei dati disponibili a una certa data, non una vista continuamente aggiornata. Invio SMTP, recapito, interazione sul collegamento e identificazione della persona sono fatti differenti. La piattaforma espone i primi e i segnali osservati senza dedurre automaticamente gli altri.
Generare un report
- Aprire Simulazioni phishing → Risultati e selezionare la campagna del tenant corrente.
- Selezionare Aggregato oppure Nominativo, quando disponibile.
- Usare Genera report campagna per lo snapshot della campagna, oppure Rigenera report invii per il riepilogo degli invii assestati.
- Attendere la generazione e leggere Dati al, stato degli invii e stato dell'osservazione.
results.aggregate consente l'accesso ai risultati. Il nominativo richiede anche results.identifiable; l'export richiede results.export. Se l'osservazione è ancora attiva, il report campagna è marcato Snapshot parziale. Per includere interazioni successive occorre generare un nuovo snapshot.
Scegliere il report corretto
| Domanda operativa | Scelta | Controllo sul risultato |
|---|---|---|
| Quanti messaggi hanno un esito SMTP definitivo? | Rigenera report invii, dopo l'assestamento | Confrontare N, accettati, falliti, esclusi, annullati e incerti; i pendenti devono essere assestati |
| Quali segnali risultano finora durante l'esercitazione? | Genera report campagna | Leggere “Dati al” e l'indicazione snapshot parziale se l'osservazione continua |
| Serve un riepilogo senza indirizzi destinatari | Aggregato | Metriche e metadati, senza la tabella nominativa |
| Occorre verificare una casella di collaudo autorizzata | Nominativo, con il permesso specifico | Tipo casella, stato SMTP, conteggio eventi e primi/ultimi istanti; non attribuire automaticamente l'azione a una persona |
| Serve condividere la stessa versione già analizzata | Prepara XLSX o JSON sul report scelto | Export legato all'identificativo di quel report; rigenerare il report se si vogliono dati più recenti |
sending_not_settled significa che il report invii è stato richiesto troppo presto. Tornare all'avanzamento e attendere che non restino queued, retry_scheduled o in_flight. PHISHING_REPORT_QUEUE_FULL indica capacità di generazione occupata: attendere le richieste già presenti nello storico prima di ripetere.
| Stato richiesta/report | Significato |
|---|---|
queued | Richiesta in coda |
snapshotting | Preparazione dei dati dello snapshot |
rendering | Generazione in corso |
ready | Versione pronta e consultabile |
failed | Generazione fallita; verificare il codice e richiedere il solo report |
invalidated | Versione non più valida |
expired | Scadenza superata |
Lo Storico richieste report distingue le richieste e i relativi esiti. Un problema nella generazione di un report non richiede di inviare nuovamente la campagna.
Ripartizione SMTP
La popolazione ammessa N è ripartita negli stati seguenti. I conteggi descrivono l'intenzione di invio per destinatario nella campagna, non il numero di aperture.
| Stato | Significato |
|---|---|
queued | In coda, senza un esito finale |
retry_scheduled | Nuovo tentativo pianificato dopo un rifiuto ritentabile |
in_flight | Tentativo in corso |
accepted | Server SMTP ha accettato il messaggio; recapito e lettura non sono confermati |
failed | Invio fallito secondo l'esito registrato |
skipped | Destinatario escluso dopo lo snapshot operativo |
cancelled | Invio annullato |
delivery_unknown | Accettazione SMTP non determinabile con certezza |
I pendenti comprendono queued, retry_scheduled e in_flight. Gli esiti sono assestati quando questi tre conteggi sono a zero. delivery_unknown resta un esito incerto anche dopo l'assestamento: non deve essere sommato agli accettati né reinviato automaticamente.
Se la ripartizione non è coerente con N, aggiornare i dati o segnalare il problema al supporto. Non interpretare la percentuale di esiti operativi disponibili come percentuale di consegna.
Denominatori e interazioni
| Metrica | Interpretazione corrente |
|---|---|
| Denominatore | Destinatari unici con invio SMTP accettato nello snapshot |
| Click osservati | Destinatari distinti con almeno un evento click nel gruppo degli accettati |
| Invii form osservati | Destinatari distinti con almeno un evento form_submit nel gruppo degli accettati |
| Probabile automazione | Destinatari distinti con almeno un evento classificato come probabile automazione |
| Segnali incerti | Destinatari distinti con almeno un evento classificato incerto |
| Aperture | Non misurate dall'implementazione corrente; eventuali valori storici sono indicati come stime |
| Segnalazioni | Non misurate: nessuna fonte qualificata nello snapshot corrente |
Le metriche sono indipendenti e possono sovrapporsi: non formano una sequenza obbligata e non vanno sommate per ottenere il totale dei partecipanti. Con denominatore zero le percentuali non sono disponibili.
Il report creato dalla schermata corrente non applica un filtro automatico alle sole caselle person: il denominatore segue la popolazione del report e lo stato SMTP. La classificazione shared/list distingue il tipo di casella nel dettaglio; non trasforma i conteggi in misure individuali. Il testo informativo dell'importazione sulle “misure individuali” non va interpretato come esclusione automatica da ogni aggregato.
I segnali collegati a invii delivery_unknown sono riportati separatamente nella popolazione incerta. Non entrano nel denominatore degli accettati e non dimostrano retroattivamente un'accettazione SMTP.
Dettaglio nominativo
La tabella identifica la casella destinataria del collegamento, non con certezza la persona che lo ha utilizzato. Inoltri, caselle condivise e scanner possono produrre interazioni.
| Colonna | Significato |
|---|---|
| Destinatario del link | Email associata al destinatario della campagna |
| Tipo casella | person/shared/list importato nella popolazione |
| Stato SMTP | Stato di invio del destinatario |
| Click osservati | Numero di eventi click registrati per la casella, distinto dal conteggio di destinatari unici dell'aggregato |
| Primo / ultimo click | Estremi temporali degli eventi osservati |
| Invii form | Numero di eventi form_submit per la casella |
| Primo / ultimo invio form | Estremi temporali degli eventi form_submit |
| Eventi con probabile automazione | Numero di eventi con quella classificazione |
| Eventi incerti | Numero di eventi con classificazione incerta |
| Classificazioni | Insieme delle classificazioni presenti |
Gli orari sono presentati nel fuso indicato dal report. Non disponibile è diverso da zero: può indicare che uno snapshot precedente non contiene quel dettaglio.
La landing simulata registra l'interazione di invio form; i valori digitati nei campi identificativo/password vengono svuotati nel browser e non sono trasmessi o conservati dal flusso implementato. Un evento form_submit non è quindi una credenziale acquisita o prova di compromissione.
Metadati dello snapshot
Aprire Contesto didattico e dettagli dello snapshot per leggere obiettivo, pubblico, indizi, difficoltà e pertinenza, oltre a:
| Metadato | Uso |
|---|---|
| Dati al / Generato | Distingue il momento dei dati dal completamento della generazione |
| Versione report | Identifica il risultato consultato o esportato |
| Snapshot ID | Riferimento tecnico dello snapshot, quando presente |
| Classificatore | Versione o qualificazione del classificatore; non una certificazione dell'identità dell'utente |
| Versione dati | Revisione delle sorgenti usata dal report |
| Versione popolazione | Revisione della popolazione |
| Versione campagna | Configurazione della campagna rappresentata |
| Fine autorizzazione invii | Termine per l'autorizzazione di nuovi tentativi |
| Esiti assestati | Momento in cui gli invii già avviati risultano assestati |
Usare questi riferimenti per confrontare due report. Uno snapshot nuovo può differire perché sono arrivati eventi, sono cambiati gli esiti o sono intervenute modifiche di disponibilità/privacy dei dati.
Esportazione XLSX e JSON
Su un report pronto, Prepara XLSX o Prepara JSON crea un export della versione selezionata. Attendere ready, verificare versione, formato, livello aggregato/nominativo e scadenza, quindi scegliere Scarica.
Gli export hanno stati queued, ready, failed, invalidated, expired. Il servizio limita la scadenza a 7 giorni dalla creazione oppure alla scadenza del report, se precedente. Un export non valido o scaduto non è scaricabile come se fosse corrente. Le autorizzazioni sono ricontrollate anche durante il download.
Verificare il file esportato
- Prima di Prepara XLSX/JSON, annotare campagna, versione report, istante “Dati al” e livello di dettaglio.
- Attendere
readynello stato export e verificare che il riferimento sia ancora quello del report selezionato. - Scaricare il formato richiesto e confrontare i metadati con quelli annotati. Non usare solo il nome della campagna per distinguere due snapshot.
- Se il file deve contenere gli eventi raccolti dopo lo snapshot, generare prima un nuovo report e poi un nuovo export di quella versione.
- Se l'export è fallito, scaduto o invalidato, controllare disponibilità del report e permessi. Preparare un nuovo export quando la versione è ancora valida; se serve, rigenerare il report. Non ripetere la simulazione per ottenere il file.
Il file nominativo può contenere email e altri dati del perimetro autorizzato. Nelle copie usate per assistenza o documentazione rimuovere identificativi reali, indirizzi e riferimenti di campagna. Conservare versione e contesto tecnico necessari a interpretare il dato.