Skip to main content

Enveloppe

Tous les SDK envoient ce payload vers POST https://collector.reelevant.com/collect/{datasourceId}/rlvt :
La réponse est un 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.
Ci-dessus, 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 :
  • value est tronqué à deux décimales.
  • Une chaîne ids unique contenant ;, , ou | est découpée en plusieurs identifiants, sauf pour category_view et brand_view où 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