Passer au contenu principal
Les notifications décalées vous permettent de planifier des notifications pour qu’elles se déclenchent par rapport à une date connue (par exemple, la date de fin d’un engagement ou la date de création d’un contrat). Elles sont idéales pour concevoir des expériences proactives, centrées sur le client. Par exemple, envoyer un e-mail « crédits d’essai expirant bientôt » aux clients 7 jours avant leur date d’expiration pour encourager une adoption et une utilisation supplémentaires. Les montants de décalage peuvent être configurés en heures, jours, semaines, mois et années.

​
Types et charges utiles des notifications décalées

DIFFÉRENCES DE SCHÉMA DE CHARGE UTILELe schéma des charges utiles pour les notifications décalées diffère légèrement de celui des notifications de seuil. Plus précisément, la charge utile des notifications décalées n’inclut pas de champ properties. Assurez-vous que vos webhooks sont correctement configurés pour gérer les deux types de notifications.
Les notifications décalées peuvent être configurées autour de n’importe lequel des types de notifications système ci-dessus. Voici un exemple de charge utile pour les notifications décalées : 
{
  "id": "c9656215-3e96-59f4-7284-0021bdfd4c9a",
  "type": "contract.start",
  "timestamp": "2025-07-02T00:00:00Z",
  "environment_type": "PRODUCTION",
  "contract_id": "1bd74703-0854-4730-9549-893585c519e8",
  "contract_custom_fields": {
    "ContractType": "PayGo"
  },
  "customer_id": "eadab230-ef95-4c3c-d696-4391c205c982",
  "customer_custom_fields": {
    "CustomerType": "Tier2"
  },
  "offset_id": "8ed3d961-7b61-4c0a-8f2b-e546f45c33d6",
  "offset_duration": "-P3DT12H"
}
L’horodatage inclus dans la charge utile décalée est l’heure associée à l’événement source lui-même, et non au décalage. Par exemple, pour un décalage configuré pour se déclencher 3 jours après le début du contrat, l’horodatage sera l’heure de début du contrat elle-même, et non l’heure de début du contrat + 3 jours.

​
Activer et gérer les notifications décalées

Les notifications décalées peuvent être activées et gérées via l’interface utilisateur ou l’API.
Interface de création de notification décalée affichant la configuration de notification de fin de contrat
Dans l’interface utilisateur
  1. Accédez à l’onglet Notifications
  2. Cliquez sur Créer une notification
  3. Choisissez n’importe lequel des types de notifications système ci-dessus
  4. Configurez les détails du décalage (par exemple, 3 jours après le début du contrat, 60 jours avant la fin du segment d’engagement)
  5. Cliquez sur Enregistrer
  6. Vous commencerez à recevoir des notifications sur cet événement décalé pour tous les clients vers tous les webhooks configurés
  7. Assurez-vous que vos webhooks sont configurés pour gérer correctement les charges utiles de ces notifications.
Via l’API
  1. Appelez POST /v2/notifications/create
  2. Passez le nom du décalage et la politique de décalage, y compris le type d’événement système pour lequel vous souhaitez créer un décalage et le montant de décalage associé au format ISO-8601
  3. Une réponse réussie retournera les détails du décalage créé, y compris la configuration de notification avec son ID unique

​
Comportement du décalage par scénario

Lorsque vous activez une notification décalée, Metronome commence à générer des événements à partir de ce moment-là. Il ne revient pas en arrière pour créer des événements pour les données passées. Voir le tableau ci-dessous pour des exemples de scénarios dans lesquels les notifications décalées se déclencheront ou non.
ScénarioLa notification se déclenchera-t-elle ?Exemple
L’heure de décalage pour une entité existante est déjà dans le passé au moment de la création du décalageNonUn décalage credit.end - 3d est configuré le 20 mai, mais un crédit existant se termine le 22 mai. L’heure de déclenchement du décalage (19 mai) est déjà passée, donc rien n’est envoyé.
L’entité est créée mais l’heure de déclenchement du décalage est déjà dans le passéNonUn crédit est créé le 15 mai avec une date de fin du 30 mai. Un décalage correspondant (-30d) a été défini plus tôt. Comme le 1er mai est déjà passé, aucune notification n’est envoyée.
L’entité est modifiée et la nouvelle heure de déclenchement du décalage est dans le passéNonUn engagement se terminait initialement le 25 mai avec un décalage de -5d qui s’est déclenché le 20 mai. Le 22 mai, la date de fin est modifiée au 23 mai. L’heure de déclenchement du décalage (18 mai) est déjà passée, donc rien n’est envoyé.
Le décalage est archivé avant l’heure de déclenchementNonUn décalage contract.end - 1d est planifié pour se déclencher le 4 juin. La configuration du décalage est archivée le 2 juin. La notification ne se déclenche pas.
L’entité est créée après que la configuration du décalage est définieOui, si l’heure de déclenchement du décalage est toujours dans le futurUn décalage commit.end - 7d est configuré. Le 10 mai, un nouvel engagement est créé avec une date de fin du 20 mai. Une notification se déclenchera le 13 mai.

​
Mises en garde supplémentaires

Il existe quelques mises en garde supplémentaires pour des types de décalages spécifiques :
  • Les notifications décalées ne peuvent pas être configurées pour se déclencher avant les événements .create, .edit et .archive
  • Si vous avez configuré une notification décalée pour se déclencher avant commit.segment.start, il y a un cas limite à connaître lors de l’utilisation de ce type de décalage avec la fonctionnalité d’engagements récurrents de Metronome.
    • Pour les engagements récurrents, Metronome ne génère les engagements enfants suivants qu’au plus une période de facturation à l’avance. Cela signifie que si vous avez un décalage configuré pour se déclencher avant le début d’un segment d’engagement et que cette durée de décalage est plus longue qu’une période de facturation, la notification ne se déclenchera pas à l’heure planifiée. Au lieu de cela, elle se déclenchera au moment où le prochain engagement enfant est créé. Par exemple, vous avez configuré un engagement mensuel récurrent et configuré une notification décalée pour se déclencher 90 jours avant le début d’un segment d’engagement, le décalage pour cet engagement récurrent ne se déclenchera pas 90 jours avant le début du futur segment d’engagement enfant car l’engagement enfant n’existe pas encore. Au lieu de cela, il se déclenchera ~30 jours avant le début du futur segment d’engagement enfant au moment où le prochain engagement enfant est créé, car c’est à ce moment-là que la prochaine période de facturation devient disponible.