Enveloppe
Tous les SDK envoient ce payload versPOST https://collector.reelevant.com/collect/{datasourceId}/rlvt :
200 avec un corps vide. L’endpoint accepte également un tableau d’enveloppes et les corps application/x-www-form-urlencoded, tous traités par la même chaîne d’ingestion.
Champs réservés de data
Trois clés de data sont mappées vers des colonnes typées de la Datasource de tracking. Toutes les autres clés sont stockées comme labels interrogeables.
locale et store sont des labels : filtrables dans un Workflow, mais pas agrégés comme des métriques.
Catalogue d’événements
Les noms personnalisés sont acceptés tels quels et deviennent des valeurs de filtre sur le Data Node Website Events : gardez-les stables, renommer un événement rend orphelin l’historique collecté sous l’ancien nom.
Règles de validation
Le tracker web valide les payloads avant envoi et journalise la raison de son refus. Les SDK mobiles envoient ce que vous construisez : appliquez vous-même les mêmes règles.
Les valeurs de remplissage sont rejetées car elles résultent presque toujours d’une erreur de templating :
undefined, null, unknown, inconnu, 0, -1, NaN, ko, true, false, Infinity, -Infinity, {}, [].
Deux normalisations sont appliquées silencieusement, à connaître si vous comparez vos données avec celles de Reelevant :
valueest tronqué à deux décimales.- Une chaîne
idsunique contenant;,,ou|est découpée en plusieurs identifiants, sauf pourcategory_viewetbrand_viewoù les séparateurs font légitimement partie du nom.
Collecte serveur à serveur
Le collecteur accepte les appels directs : c’est l’intégration adaptée lorsque l’événement n’existe que sur votre backend — commande confirmée par votre prestataire de paiement, changement d’abonnement, achat en magasin. Envoyez la même enveloppe et réutilisez l’identité de la session de navigation (rlvt_clientId) pour que l’événement rejoigne l’historique de l’utilisateur :
tmpId est obligatoire : renseignez-le avec l’identité anonyme quand vous l’avez, sinon avec clientId. Envoyez timestamp explicitement dès que l’événement est rejoué ou traité de façon asynchrone — sinon le collecteur l’horodate à la réception.
Les appels serveur contournent les règles de validation côté client décrites plus haut : normalisez ids et value avant l’envoi. Le schéma complet est publié dans la référence OpenAPI Datasources Collector.
Ressources associées
- Vue d’ensemble de la collecte — chaîne de traitement, identité, consentement
- Collecte web — tag, Google Tag Manager, API
window.reel - Collecte mobile — Android, iOS, Flutter
- Filtres de requête Datasource — interroger directement les événements collectés