Journal d'hameçonnage par e-mail

Ce rapport est un journal d’hameçonnage au niveau des événements : une ligne par interaction de simulation observée (date, action, adresse e-mail du destinataire, objet, expéditeur, difficulté). Il reste au format long : il ne regroupe pas l’historique d’une personne en un seul résultat. La requête intègre les 12 derniers mois calendaires dans occurred_after (minuit UTC le même jour du mois, douze mois auparavant — et non une durée de 365 jours). La configuration, les identifiants, la pagination et la gestion des nouvelles tentatives en cas de limitation de débit sont identiques à ceux du guide de connectivité Power BI / Excel. Ajoutez d’abord la requête partagée Fn_FetchAll ; ce rapport l’appelle par son nom.

​

Portées de clé requises

Une clé disposant uniquement de simulation:read ne peut pas appeler le point de terminaison des événements de reporting (l’API renvoie 403). Consultez choisir la bonne granularité.

​

Points de terminaison sources

Filtres autorisés sur la liste des événements (tout autre filtre renvoie 400) : limit, page_token, simulation, entity, event_type, occurred_after. Cette famille de reporting est un jeu de données en préversion. Consultez le schéma du jeu de données et les politiques de données à l’adresse GET /v1/reporting/datasets et GET /v1/reporting/datasets/simulation_events.

​

Granularité

Une ligne par événement de simulation de reporting. Une personne qui a ouvert puis cliqué sur le même message génère deux lignes. Les événements dont entity_id est nul (aucun acteur / destinataire / participant cible) apparaissent tout de même — email est nul. La fenêtre de l’API est élargie d’une minute ; la borne exacte occurred_at >= WindowStart est réappliquée localement afin que l’année glissante ne dépende pas du fait que le serveur traite occurred_after comme inclusif ou exclusif. Budget de requêtes : un parcours paginé des événements de la fenêtre, plus un parcours des entités. Définissez toujours limit = "500".

​

Mappage des colonnes

Les noms de colonnes historiques proviennent de l’export de votre fournisseur précédent. Les champs /v1 sont les noms de l’API publique ; la requête en renomme certains pour le rapport.

​

Jetons d’action

action est le jeton de reporting fermé. L’ancien « Email Sent » correspond à simulation.delivered (delivered est le verbe public ; le jeton transmis est simulation.delivered). Champs supplémentaires conservés car l’API les fournit : sender_domain, full_name, event_id, entity_id, simulation_id, occurred_at, ainsi que entity_type et entity_status issus de la jointure d’entités.

​

Différences par rapport à l’export historique

• L’adresse IP brute n’est jamais disponible. /v1 n’expose pas l’adresse IP brute du client — protection de la vie privée dès la conception, et non mappage en attente. La requête n’ajoute aucune colonne IP de substitution.
• Le type d’appareil est dérivé, non brut. device_type est une classe d’appareil dérivée pour les événements de clic, de soumission et de signalement. Les jetons observés comprennent desktop, mobile, tablet et unknown, mais l’émetteur stocke une chaîne libre — traitez-la comme du texte ouvert, et non comme une énumération fermée. Elle est nulle lorsque l’événement n’a pas de classe dérivée, et la chaîne brute user_agent reste privée.
• « Email Sent » correspond à simulation.delivered. Utilisez ce jeton pour filtrer ou compter les envois. Ne recherchez pas de chaîne historique email_sent.
• L’adresse e-mail du destinataire est obtenue par jointure et n’est pas un champ de l’événement. L’événement de reporting omet l’adresse e-mail ; la requête parcourt /entities pour la renseigner.
• 12 derniers mois calendaires, et non une durée de 365 jours, ni l’historique complet.
• Format long, non regroupé. Une ligne par interaction, et non un résultat par personne.

​

Étapes suivantes