Présentation
Un custom fetcher est une couche de traitement optionnelle appliquée au-dessus de la récupération standard d’une Datasource. Au lieu de renvoyer les lignes stockées telles quelles, la Datasource exécute les données à travers une logique supplémentaire à chaque requête — les filtrant pour un seul utilisateur, restructurant les colonnes en lignes, excluant des produits ou calculant une agrégation. Les custom fetchers s’exécutent au moment de la requête, ils reflètent donc toujours les dernières données stockées et le contexte d’exécution (comme l’utilisateur pour lequel la personnalisation est effectuée). Cette page documente les custom fetchers génériques — ceux disponibles pour tout compte. Certains custom fetchers implémentent une logique spécifique à un client et ne sont pas couverts ici.Les custom fetchers ne disposent pas encore d’interface en libre-service. Ils sont configurés sur une Datasource par Reelevant. Contactez votre Technical Account Manager si vous souhaitez en activer un.
Modes de récupération
Une Datasource récupère les données selon l’un des trois modes, et chaque custom fetcher est conçu pour un ou plusieurs d’entre eux :
Le tableau récapitulatif ci-dessous indique quel mode s’applique à chaque custom fetcher générique.
Mise en place d’un custom fetcher
Il n’existe pas encore d’interface en libre-service pour les custom fetchers, ils sont donc configurés via l’API Datasources sur la version brouillon de la Datasource. La mise en place se fait en deux étapes : déclarer le fetcher avec l’étapeconfigure_fetcher, puis promouvoir la version avec l’étape validate.
Les deux appels nécessitent un jeton d’accès — consultez Authentification pour savoir comment en obtenir un.
payload.name est l’identifiant du fetcher (par ex. per-user, generic-unwind-rows, product-exclusion), et payload.params contient les champs de configuration documentés pour chaque fetcher ci-dessous. Pour les fetchers qui ne prennent aucune configuration, envoyez un objet vide : "params": {}.
L’étape
validate promeut la version brouillon en version live. Pour les Datasources pull-and-store, elle met également en file d’attente un job de vérification, de sorte que la nouvelle version ne passe en production qu’une fois ce job réussi.Per User
Restreint la Datasource de manière à ce qu’une requête ne renvoie que les enregistrements appartenant à l’utilisateur en cours de personnalisation. Il fonctionne sur tous les modes de récupération et cible automatiquement le champ identifiant utilisateur défini dans le Field Mapping (le champ utilisateur CRM, ou le champ utilisateur d’achat pour une Datasource d’achats). Lorsqu’une Datasource possède un champ timestamp, les résultats sont automatiquement triés du plus récent au plus ancien. Le fetcher expose également le champ locale résolu afin qu’un Workflow puisse lire la locale de l’utilisateur en plus des données. Ce custom fetcher ne nécessite aucune configuration.Utilisez-le sur les Datasources partagées (comme un CRM, des achats ou un flux analytique) où un Workflow ne doit voir que les lignes propres à l’utilisateur actif.
Unwind Rows
Restructure chaque ligne stockée en transformant ses colonnes en plusieurs lignes. Une colonne est conservée comme identifiant, et chaque autre colonne devient sa propre ligne, avec le nom de colonne original stocké dans un champ et la valeur de la cellule dans un autre.Configuration
Avant et après
Considérons une ligne stockée qui liste trois affinités de catégorie pour un utilisateur :
Avec source =
user, destination = user, et columnDestination = category, le fetcher la déplie en :
Le tri par le champ valeur est appliqué après le dépliage, vous pouvez donc classer les lignes produites par leur valeur numérique lorsque valueType est
number.Product Exclusion
Filtre une Datasource de produits par rapport à une seconde Datasource qui liste les éléments à conserver ou à supprimer. Un usage typique est de masquer les produits qu’un utilisateur a déjà achetés, ou de restreindre les recommandations à une liste autorisée.Configuration
Fonctionnement
- Le fetcher lit les IDs correspondants depuis la Datasource d’exclusion, en respectant tout filtre de requête applicable aux deux Datasources.
- En mode
exclusion, ces IDs sont retirés des résultats produits ; en modeinclusion, seuls ces IDs sont conservés. - En mode
inclusion, si la Datasource d’exclusion ne renvoie aucun ID, la requête produit ne retourne aucune ligne.
La liste d’exclusion est lue jusqu’à une limite configurée. Pour les listes très volumineuses, consultez votre Technical Account Manager concernant le seuil applicable.
Expired Product Lifetime
Fait remonter les produits qu’un utilisateur doit racheter, en se basant sur son historique d’achats et une durée de vie attendue du produit. Il joint la Datasource de produits actuelle avec une Datasource d’achats, calcule quand chaque produit précédemment acheté devrait être épuisé, et ne renvoie que les produits dont la prochaine date d’achat tombe dans une fenêtre configurée.Configuration
Chaque entrée dans temporalities décrit une fenêtre de rachat :
Fonctionnement
Le fetcher examine chaque produit que l’utilisateur a précédemment acheté et prédit quand il en aura à nouveau besoin. La manière dont la durée de vie est dérivée dépend du nombre de fois où l’utilisateur a acheté ce produit.- Il lit les achats de l’utilisateur (du plus récent au plus ancien) et regroupe les dates d’achat par référence produit.
- Pour chaque produit, il dérive une durée de vie attendue et une date de prochain achat attendue (voir les deux comportements ci-dessous).
- Il conserve le produit uniquement si la date du jour tombe dans la fenêtre de temporalité correspondante — de
windowStartjours avant la date de prochain achat àwindowEndjours après. - Les produits conservés sont enrichis avec
purchaseCount,lastPurchaseDateetnextPurchaseDate, et peuvent être triés par n’importe lequel de ces champs.
Comportement 1 — achat unique (consultation de la durée de vie)
Lorsque le produit a été acheté une seule fois, le fetcher ne peut pas mesurer un véritable intervalle de rachat, il lit donc la durée de vie attendue à partir du champ durée de vie propre au produit dans le Field Mapping. La date de prochain achat estlastPurchaseDate + durée de vie.
Exemple — un pack de capsules de café avec un champ durée de vie de 30 jours, acheté une fois le 1er mars, avec la fenêtre par défaut (windowStart 0, windowEnd 90) :
Le pack de capsules est renvoyé pour toute requête utilisateur exécutée entre le 31 mars et le 29 juin. Si le produit n’a pas de champ durée de vie, un produit à achat unique ne peut pas être évalué et est ignoré.
Comportement 2 — achats multiples (moyenne calculée)
Lorsque le produit a été acheté plusieurs fois, le fetcher ignore le champ durée de vie statique et calcule à la place l’intervalle moyen entre les achats consécutifs pour cet utilisateur spécifique. La date de prochain achat estlastPurchaseDate + intervalleMoyen.
Exemple — le même pack de capsules acheté le 1er janvier, le 1er février et le 1er mars, avec la fenêtre par défaut :
Utiliser la cadence propre à l’utilisateur rend la prédiction bien plus précise qu’une durée de vie statique unique. Si la moyenne calculée est inférieure à un jour, le produit est ignoré.
Lorsqu’aucune temporalities n’est configurée, une règle par défaut est appliquée : les produits avec une durée de vie allant jusqu’à 365 jours qui sont attendus dans les 90 prochains jours (
maxLifetime 365, windowStart 0, windowEnd 90).Proxy Lock
S’applique uniquement aux Datasources real-time proxy. Lorsque Reelevant reçoit de nombreuses requêtes simultanées qui déclencheraient le même appel amont, ce fetcher laisse le premier appel s’exécuter et fait attendre les autres brièvement, afin que le résultat puisse être servi depuis le cache au lieu de répéter l’appel.Configuration
Utilisez ceci pour protéger une API amont à débit limité ou coûteuse lorsqu’une seule diffusion génère de nombreux appels temps réel identiques.
Proxy Aggregation
S’applique uniquement aux Datasources real-time proxy. Après avoir récupéré la réponse en direct, il calcule une agrégation unique sur un champ choisi et ajoute le résultat à chaque ligne renvoyée.Configuration
Les valeurs non numériques et manquantes sont ignorées. Si aucune valeur numérique n’est trouvée, le champ de sortie est vide.
Pages associées
- Datasource Reference — construire des Datasources dérivées à partir de Datasources existantes.
- Configurations spéciales — autres types de Datasources calculées (Best Products, Merge, Cross-sell).
- Field Mapping — définir les champs qu’un custom fetcher lit et écrit.