> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.onesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Opérateurs Temporels
> Les Opérateurs Temporels vous permettent d'envoyer des messages relatifs à un moment spécifique dans le temps—comme après qu'une action se produise ou avant une date à venir.
## Aperçu
Les Opérateurs Temporels vous permettent d'envoyer des messages relatifs à un moment spécifique dans le temps—comme **après qu'une action se produise** ou **avant une date à venir**.
Vous stockez ce moment comme un **horodatage Unix (en secondes)** sur l'utilisateur en utilisant un **Tag**. OneSignal compare ensuite le temps actuel à cet horodatage et vous permet de cibler les utilisateurs selon le temps qui s'est écoulé (ou le temps restant).
Cela facilite l'automatisation de messages comme les rappels, les suivis et les échéances sans programmer manuellement les messages.
**Cas d'utilisation courants :**
* **[Panier abandonné](./abandoned-cart)** : Rappeler aux utilisateurs qui n'ont pas finalisé leur commande après un certain temps
* **Rappels d'événements** : Envoyer des messages aux utilisateurs avant un rendez-vous programmé ou une date de renouvellement
* **Jalons** : Effectuer un suivi quand les utilisateurs n'ont pas terminé une action avant une échéance
* **Anniversaires** : Envoyer des messages automatiques le (ou autour du) jour d'anniversaire d'un utilisateur
Les Opérateurs Temporels ne sont disponibles que sur les plans payants. Les plans gratuits peuvent toujours utiliser les filtres de segments temporels par défaut comme Première Session et Dernière Session.
### Quand devrais-je utiliser ceci ?
Utilisez les Opérateurs Temporels quand vous voulez :
* Envoyer des messages **relatifs à un événement**, pas à un moment de calendrier fixe
* Créer des **fenêtres temporelles mobiles** (par exemple, "24–48 heures après")
* Réutiliser la même logique pour de nombreux utilisateurs avec des dates différentes
* Évaluer continuellement l'éligibilité au fil du temps
Si vous devez déclencher des messages immédiatement quand un événement se produit, considérez utiliser les **[Événements Personnalisés](./custom-events)** à la place.
### Tags vs Événements Personnalisés
Vous pouvez résoudre de nombreux cas d'utilisation de "rappels" avec soit les **Tags** soit les **Événements Personnalisés**. La meilleure option dépend de ce que vous devez stocker et comment vous voulez déclencher l'automatisation.
* Utilisez les **Tags** quand vous voulez stocker le **dernier horodatage connu** (par exemple, `cart_updated_at` ou `subscription_expires_at`) sur l'utilisateur et segmenter basé sur cette valeur au fil du temps.
* Utilisez les **Événements Personnalisés** quand vous voulez enregistrer **chaque occurrence d'événement** (avec des propriétés) et déclencher des Journeys basés sur le comportement en temps réel.
En pratique, de nombreuses implémentations peuvent utiliser les deux : Événements Personnalisés pour le suivi en temps réel et Tags pour l'état utilisateur que vous voulez segmenter plus tard.
Les [Tags](/docs/en/add-user-data-tags) et les [Événements personnalisés](/docs/en/custom-events) sont tous deux des moyens d'ajouter des données à vos utilisateurs. Cependant, il existe quelques différences clés :
| Fonctionnalité | Tags | Événements personnalisés |
| ----------------------- | :-------------------------------------------: | :-----------------------------------------------------------------------------------------------------: |
| Utilisation des données | Segmentation et personnalisation | Déclencher des Journeys sans Segment, étapes Wait Until, personnalisation directement dans les Journeys |
| Rétention des données | À vie | 30+ jours ([stockage à vie disponible](/docs/en/billing-faq#streaming-events)) |
| Format des données | Chaînes ou nombres clé-valeur | JSON |
| Source des données | SDK OneSignal, API ou intégrations (limitées) | SDK OneSignal, API ou intégrations |
| Accès aux données | Segmentation et personnalisation des messages | Personnalisation des Journeys et des modèles de messages Journey, Segmentation (Prochainement) |
La distinction clé entre les Tags et les Événements personnalisés réside dans leur profondeur et leurs cas d'utilisation. Les tags sont des propriétés d'un utilisateur, telles que le Nom, le Statut du compte ou l'Emplacement. Les événements sont des choses que l'utilisateur a faites, comme Acheter un article, Terminer un niveau ou Inviter un ami. Les tags et les événements peuvent tous deux être utilisés pour la segmentation et la personnalisation.
En pratique, vous utiliserez probablement les deux :
* Les tags pour les propriétés utilisateur qui sont statiques et ne changent pas souvent
* Les événements personnalisés pour les scénarios en temps réel, la segmentation complexe et les flux de travail de parcours plus sophistiqués
***
## Référence rapide
1. Convertissez la date de l'événement en horodatage Unix en **secondes**.
2. Définissez un [Tag](./add-user-data-tags) où la clé est le nom de l'événement et la valeur est l'horodatage comme **chaîne** (ex., `'event_date': '1739145600'`).
3. Créez un segment utilisant l'opérateur **Time Elapsed Greater Than** :
* Après une date passée en utilisant l'opérateur **Time Elapsed Greater Than** avec une valeur positive
* Avant une date future en utilisant l'opérateur **Time Elapsed Greater Than** avec une valeur négative
Une erreur courante est de définir des horodatages en **millisecondes** (13 chiffres) au lieu de **secondes** (10 chiffres). Les Opérateurs Temporels nécessitent des **secondes**.
***
## Envoyer des messages après un événement passé
Utilisez ce modèle quand vous voulez envoyer des messages aux utilisateurs **après qu'un certain temps se soit écoulé** depuis qu'un événement s'est produit.
**Exemple : Rappel de panier abandonné 24 heures après que l'utilisateur ait mis à jour son panier**
Quand l'utilisateur met à jour son panier, sauvegardez le temps actuel comme horodatage Unix (en secondes) :
```javascript theme={null}
// Exemple SDK
const timestampSeconds = String(Math.floor(Date.now() / 1000));
OneSignal.User.addTag("cart_updated_at", timestampSeconds);
```
Utilisez les secondes (10 chiffres), pas les millisecondes (13 chiffres).
1. Allez à **Audience** > **Segments**
2. Ajoutez un filtre **User Tag**
3. Définissez **Key** à `cart_updated_at`
4. Choisissez **Time Elapsed Greater Than**
5. Définissez **Value** à `1` jour (ou `24` heures ou `86400` secondes)
Sans limite supérieure, les utilisateurs restent dans le segment pour toujours. Ajoutez un second filtre pour créer une fenêtre :
* **Time Elapsed Greater Than** `24` heures
* **Time Elapsed Less Than** `48` heures
Maintenant les utilisateurs ne sont dans le segment qu'entre 24-48 heures après l'événement.
Créez un [Journey](./journeys-overview) qui cible votre segment pour automatiser la messagerie.
***
## Envoyer des messages avant un événement futur
Utilisez ce modèle pour envoyer des messages aux utilisateurs **avant une date future**, comme un rendez-vous ou un renouvellement.
1. Stockez la date future comme tag d'horodatage Unix (ex., `'future_date': '1739145600'`)
2. Créez un segment avec **Time Elapsed Greater Than** et votre temps d'entrée désiré comme valeur négative
* Exemple : `-2` jours (ou `-172800` secondes)
3. Ajoutez une limite supérieure en utilisant le même opérateur **Time Elapsed Greater Than** avec une valeur négative d'un temps plus proche
* Exemple : `-1` jour (ou `-86400` secondes)
### Exemple : Messages d'anniversaire
Envoyez des messages d'anniversaire en stockant le **prochain anniversaire à venir** de chaque utilisateur comme horodatage.
Calculez et stockez le prochain anniversaire de l'utilisateur :
```javascript theme={null}
function getNextBirthday(month, day) {
// month: 0-11 (Jan=0), day: 1-31
const now = new Date();
let birthday = new Date(now.getFullYear(), month, day);
if (birthday <= now) {
birthday = new Date(now.getFullYear() + 1, month, day);
}
return String(Math.floor(birthday.getTime() / 1000));
}
// Exemple : anniversaire du 15 janvier
OneSignal.User.addTag("birthday", getNextBirthday(0, 15));
```
* **User Tag** : `birthday`
* **Time Elapsed Greater Than** : `0` secondes
Les utilisateurs entrent dans le segment une fois que leur horodatage d'anniversaire passe.
1. Créez un [Journey](./journeys-overview) ciblant votre segment d'anniversaire
2. Définissez la ré-entrée à **52 semaines** pour que les utilisateurs puissent ré-entrer l'année suivante
3. Mettez à jour le tag `birthday` vers la date de l'année suivante après envoi (dans votre backend ou Journey)
Calculez les horodatages d'anniversaire en utilisant le fuseau horaire local de l'utilisateur quand c'est possible. Utiliser seulement l'heure du serveur peut causer l'envoi des messages plus tôt ou plus tard que prévu.
Si vous voulez que les messages restent précis d'année en année, mettez à jour le tag `birthday` de l'utilisateur vers le prochain anniversaire à venir après avoir envoyé le message (par exemple, dans votre backend ou dans une étape Journey). Gardez à l'esprit que si vous faites cela, il pourrait être plus facile d'utiliser les [Événements Personnalisés](./custom-events) à la place.
Les messages d'anniversaire seront envoyés aux utilisateurs autour de leur date de tag `birthday`.
***
## FAQ
### Comment fonctionne les mathématiques ? (détails techniques)
Les Opérateurs Temporels existent pour vous permettre de créer des **fenêtres relatives et mobiles** au lieu de dates fixes.
OneSignal calcule le temps écoulé en utilisant cette formule :
```
time_elapsed = current_time - tag_timestamp
```
* **Horodatages passés** → valeurs positives
* **Horodatages futurs** → valeurs négatives
**Opérateurs :**
* `Time Elapsed Greater Than X` : correspond quand `elapsed > X`
* `Time Elapsed Less Than X` : correspond quand `elapsed < X`
**Pourquoi les horodatages futurs correspondent immédiatement avec `Less Than` :**
N'importe quel nombre négatif est inférieur à n'importe quel nombre positif. Donc `time_elapsed_lt 2 days` (172,800 secondes) correspondra à un horodatage 30 jours dans le futur parce que :
```
-2,592,000 < 172,800 → true (correspond)
```
Puisque les horodatages futurs produisent toujours un temps écoulé négatif, **vous devez utiliser des valeurs négatives** pour définir quand les utilisateurs doivent entrer et sortir des segments avant un événement à venir. Les valeurs positives ne peuvent pas représenter le temps *avant* une date future.
### Comment puis-je tester ?
1. Trouvez votre utilisateur via l'ID Externe, l'ID d'Abonnement, l'Email ou le numéro de téléphone. Voir [Trouver et définir des abonnements de test](./test-users) pour les détails sur comment trouver votre utilisateur.
2. Obtenez un horodatage en secondes de la date actuelle et d'une date future (5 minutes à partir de maintenant).
3. Définissez deux tags avec les clés 'current\_time' et 'future\_time' et les valeurs comme horodatages en secondes.
4. Créez un segment `current_time` avec les filtres suivants :
* **User Tag** : `current_time` **Time Elapsed Greater Than** : `2` minutes
* ET **User Tag** : `current_time` **Time Elapsed Less Than** : `5` minutes
5. Créez un segment `future_time` avec les filtres suivants :
* **User Tag** : `future_time` **Time Elapsed Greater Than** : `-5` minutes
* ET **User Tag** : `future_time` **Time Elapsed Less Than** : `-2` minutes
Vous devriez voir votre utilisateur :
* Entrer dans le segment `current_time` 2 minutes après la date de temps actuel et sortir du segment 5 minutes après la date de temps actuel.
* Entrer dans le segment `future_time` 5 minutes avant la date de temps futur et sortir du segment 2 minutes avant la date de temps futur.
***