# Événements de livraison et diagnostic

> La taxonomie des événements de livraison qu'émet un ESP ou un MTA (processed, deferred, delivered, bounce, blocked, dropped, spamreport, open, click), ainsi que les rapports de délivrabilité, le diagnostic des retards et le score de qualité de l'engagement : la couche d'instrumentation sous les procédures de dépannage.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/operations/evenements-de-livraison-et-diagnostic

Lorsque vous devez savoir ce qui est arrivé à un message, ou pourquoi une campagne donne de mauvais résultats, la réponse commence dans le flux d'événements. Chaque message que traite un fournisseur de services de messagerie (ESP) passe par une suite d'états. Chaque changement d'état est un **événement** que la plateforme enregistre et peut vous transmettre en continu.

Les taux de rebonds et de plaintes, les estimations du placement en boîte de réception par fournisseur, l'analyse des retards et les scores d'engagement sont tous construits à partir de ces événements. L'Event Webhook de SendGrid sert ci-dessous d'exemple de référence, car il est entièrement spécifié. Après les événements viennent les rapports, le diagnostic des retards et le score d'engagement construits sur eux.

Pour les seuils qu'alimentent ces événements et les mesures correctives qu'ils déclenchent, voir [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite). Pour un diagnostic pas à pas, voir [Procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison). Les deux s'appuient sur les données décrites ici.

## La taxonomie des événements

Les événements se répartissent en trois familles. Les **événements de livraison** enregistrent ce que le système d'envoi et les serveurs de réception ont fait du message. Les **événements d'engagement** enregistrent ce qu'a fait le destinataire. Les **événements de compte** enregistrent les changements de statut au niveau de la plateforme. L'Event Webhook de SendGrid les publie en JSON. Les noms sont les libellés de SendGrid, mais toute infrastructure d'envoi produit des états équivalents.

### Événements de livraison

| Événement | Signification | Déclencheur |
|---|---|---|
| **processed** | La plateforme a accepté le message et peut le livrer | Le message a été injecté, validé et placé en file d'attente pour l'agent de transfert de courrier (MTA) sortant |
| **deferred** | Le serveur de réception a refusé le message **temporairement** | Une réponse 4.x.x du MTA distant (liste grise, limitation de débit, « try again later ») ; la plateforme réessaie |
| **delivered** | Le serveur de réception a accepté le message (`250 OK`) | Le MTA distant a renvoyé une réponse de succès 2.x.x à `DATA` |
| **bounce** | Le serveur de réception a rejeté le message | Un rejet permanent 5.x.x (ou un échec temporaire après épuisement des nouvelles tentatives), renvoyé pendant la session SMTP ou plus tard dans une notification d'état de livraison (DSN) asynchrone |
| **blocked** | Un sous-type de rebond *temporaire* : un rejet temporaire pour des raisons de réputation, de contenu ou un problème technique | Le MTA distant a rejeté le message, mais pas parce que l'adresse est invalide ; enregistré comme un rebond avec `type: "blocked"` |
| **dropped** | La **plateforme elle-même** a refusé d'envoyer, donc le message n'est jamais parti | Le destinataire figure dans une liste de suppression (après un rebond antérieur, un désabonnement, un signalement de spam ou une adresse invalide), le contenu a été signalé comme spam, un en-tête ou un modèle était invalide, ou un quota a été dépassé |

Les distinctions qu'un opérateur doit bien connaître :

- **Un report de remise n'est pas un rebond.** Un report est un refus temporaire que la plateforme continue de retenter. Il ne devient un rebond que si les nouvelles tentatives sont épuisées. Des reports persistants sont le signe classique d'une limitation de débit (voir [Diagnostic des retards et de la latence](#diagnostic-des-retards-et-de-la-latence)).
- **bounce et blocked sont différents.** SendGrid enregistre les deux comme un événement `bounce` et les distingue par le champ `type`. `type: "bounce"` est un rebond définitif, qui est permanent (par exemple, l'adresse n'existe pas). `type: "blocked"` est un rebond temporaire : un rejet temporaire à cause de la réputation, du contenu ou d'un problème technique. Dans les rapports Bounces & Blocks de l'interface, un **Bounce** désigne une adresse email invalide (qui n'a jamais existé ou a été désactivée), tandis qu'un **Block** signifie que le message a été rejeté pour des « content and reputation issues or technical failures » (problèmes de contenu et de réputation ou défaillances techniques). Un blocage est le jugement du serveur de réception sur vous, et non sur l'adresse, et il peut disparaître une fois corrigé le problème de réputation ou de contenu qui en est la cause. Voir [Listes de blocage DNS et zones Spamhaus](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus).
- **Un abandon, c'est la plateforme qui vous protège, ou votre propre erreur.** La plateforme a supprimé l'envoi avant la transmission. La plupart des abandons sont sains, car supprimer une adresse connue comme mauvaise protège la réputation. Un pic d'abandons pour des raisons inattendues (un modèle invalide, un quota dépassé) signale un défaut côté expéditeur, et non un problème chez le serveur de réception. [Architecture des listes de suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture) explique la portée des suppressions.
- **Livré ne veut pas dire en boîte de réception.** `delivered` est publié quand le serveur de réception répond `250 OK`. Ensuite, le serveur de réception peut encore placer le message en boîte de réception, le mettre en file d'attente, le classer dans le dossier spam ou le courrier indésirable, le supprimer sans rien dire ou (chez Gmail) le ranger dans un onglet, et la plateforme d'envoi ne reçoit **aucun autre signal** sur tout cela. La seule preuve ultérieure est l'engagement du destinataire (ouvertures et clics). Un taux de livraison élevé avec un engagement quasi nul est le signe typique de messages classés en spam. C'est pourquoi le placement en boîte de réception ne peut être qu'*estimé*, par des tests sur liste de test et les tableaux de bord postmaster des fournisseurs, et jamais lu directement dans les événements de livraison. Voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) et [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation).

### Classification des rebonds

Pour les événements `bounce`, SendGrid ajoute un champ `bounce_classification` qui range l'échec SMTP dans une catégorie de cause sur laquelle un opérateur peut agir :

| Classification | Signification et action de l'opérateur |
|---|---|
| **Invalid Address** | L'adresse n'existe pas ou n'a jamais existé. Retirez-la définitivement (hygiène de base de données) |
| **Mailbox Unavailable** | La boîte est pleine ou temporairement injoignable. Souvent temporaire ; peut se rétablir |
| **Technical** | Un échec DNS, de connexion, de protocole ou TLS, côté infrastructure |
| **Content** | Le contenu du message a déclenché un rejet ou un filtrage. Corrigez le contenu ou les liens |
| **Reputation** | La réputation de l'adresse IP ou du domaine d'envoi a causé le rejet. Travaillez sur la réputation |
| **Frequency/Volume** | Le débit ou le volume d'envoi est trop élevé pour le serveur de réception. Limitez le débit (voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta)) |
| **Unclassified** | L'échec n'a pas pu être rangé dans une catégorie |

Les catégories Content et Reputation alimentent le score de qualité de l'engagement (voir plus bas) comme alerte précoce, car elles montrent que le serveur de réception vous juge, et non que l'adresse est mauvaise.

### Événements d'engagement

| Événement | Signification | Déclencheur |
|---|---|---|
| **open** | Le destinataire a affiché le message HTML | Le pixel de suivi des ouvertures s'est chargé (Open Tracking doit être activé) |
| **click** | Le destinataire a cliqué sur un lien de suivi | Un lien réécrit a été suivi (Click Tracking doit être activé) |
| **spamreport** | Le destinataire a marqué le message comme spam (une *plainte*) | L'action « marquer comme spam » du destinataire, transmise par la feedback loop du fournisseur |
| **unsubscribe** | Le destinataire a cliqué sur le lien global de désinscription de tous les envois | Subscription Tracking est activé |
| **group_unsubscribe** | Le destinataire s'est désabonné d'un groupe de suppression | Un lien de désabonnement du groupe ou la page de préférences |
| **group_resubscribe** | Le destinataire s'est de nouveau abonné à un groupe | La page de préférences (Subscription Tracking activé) |

Deux précautions évitent que les événements d'engagement vous induisent en erreur :

- **Ouvertures par des machines.** SendGrid renseigne `sg_machine_open: true` lorsque l'ouverture a été générée par Apple Mail Privacy Protection (MPP), et non par une personne. Excluez ces ouvertures de toute mesure réelle de l'engagement. Le préchargement des images de Gmail déclenche aussi des ouvertures sans personne. Voir [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure) et [Interactions non humaines](https://emailmarketing.net/fr/apprendre/operations/interactions-non-humaines).
- **spamreport est votre signal de plainte.** C'est la partie de la feedback loop du fournisseur que voit l'expéditeur. Un taux de spamreport soutenu est la donnée d'entrée la plus dommageable pour la réputation. Voir [Feedback loops de plaintes](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes).

### Événements de compte

SendGrid émet `account_status_change` lorsque la plateforme modifie la situation d'un compte pour des raisons de conformité (phishing, taux de spam élevés, « other bad behavior »). Le champ `type` donne l'action, par ordre de gravité croissante :

| `type` | Effet |
|---|---|
| `compliance_suspend` | Bloque la livraison ; met les messages en file d'attente et les fait rebondir au moment de la livraison |
| `compliance_deactivate` | Bloque la livraison ; rejette les files d'attente ; supprime les messages en file d'attente ; bannit l'utilisateur au bout de 48 heures |
| `compliance_ban` | Bloque la livraison ; rejette et supprime les files d'attente ; retire l'accès à la console ; annule la facturation ; retire les adresses IP |
| `reactivate` | Rétablit le compte en statut actif |

Pour la façon dont un opérateur d'ESP détecte et contient ces problèmes et applique l'échelle des sanctions, voir [Comptes compromis](https://emailmarketing.net/learn/esp-operations/compromised-accounts), [Surveillance des envois sortants](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) et [Architecture multi-tenant](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture).

## Champs de la charge utile des événements

Le JSON du webhook comporte un ensemble de champs communs et des champs propres à chaque événement. Ce sont les champs que vous mettez en correspondance pour répondre à la question « qu'est-il arrivé à ce message ? ».

| Champ | Type | Événements | Signification |
|---|---|---|---|
| `email` | chaîne | tous | Adresse du destinataire |
| `timestamp` | entier (UNIX) | tous | Moment où l'événement s'est produit |
| `event` | chaîne | tous | Identifiant du type d'événement |
| `sg_event_id` | chaîne | tous | Identifiant unique de l'événement (compatible URL, ≤100 caractères), la clé pour supprimer les doublons |
| `sg_message_id` | chaîne | tous | Identifiant unique du message, la clé qui relie tous les événements d'un même message |
| `smtp-id` | chaîne | événements de livraison, ainsi que les événements bounce, spam et group | Message-ID attribué par le système d'origine |
| `category` | chaîne ou tableau | livraison et engagement | Étiquettes personnalisées que l'expéditeur définit pour organiser ses messages |
| `asm_group_id` | entier | la plupart | Identifiant du groupe de désabonnement (suppression) |
| `marketing_campaign_id` et `_name` | entier et chaîne | livraison et engagement | Identifiants de la campagne |
| `pool` | objet `{name, id}` | processed | Pool d'adresses IP depuis lequel le message a été envoyé |
| `ip` | chaîne | delivered, open, click, désabonnement et réabonnement à un groupe | Adresse IP d'envoi (delivered) ou adresse IP du destinataire (engagement) |
| `response` | chaîne | delivered, deferred | Texte intégral de la réponse du serveur de réception |
| `reason` | chaîne | bounce, deferred, dropped | Raison lisible de l'erreur ou de l'abandon |
| `status` | chaîne `X.Y.Z` | bounce, dropped | Code d'état étendu (voir [Codes d'état étendus](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp)) |
| `attempt` | entier | deferred | Nombre de tentatives de livraison jusqu'ici |
| `type` | chaîne | bounce, account | `bounce` ou `blocked`, ou l'action sur le statut du compte |
| `bounce_classification` | chaîne | bounce | Catégorie de cause (tableau ci-dessus) |
| `tls` | booléen | bounce, delivered | Indique si la connexion a utilisé TLS |
| `url` | chaîne | click, désabonnement et réabonnement à un groupe | L'URL concernée |
| `url_offset` | entier | click | Position du lien dans le HTML, à partir de zéro (les URL répétées reçoivent des positions différentes) |
| `useragent` | chaîne | open, click, désabonnement et réabonnement à un groupe | Programme client qui a généré l'événement |
| `sg_machine_open` | booléen | open | Vrai si l'ouverture a été générée par Apple MPP |
| `unique_args` | objet | livraison et engagement | Paramètres personnalisés fournis par l'expéditeur |

> SendGrid recommande de ne jamais placer de données personnelles dans `category` ou `unique_args`. La plateforme peut utiliser ces champs pour ses opérations internes, ils ne peuvent pas être masqués, et ils peuvent être conservés longtemps.

Une requête de diagnostic typique joint tous les événements qui partagent un même `sg_message_id` et les trie par `timestamp` pour reconstituer l'historique complet d'un message : processed, puis deferred une ou plusieurs fois, puis delivered, puis open. Une autre agrège par `event`, `bounce_classification` et domaine de réception pour trouver quel fournisseur rejette quelle catégorie de messages.

## Rapports de délivrabilité

Un tableau de bord de diagnostic construit à partir du flux d'événements suit le modèle « Deliverability Insights » (dans SendGrid, sous **Stats**, puis **Deliverability Insights**). Ses données ont environ **48 heures** de retard sur le temps réel. Il comporte quatre vues :

| Vue | Contenu |
|---|---|
| **Overview** | Processed (« la quantité de messages que vous avez tenté d'envoyer »), Delivered (% acceptés par les fournisseurs de messagerie), Bounce & Blocked (% non livrés) et Unique Opens (% des messages *livrés* qui ont été ouverts), en tendance dans le temps |
| **Mailbox Providers** | Les mêmes indicateurs pour chaque fournisseur (Gmail, Yahoo, Microsoft, AOL, …) : taux de livraison, taux d'ouverture, et répartition entre rebonds et blocages |
| **Bounces & Blocks** | Les deux types d'échec séparément : un **Bounce** est une adresse invalide ; un **Block** est un rejet pour des raisons de contenu, de réputation ou un problème technique |
| **Spam & Unsubscribes** | Les plaintes et les désinscriptions, par fournisseur |

Le choix de conception le plus important est la **segmentation par fournisseur de messagerie**. Un taux de livraison global de 95 % peut masquer un blocage total chez un fournisseur. La réputation est tenue séparément chez chaque fournisseur, donc le diagnostic et la correction doivent aussi se faire fournisseur par fournisseur (voir [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation) et [Réglages de référence par fournisseur](https://emailmarketing.net/fr/apprendre/operations/reglages-de-reference-par-fournisseur)). SendGrid publie ces seuils pour lire cette vue :

| Signal | Seuil |
|---|---|
| Taux de blocage | Objectif **≤ 3 %** chez chaque grand fournisseur de messagerie |
| Taux de signalement de spam | **≥ 0,1 %** chez un seul fournisseur, c'est excessif |
| Taux de rebonds | **Constamment au-dessus de 5 %**, c'est préoccupant |
| Déclencheur de mise en sommeil | Aucune ouverture ni aucun clic pendant **3 mois** : cessez d'écrire à cette adresse |

Ces seuils concordent avec les seuils rassemblés à partir de plusieurs sources dans [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite) : le consensus de ≤0,1 % de plaintes et de <5 % de rebonds, et la limite de 0,3 % que Gmail et Yahoo traitent comme une violation.

## Diagnostic des retards et de la latence

« Retard » peut désigner deux choses très différentes, et les confondre oriente le diagnostic dans la mauvaise direction.

**1. Retard chez le serveur de réception (reports de remise et limitation de débit).** Le message a quitté la plateforme, mais le serveur de réception le retient par une liste grise, une limitation de débit ou un « try again later ». Cela se traduit par des événements **deferred** avec un compteur `attempt` croissant et une `response` 4.x.x. La plateforme réessaie selon un calendrier. SendGrid retente les messages reportés pendant **72 heures** au maximum, puis transforme le message en rebond.

Des reports persistants concentrés chez un seul fournisseur signifient que vous dépassez ce que ce fournisseur accepte en débit ou en volume. Le remède est d'adapter le trafic à ce serveur de réception (réduire la concurrence ou le débit, étaler l'envoi sur davantage d'heures), et non de multiplier les tentatives. Voir [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta) et [Liste grise (RFC 6647)](https://emailmarketing.net/learn/rfc/rfc6647-greylisting).

**2. Retard sur la plateforme ou à l'injection (bloqué en Processing).** Le message n'atteint jamais un serveur de réception ; il reste à l'état **processed**. SendGrid documente plusieurs causes :

- **Une limite de volume sur une nouvelle adresse IP dédiée.** Un plafond de volume s'applique pendant les **3 premiers jours** sur une nouvelle adresse IP dédiée, pour prévenir les abus. Augmentez le volume progressivement avec le processus de [chauffe d'IP](https://emailmarketing.net/fr/apprendre/gestion-des-adresses-ip/recommandations-pour-la-chauffe-d-ip).
- **Une mise en attente pour conformité.** Pour un compte en cours d'examen, ou sur lequel une activité inhabituelle a été détectée, l'envoi est suspendu jusqu'à confirmation par l'équipe Compliance.
- **Un engorgement de la file d'attente du MTA.** Un volume d'envoi très élevé peut accumuler les messages dans la file d'attente du MTA sortant. Mettez l'envoi en pause ou mettez une autre adresse IP en service.
- **La suspension d'un compte dormant.** Les comptes sans aucune connexion sont suspendus automatiquement.

Les messages restent en attente pendant **72 heures** au maximum. Si le problème sous-jacent n'est pas résolu d'ici là, ils deviennent des **rebonds définitifs**.

**3. Latence de transport (intégration et réseau).** Le message arrive lentement dans la plateforme. Les recommandations de SendGrid portent sur le débit et le chemin réseau :

- Utilisez les bibliothèques clientes officielles (C#, PHP, Ruby, Node.js, Python, Go, Java) plutôt que du code écrit de zéro.
- Débit SMTP : jusqu'à **5000 messages par connexion**, et jusqu'à **1000 destinataires `To:` par message** (par l'en-tête `x-smtpapi`).
- Ouvrez davantage de connexions simultanées, jusqu'à un **maximum recommandé d'environ 10 connexions simultanées**.
- Diagnostic réseau : `hping` et `Test-NetConnection` mesurent le temps de réponse et le TTL, et **tout ce qui dépasse environ 150 ms** de temps de réponse est un premier signal d'alerte. Le mode traceroute montre la latence de chaque saut ; surveillez les hausses brusques d'un saut à l'autre. Les analyseurs d'en-têtes (comme celui de Google) montrent le trajet du message à travers chaque MTA et le temps passé à chaque saut. Wireshark capture la conversation SMTP pour une inspection approfondie.

Diagnostiquez dans cet ordre. Vérifiez d'abord l'état `event`. **processed** indique un problème de plateforme ou de conformité ; **deferred** indique une limitation de débit par le serveur de réception ; **delivered sans engagement** indique le dossier spam, qui est un problème de placement et non de retard. N'utilisez les outils de latence de transport qu'une fois confirmé que le message quitte normalement la plateforme.

## Score de qualité de l'engagement

Le niveau d'agrégation le plus élevé transforme tout le flux d'événements en un seul score de santé. L'**API Engagement Quality (SEQ)** de SendGrid en est l'exemple de référence. Elle renvoie un score de **1 à 5**, où un score plus élevé signifie un meilleur engagement et une meilleure délivrabilité. Le score permet à un opérateur de classer les expéditeurs et les sous-utilisateurs à grande échelle, et de repérer une dégradation avant qu'elle ne devienne un incident de réputation.

Un score n'est généré qu'avec le **suivi des ouvertures activé** et **≥ 1 000 messages envoyés au cours des 30 derniers jours**. Les scores sont conservés **90 jours** au maximum. Les points de terminaison renvoient les scores du compte et de chaque sous-utilisateur.

Le score combine cinq composantes pondérées, qui sont les signaux d'événements décrits plus haut, condensés :

| Composante | Ce qu'elle mesure |
|---|---|
| **Engagement Recency** | Le % d'adresses uniques destinataires au cours des **30 derniers jours** qui ont aussi interagi (ouverture ou clic) au cours des **90 derniers jours** |
| **Unique Open Rate** | Le taux le plus bas sur les **7 et 30 derniers jours** chez les **5 principaux fournisseurs de messagerie**, hors ouvertures par les machines d'Apple et messages non livrés |
| **Bounce Rate** | Le % de rebonds permanents sur les 7 et 30 derniers jours, en retenant le **plus élevé** (le pire) des deux |
| **Bounce Classification** | Donne du poids aux rebonds classés **Reputation** ou **Content**, les catégories où le serveur de réception vous juge |
| **Spam Rate** | Les plaintes pour spam récentes sur une fenêtre de **7 jours** |

Cette conception montre ce qu'une plateforme considère réellement comme de la qualité : un engagement récent (écrivez-vous à des personnes qui veulent encore vos messages ?), de vraies ouvertures plutôt que des ouvertures par des machines chez les fournisseurs qui comptent, des rebonds permanents qui évoluent dans le mauvais sens, les rebonds de réputation et de contenu en particulier, et les plaintes. Un ESP peut utiliser ces scores pour répartir les sous-utilisateurs en [pools d'adresses IP](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture), signaler les expéditeurs peu performants à la [surveillance des envois sortants](https://emailmarketing.net/learn/esp-operations/outbound-monitoring), et décider quand faire passer des expéditeurs d'une infrastructure partagée à une infrastructure dédiée, ou l'inverse.

## Voir aussi

- [Procédures de dépannage de la livraison](https://emailmarketing.net/fr/apprendre/operations/procedures-de-depannage-de-la-livraison)
- [Indicateurs et valeurs de référence de la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/indicateurs-et-valeurs-de-reference-de-la-delivrabilite)
- [Codes d'état étendus (RFC 3463)](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/codes-d-etat-etendus-smtp), pour lire le champ `status`
- [Notifications d'état de livraison (RFC 3464)](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/notifications-d-etat-de-livraison), le format des rebonds asynchrones
- [Distorsions du suivi et de la mesure](https://emailmarketing.net/fr/apprendre/operations/distorsions-du-suivi-et-de-la-mesure), sur les raisons pour lesquelles les ouvertures et les clics induisent en erreur
- [Réglage de la livraison par le MTA](https://emailmarketing.net/fr/apprendre/operations/reglage-de-la-livraison-par-le-mta)
- [Feedback loops de plaintes (RFC 6449)](https://emailmarketing.net/fr/apprendre/gestion-des-listes/feedback-loops-de-plaintes)
- [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation)