Authentification et séparation des espaces clients
Les endpoints de lecture du tableau de bord exigent le cookie de session HttpOnly de l’utilisateur connecté. Les propriétaires dont l’adresse e-mail est vérifiée peuvent émettre des jetons bearer en lecture seule liés à un projet, affichés une seule fois et stockés sous forme d’empreintes, avec une expiration allant jusqu’à 90 jours. read:reports autorise summary/trend/search ; read:journeys autorise en plus la lecture des événements bruts et des parcours. Les jetons n’autorisent jamais l’accès au compte ni les modifications. Les propriétaires peuvent modifier leurs projets ; les Viewers vérifiés ayant accepté l’invitation peuvent lire les projets partagés, mais ne peuvent modifier ni réglages, ni facturation, ni connexions. Les identifiants de projet et les identifiants publics du traceur servent au routage, pas à l’authentification. Ne copiez pas une session de navigateur dans du code client public.
Les écritures API exigent JSON et des contrôles same-origin. Des origines de site autorisées exactes s’appliquent à la collecte publique. Les cookies sont Secure en production. Une session absente entraîne 401 ; les projets inaccessibles renvoient 404. Des paramètres de requête invalides renvoient 400.
Politique de navigation automatique
startPageviews({mode, routes, initial}) active explicitement l’automatisation des pages vues configurées. mode vaut history par défaut ou hash ; routes est un objet obligatoire contenant 1 à 50 chemins sûrs exacts ou préfixes terminés par /* associés à des libellés de page statiques sûrs. initial vaut true par défaut. stopPageviews() arrête uniquement l’automatisation de navigation ; consent(false) arrête toute collecte et efface le pseudonyme stocké.
Les opérations history pushState/replaceState et popstate ne sont observées qu’avec consentement. Le mode hash traite aussi les changements #/route. Les chaînes de requête sont ignorées pour l’identité de page ; les fragments ordinaires en mode history ne deviennent pas des pages. Une configuration équivalente répétée et les signaux de navigation en double n’ajoutent pas d’événements. L’appel manuel track(pageview) est indépendant : ne le combinez pas avec les pages vues automatiques pour une même visite.
GPC=true bloque l’octroi du consentement, les pages vues, les événements nommés et l’accès à l’identifiant du visiteur. Un nouveau signal GPC observé retire le suivi actif et interrompt les requêtes en attente lorsque cela est possible. Effacer GPC ne rétablit pas silencieusement le consentement. Il s’agit d’un comportement de l’implémentation, pas d’une affirmation de conformité juridique universelle.
Collecte du navigateur avec consentement
Le traceur n’accorde jamais automatiquement le consentement. Reliez accord et retrait à votre gestionnaire de consentement. Page est un libellé de chemin explicite non personnel ; aucune URL complète, requête de recherche ou fragment n’est collecté. Ne placez ni noms, ni identifiants de compte, ni jetons dans les libellés de chemin. Referrer, s’il est fourni, doit être un nom d’hôte ; device est une catégorie générale déclarée facultative, pas une empreinte numérique. Country n’est pas déduit des données du navigateur.
reylin.consent(true); // only after the visitor permits it
await reylin.track('pageview', {page:'/pricing', device:'desktop'});
await reylin.track('signup', {page:'/signup'});
// On withdrawal:
reylin.consent(false);Synthèse et entonnoir ordonné
GET /api/projects/:id/summary accepte days (1–366), currency (code ISO en majuscules), source, steps (noms séparés par des virgules) et conversionHours (1, 24 ou 168). Les jours se terminent à l’heure UTC actuelle. Utilisez page:/pricing pour des pages vues déclarées exactes ou page:/docs/* pour un préfixe sûr de chemin déclaré, combinés à des objectifs nommés et à $payment en dernière étape. Un entonnoir exige des horodatages strictement ordonnés ; toute entrée admissible peut commencer un parcours et chaque visiteur pseudonyme est compté une fois. Source s’applique à l’entrée. L’absence de consentement ou de lien avec le visiteur ne peut créer une conversion de paiement.
L’étape finale réservée $payment lit uniquement les paiements réussis du registre. Un événement du navigateur appelé purchase ou payment ne constitue jamais une preuve financière. Les remboursements n’effacent pas les conversions de paiements réussis. Les totaux de revenus utilisent les unités mineures entières du prestataire ; les devises ne sont jamais combinées ni converties implicitement.
Requêtes par dimension et pagination
GET /api/projects/:id/events accepte des horodatages ISO from/to (plage maximale de 366 jours), limit (1–1000), cursor, groupBy et filters sous forme de JSON encodé pour URL. Dimensions : source, type, page, referrer, country, device. Les valeurs manquantes sont Unknown, pas devinées. Opérateurs : is, is_not, contains, not_contains. Jusqu’à dix filtres se combinent avec AND ; la comparaison contains est insensible à la casse.
Omettez groupBy pour obtenir les événements individuels chronologiques ; définissez-le pour compter les événements et visiteurs distincts. Les réponses incluent les bornes normalisées from/to et nextCursor. Réutilisez exactement ces bornes et filtres pour les requêtes suivantes, car une borne de fin mobile modifie la requête. Les curseurs sont liés à la requête et ne sont pas des identifiants d’accès.
const query = new URLSearchParams({
from:'2026-10-01T00:00:00Z', to:'2026-10-31T23:59:59Z',
groupBy:'page', limit:'100',
filters:JSON.stringify([{dimension:'source',operator:'contains',value:'Google'}])
});
const response = await fetch('/api/projects/PROJECT_ID/events?' + query);Parcours de visiteurs pseudonymes
GET /api/projects/:id/journey accepte visitorId, from/to, limit et cursor. Il renvoie les événements consentis, les paiements réussis liés et les états de remboursement de ces paiements dans l’ordre chronologique. Il ne reconstitue ni personne, ni adresse e-mail, ni graphe d’appareils, ni identité intersites. Un visiteur absent renvoie un parcours vide plutôt qu’un historique inventé. Les montants de remboursement restent propres à chaque devise et leurs états restent visibles.
Sens de la connexion au prestataire et des imports
L’analyse Stripe des clients et votre abonnement Reylin sont des périmètres de confiance distincts. L’établissement d’une connexion vérifie le compte du prestataire, crée un brouillon avec un endpoint webhook stable, puis active le secret de signature chiffré. Les signatures valident les octets bruts transmis ; les montants sont rapprochés à partir de l’objet actuel du prestataire et dédupliqués.
L’import historique borné des paiements sur 7 ou 30 jours ne reconstitue ni les anciens visiteurs, ni tous les remboursements, ni les litiges. Les avertissements de couverture restent visibles. Les revenus d’un prestataire déconnecté sont indisponibles ; un nombre nul de paiements stockés ne prouve pas l’absence de ventes réelles. Le test de validation réelle du prestataire reste un prérequis de déploiement.
Les données de recherche ne sont pas des revenus
L’intégration Search Console fournit des rapports de recherche en lecture seule, avec autorisation distincte. Clics, impressions, CTR et position sont des métriques de recherche Google, pas des paiements ni des visiteurs uniques du site. Les bornes de date Google utilisent l’heure du Pacifique, contrairement à la fenêtre UTC des rapports d’événements. Les résultats de l’API peuvent omettre des lignes et renvoyer les principales ; une pagination bornée ne prouve jamais un export exhaustif. Le provisionnement OAuth et l’autorisation d’un compte réel exigent une intégration configurée séparément.
Configuration enregistrée et rapports calendaires
GET et POST /api/projects/:id/config/:kind prennent en charge segment, funnel, goal, note et preferences. Les mises à jour utilisent /:id et les suppressions utilisent POST {action: delete}. Seuls les propriétaires modifient les données. Les notes sont réservées au propriétaire ; les autres définitions enregistrées sont lisibles par les Viewers du partage. Les clés d’événement des objectifs ne peuvent changer ; les libellés ne réécrivent jamais l’historique des événements. Les préférences sont enregistrées explicitement et appliquées au rapport courant sur demande.
GET /api/projects/:id/trend accepte from, to, timezone, bucket hour/day/week/month, currency et compare=true. Sa fenêtre semi-ouverte [from,to) évite le double comptage aux limites. Les regroupements suivent les limites calendaires locales réelles, y compris les changements d’heure ; les semaines commencent le lundi. La comparaison avec la période précédente a la même durée écoulée, et une base nulle renvoie null pour la variation en pourcentage.
Abonnements clients et contrats récurrents
L’analyse des clients peut rapprocher les événements customer.subscription.created, customer.subscription.updated et customer.subscription.deleted. Seuls les identifiants d’abonnement sont conservés depuis les déclencheurs d’événements signés ; l’état actuel de l’abonnement est récupéré via le compte vérifié correspondant. Les instantanés d’abonnement ne créent jamais d’écritures d’encaissement dans le registre.
GET /api/projects/:id/subscriptions renvoie les montants mensuels récurrents contractuels bruts, séparés par devise, avant remises et taxes. Seuls les postes récurrents à prix fixe de type licensed sont inclus : les instantanés en pause, à l’usage, par paliers, transformés, inconnus ou périmés sont exclus avec des avertissements de couverture. Les équivalents d’essai sont séparés du MRR actif. L’agrégation rationnelle exacte est arrondie une seule fois par devise, au plus proche, les demi-unités vers le haut. La normalisation mois/année/semaine/jour est explicitement indiquée.
Les abonnements connus sont actualisés par lots bornés en arrière-plan. Une lecture échouée exclut immédiatement l’abonnement ; les instantanés de plus de 24 heures ne sont pas présentés comme actuels. Les propriétaires peuvent lancer une recherche reprenable dans Recurring contracts. Son achèvement signifie que les abonnements actuels disponibles ont été parcourus par pagination, pas que tous les cycles de vie historiques ou enregistrements changeants du prestataire ont été reconstitués. Cette découverte exige les permissions de lecture de la liste et du détail des abonnements.
Objectifs déclaratifs et files sûres
Après consentement explicite, data-reylin-event sur un élément cliquable envoie un objectif nommé par clic. data-reylin-view-event envoie une fois lorsque la moitié au moins de l’élément est visible, pour chaque accord de consentement. L’attribut facultatif data-reylin-page fournit un libellé de chemin sûr explicite. Les valeurs de formulaire, destinations des liens et textes du DOM ne sont jamais collectés. Le retrait déconnecte les observateurs et interrompt les requêtes en attente lorsque cela est pris en charge.
Les éléments mis en file avant chargement ou sans consentement sont abandonnés, pas rejoués plus tard. Après chargement, reylinQueue.push([track, eventName, dimensions]) n’envoie que si le consentement est actuellement true. Aucune page vue ni aucun consentement automatique n’est ajouté.
Sessions observées et recherche privée de visiteurs
GET /api/projects/:id/session-metrics présente une cohorte d’entrées de session dans [from,to). Les sessions regroupent les événements consentis par identifiant pseudonyme de navigateur, avec une séparation strictement supérieure à 30 minutes. L’historique antérieur stocké empêche la création artificielle d’une nouvelle session au seul début de la fenêtre d’un rapport ; la conservation et la suppression peuvent toutefois retirer les preuves de continuité.
Un rebond est une session close par inactivité avec exactement une page vue et aucun événement autre qu’une page vue. Les sessions ouvertes sont exclues du dénominateur du rebond. La durée moyenne observée est l’écart entre le premier et le dernier événement enregistré, pas le temps passé sur le site ni une estimation d’attention. La première page vue observée et le dernier libellé de page observé ne prouvent pas un véritable comportement d’arrivée ou de sortie. Les données manquantes sont Unknown, pas une géolocalisation ni un profil de navigateur inventé.
GET /api/projects/:id/visitors est privé et exige une session de projet ou un rôle Viewer, ou un jeton read:journeys. Il prend en charge source, eventType, customerStatus all/paid/unpaid, la recherche d’identifiant, limit et un curseur lié à la requête. Les filtres de source et de type d’événement doivent correspondre au même événement observé. Les nombres décrivent les événements observés de ce visiteur dans la fenêtre choisie. Paid signifie des paiements liés du registre dans cette même fenêtre ; les événements purchase du navigateur ne l’établissent pas. Les nombres de paiements sont séparés par devise.
Les métriques de session agrégées autorisent les jetons read:reports et n’incluent jamais d’identifiants individuels de visiteurs. Les lignes de visiteurs sont des observations pseudonymes, pas des personnes vérifiées, adresses e-mail, rapprochements d’identités ou profils CRM.
Dimensions d’acquisition et revenus figés
Les dimensions explicites d’événement peuvent inclure campaign, medium, content et term sous forme de slugs non personnels en minuscules de 64 caractères maximum, hostname comme nom d’hôte DNS, et des catégories générales de navigateur ou système d’exploitation. Ce sont des libellés déclarés : Reylin ne les déduit pas d’une empreinte numérique et ne capture pas automatiquement les requêtes de recherche brutes. Les dimensions manquantes restent Unknown. Les champs existants page, referrer et device restent pris en charge.
Les nouveaux paiements vérifiés figent l’instantané des dimensions du premier contact consenti dans la fenêtre d’attribution configurée. Un événement ultérieur, la suppression de l’historique des événements ou une modification des métadonnées du prestataire ne peuvent le réécrire. Les anciens paiements sans instantané de dimension restent Unknown pour cette dimension ; aucune attribution historique n’est fabriquée.
GET /api/projects/:id/acquisition accepte dimension, metric, from, to et currency. Il s’agit d’une lecture agrégée pour les sessions de projet, Viewers et jetons read:reports. Le rapport utilise une cohorte de paiements : paiements dans la fenêtre semi-ouverte et remboursements réussis admissibles avant sa fin, plafonnés par paiement. Ce n’est pas un rapport des mouvements de trésorerie liés aux remboursements. Les montants restent séparés par devise. La conversion exige un visiteur consenti observé dans le même groupe de dimension et la même fenêtre ; les ratios à dénominateur nul sont indisponibles, pas des zéros inventés.
Les rapports renvoient au plus 100 groupes triés, avec des nombres et totaux explicites pour les groupes omis. Les visiteurs peuvent apparaître dans plusieurs groupes de dimension ; la somme des visiteurs des groupes n’est donc pas nécessairement égale au nombre global de visiteurs uniques. Les segments de requêtes d’événements enregistrés prennent en charge les mêmes dimensions déclarées d’acquisition et de plateforme.
Propriétés catégorielles des objectifs
Les propriétaires déclarent d’abord dans Goal properties des schémas uniquement énumérés, par exemple signup → plan → starter ou growth. Les clés des schémas d’événement et de propriété sont en snake case minuscule, avec 32 caractères maximum ; au plus 20 schémas d’événement, 8 propriétés chacun et 20 valeurs par propriété. Les libellés sont de courts slugs minuscules, jamais des identifiants personnels ni des secrets. L’appartenance à une énumération ne prouve pas l’anonymat : le propriétaire du projet est responsable du caractère non personnel des libellés. Les clés ou valeurs inconnues sont rejetées avant stockage et consommation du quota.
Envoyez les propriétés en troisième argument du traceur, par exemple reylin.track("signup", {page:"/pricing"}, {plan:"starter"}). Le consentement est requis. Aucun texte du DOM ni aucune valeur de formulaire n’est collecté automatiquement. Le serveur valide avec le schéma actuel du projet. Les modifications de schéma affectent les événements futurs, pas les enregistrements historiques.
GET /api/projects/:id/goal-properties accepte eventType, property, from et to (fenêtre UTC semi-ouverte). Les catégories configurées et un groupe distinct de valeurs manquantes contiennent les nombres d’événements et de visiteurs uniques, jamais les identifiants de visiteurs. Les catégories historiques supprimées comptent dans excludedEvents/excludedVisitors sans reproduire leurs anciens libellés. Propriétaires, Viewers et jetons read:reports peuvent lire cet agrégat ; seuls les propriétaires peuvent utiliser GET/POST /property-schemas. Les propriétés brutes restent incluses dans les lectures d’événements à portée parcours.
Tâches de nettoyage des visiteurs par le propriétaire
GET /api/projects/:id/visitor-erasure liste les états filtrés des tâches de ce propriétaire ; ajoutez l’identifiant d’une tâche pour obtenir son état. Un POST sur la collection lance une tâche avec visitorId, un requestId aléatoire stable et retainFinancialRecords:true. Le pseudonyme brut du visiteur doit être placé dans le corps JSON, jamais dans une URL. Seules les sessions de propriétaires vérifiés sont autorisées ; les Viewers et jetons bearer API ne peuvent ni lancer ni consulter ces tâches.
Le même identifiant de requête et la même cible sont idempotents ; une cible contradictoire est rejetée. L’état public omet les empreintes de suppression et les jetons de workers. L’achèvement préserve les montants et l’attribution figée tout en supprimant le lien avec le pseudonyme connu ; ce n’est pas une garantie d’effacement juridique, physique ou chez le prestataire. Lisez le guide sur le cycle de vie des données et l’avertissement sur les données conservées avant utilisation.
La collecte et les écritures financières du projet concerné sont suspendues pendant l’exécution des barrières locales aux transactions et des lots reprenables. Les tâches attendant des envois incertains restent visiblement en attente. La conservation manuelle et la suppression de projet ou de compte ne peuvent s’exécuter en concurrence avec un nettoyage actif. Les limites de périmètre comprennent les anciens reçus non indexés, les notes et libellés rédigés par les utilisateurs, les copies externes et les sauvegardes.
Inventaire d’export des données du propriétaire
GET /api/account/data-export renvoie les sections locales prises en charge, les projections de champs, la disponibilité et les exclusions. Ajoutez section, éventuellement projectId d’un projet détenu, limit (1–100) et cursor pour lire une page. Le serveur déduit le propriétaire de la session authentifiée, jamais d’un identifiant de propriétaire fourni. Les rôles Viewer et les jetons API en lecture seule n’autorisent pas cette route au niveau du compte.
Le curseur est lié à la section, au propriétaire et au projet. Les lignes sont sélectionnées avec du SQL statique et des listes de champs JSON autorisés ; aucun paramètre arbitraire de base, table, chemin ou colonne n’existe. Un stockage absent ou dont le schéma est incompatible renvoie une couverture explicitement indisponible. Empreintes d’identifiants, textes chiffrés, jetons bruts et données internes des workers sont omis. Le résultat n’est ni un instantané atomique ni une affirmation d’exhaustivité universelle.
Rapports et alertes du propriétaire
Les propriétaires de projet peuvent activer un rapport hebdomadaire avec un jour et une heure UTC explicites et une devise, ou des alertes sur des événements nommés. Les messages vont uniquement à l’adresse e-mail vérifiée du compte ; aucun champ de destinataire arbitraire n’existe. Les nouvelles alertes d’objectif commencent au point de contrôle de réception du serveur : activer une règle ne rejoue donc jamais les événements antérieurs. Un événement tardif peut déclencher une alerte s’il arrive après l’activation de la règle. Les objectifs du navigateur ne prouvent pas des revenus.
La livraison est désactivée indépendamment par défaut. Les règles en simulation peuvent mettre des rapports en file, mais n’envoient aucun e-mail. Un message accepté signifie que le prestataire d’e-mail l’a accepté, pas qu’il est arrivé en boîte de réception. Les limites de file en attente et de livraison quotidienne du propriétaire suppriment les notifications excédentaires ; aucune surfacturation n’est créée. Disable all dans Reports & alerts annule les messages en file. Les messages précédemment acceptés ne peuvent pas être rappelés.
Seules les sessions du propriétaire peuvent accéder à /api/projects/:id/notifications. Les jetons bearer en lecture seule et les Viewers ne peuvent ni configurer les rapports ni lire la file privée. Les actions POST sont weekly, goal, remove_goal et unsubscribe.
Liens agrégés publics et widgets
Les propriétaires créent explicitement un partage dans les paramètres Sharing du projet. Toute personne détenant son URL donnant accès au partage peut uniquement lire les agrégats de visiteurs, événements, paiements, encaissements bruts, remboursés et nets, ainsi que la devise et la période. Aucune source, aucun visiteur, aucune note ni aucun enregistrement sous-jacent n’est inclus. Les liens et intégrations de widgets ne sont pas publiés automatiquement. La rotation ou la révocation invalide immédiatement l’ancienne URL, sans pouvoir effacer les copies déjà consultées.
La page partagée et le contenu intégré sont noindex et utilisent les en-têtes no-referrer/no-store. Le widget n’est intégrable dans une frame, par conception, qu’après création de cette capacité par un propriétaire. Les routes du tableau de bord privé restent non intégrables dans une frame. Un nombre agrégé nul de paiements dans le registre ne prouve pas qu’une entreprise réelle déconnectée n’a réalisé aucune vente.
SDK et CLI en lecture seule
reylin-client.mjs est un SDK côté serveur sans dépendance exposant summary/events/journey/trend/search. reylin-cli.mjs expose les mêmes opérations de lecture et affiche du JSON. Définissez REYLIN_API_TOKEN dans l’environnement, jamais dans les arguments de ligne de commande ni les bundles du navigateur. Les jetons ne peuvent modifier la facturation, les réglages des prestataires ou les comptes utilisateurs. Ces outils sources sont locaux ; aucun paquet de registre npm ni aucune connexion MCP tierce n’a été publié.
node reylin-cli.mjs summary --origin https://YOUR_APPROVED_HOST --project PROJECT_ID --days 30 --currency USDErreurs et traitement des données
Ne réessayez jamais une action facturable avec une nouvelle clé d’idempotence simplement parce que sa réponse a été perdue. Ne placez pas de secrets dans les chaînes de requête, les événements personnalisés ou les captures d’écran d’assistance. Les exports et parcours pseudonymes sont des données de projet authentifiées ; limitez leur accès et respectez les politiques de conservation et de suppression. Il n’existe aucune API publique de lecture analytique non authentifiée.
Références
Cette documentation décrit le code et ses limites ; elle ne confirme pas une connexion active. Les exemples techniques conservent leurs identifiants d’origine.