E-Mail-Phishing-Protokoll

Dieser Bericht ist ein Phishing-Protokoll auf Ereignisebene: eine Zeile pro beobachteter Simulationsinteraktion (Datum, Aktion, E-Mail-Adresse des Empfängers, Betreff, Absender, Schwierigkeitsgrad). Er bleibt im Langformat – die Historie einer Person wird nicht zu einem einzelnen Ergebnis zusammengeführt. Die Abfrage bezieht die letzten 12 Kalendermonate in occurred_after ein (Mitternacht UTC am selben Tag des Monats vor zwölf Monaten – nicht als Zeitspanne von 365 Tagen). Einrichtung, Anmeldedaten, Paginierung und Wiederholungsversuche bei Ratenbegrenzung entsprechen dem Leitfaden zur Power-BI-/Excel-Anbindung. Fügen Sie zuerst die gemeinsame Abfrage Fn_FetchAll hinzu; dieser Bericht ruft sie über ihren Namen auf.

​

Erforderliche Schlüsselberechtigungen

Ein Schlüssel, dem nur simulation:read gewährt wurde, kann den Reporting-Endpunkt für Ereignisse nicht aufrufen (die API gibt 403 zurück). Siehe Die richtige Granularität wählen.

​

Quellendpunkte

Zulässige Filter für die Ereignisliste (alles andere liefert 400): limit, page_token, simulation, entity, event_type, occurred_after. Diese Reporting-Familie ist ein Vorschau-Datensatz. Das Datensatzschema und die Datenrichtlinien können Sie unter GET /v1/reporting/datasets und GET /v1/reporting/datasets/simulation_events einsehen.

​

Granularität

Eine Zeile pro Reporting-Simulationsereignis. Eine Person, die dieselbe Nachricht geöffnet und anschließend darauf geklickt hat, erzeugt zwei Zeilen. Ereignisse mit einem Nullwert für entity_id (kein Akteur / Empfänger / Zielteilnehmer) erscheinen trotzdem – email ist null. Das API-Zeitfenster wird um eine Minute erweitert; die exakte Grenze occurred_at >= WindowStart wird lokal erneut angewendet, sodass das letzte Jahr nicht davon abhängt, ob der Server occurred_after als einschließend oder ausschließend behandelt. Anfragebudget: ein paginierter Durchlauf der Ereignisse im Zeitfenster plus ein Durchlauf der Entitäten. Legen Sie stets limit = "500" fest.

​

Spaltenzuordnung

Die bisherigen Spaltennamen stammen aus dem Export Ihres früheren Anbieters. Die /v1-Felder sind die öffentlichen API-Namen; die Abfrage vergibt für den Bericht teilweise Aliasse.

​

Aktions-Token

action ist das geschlossene Reporting-Token. Das bisherige „Email Sent“ entspricht simulation.delivered (delivered ist das öffentliche Verb; das Token auf der Leitung lautet simulation.delivered). Zusätzlich enthaltene Felder, da die API sie bereitstellt: sender_domain, full_name, event_id, entity_id, simulation_id, occurred_at sowie entity_type und entity_status aus der Entitätsverknüpfung.

​

Abweichungen vom bisherigen Export

• Die rohe IP ist nie verfügbar. /v1 stellt die rohe Client-IP nicht bereit – Datenschutz durch Technikgestaltung, keine ausstehende Zuordnung. Die Abfrage fügt keine Platzhalterspalte für die IP hinzu.
• Der Gerätetyp ist abgeleitet, nicht roh. device_type ist eine abgeleitete Geräteklasse für Klick-, Übermittlungs- und Meldeereignisse. Zu den beobachteten Token gehören desktop, mobile, tablet und unknown, der Emitter speichert jedoch eine Freitext-Zeichenfolge – behandeln Sie sie als offenen Text, nicht als geschlossene Enumeration. Sie ist null, wenn das Ereignis keine abgeleitete Klasse hat, und die rohe Zeichenfolge user_agent bleibt privat.
• „Email Sent“ ist simulation.delivered. Verwenden Sie dieses Token, wenn Sie Versendungen filtern oder zählen. Suchen Sie nicht nach einer bisherigen Zeichenfolge email_sent.
• Die E-Mail-Adresse des Empfängers wird per Verknüpfung ermittelt und ist kein Feld des Ereignisses. Das Reporting-Ereignis enthält keine E-Mail-Adresse; die Abfrage durchläuft /entities, um sie zu ergänzen.
• Die letzten 12 Kalendermonate, keine Zeitspanne von 365 Tagen und nicht die vollständige Historie.
• Langformat, nicht zusammengeführt. Eine Zeile pro Interaktion, nicht ein Ergebnis pro Person.

​

Nächste Schritte