Authentifizierung und Mandantengrenzen
Leseendpunkte des Dashboards benötigen das HttpOnly-Sitzungscookie eines angemeldeten Nutzers. Inhaber mit verifizierter E-Mail-Adresse können projektgebundene schreibgeschützte Bearer-Tokens ausstellen, die einmal angezeigt, als Hashes gespeichert und mit bis zu 90 Tagen Laufzeit versehen werden. read:reports erlaubt summary/trend/search; read:journeys zusätzlich das Lesen von Rohereignissen und Besucherpfaden. Tokens erlauben niemals Kontozugriff oder Änderungen. Inhaber können ihre eigenen Projekte ändern; verifizierte und angenommene Viewer können freigegebene Projekte lesen, aber weder Einstellungen noch Abrechnung oder Verbindungen ändern. Projekt-IDs und öffentliche Tracker-IDs dienen dem Routing, nicht der Authentifizierung. Kopiere keine Browser-Sitzung in öffentlichen Client-Code.
API-Schreibzugriffe erfordern JSON und Same-Origin-Prüfungen. Für öffentliche Erfassung gelten exakt erlaubte Website-Origins. Cookies sind in Produktion mit Secure versehen. Eine fehlende Sitzung ergibt 401; nicht zugängliche Projekte ergeben 404. Ungültige Abfragesteuerungen liefern 400.
Regeln für automatische Navigation
startPageviews({mode, routes, initial}) aktiviert ausdrücklich die Automatisierung zugeordneter Seitenaufrufe. mode ist history (Standard) oder hash; routes ist ein erforderliches Objekt mit 1–50 exakten sicheren Pfaden oder Präfixen mit abschließendem /*, die statischen sicheren Seitenbezeichnungen zugeordnet sind. initial ist standardmäßig true. stopPageviews() stoppt nur die Navigationsautomatisierung; consent(false) stoppt jede Erfassung und löscht das gespeicherte Pseudonym.
History-pushState/replaceState und popstate werden nur bei erteilter Einwilligung beobachtet. Der Hash-Modus verarbeitet zusätzlich #/route-Änderungen. Query-Strings werden bei der Seitenidentität ignoriert; gewöhnliche History-Fragmente werden nicht zu Seiten. Wiederholte gleichwertige Konfigurationen und doppelte Navigationssignale erzeugen keine zusätzlichen Ereignisse. Manuelles track(pageview) ist unabhängig; kombiniere es daher nicht mit automatischen Seitenaufrufen für denselben Besuch.
GPC=true blockiert Einwilligungserteilungen, Seitenaufrufe, benannte Ereignisse und Besucher-ID-Zugriff. Ein neu erkanntes GPC-Signal widerruft aktives Tracking und bricht ausstehende Anfragen nach Möglichkeit ab. Das Aufheben von GPC stellt die Einwilligung nicht stillschweigend wieder her. Dies beschreibt das Implementierungsverhalten und behauptet keine allgemeingültige Rechtskonformität.
Browser-Erfassung mit Einwilligung
Der Tracker erteilt niemals automatisch eine Einwilligung. Verbinde Einwilligung und Widerruf mit deiner Einwilligungsverwaltung. Page ist eine ausdrückliche nicht personenbezogene Pfadbezeichnung; weder vollständige URL noch Suchanfrage oder Fragment werden erfasst. Trage keine Namen, Konto-IDs oder Tokens in Pfadbezeichnungen ein. Referrer muss, falls angegeben, ein Hostname sein; device ist eine optionale grobe angegebene Kategorie, kein Fingerprinting. Country wird nicht aus Browsereingaben abgeleitet.
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);Zusammenfassung und geordneter Trichter
GET /api/projects/:id/summary akzeptiert days (1–366), currency (ISO-Code in Großbuchstaben), source, steps (kommagetrennte Namen) und conversionHours (1, 24 oder 168). Die Tage enden zur aktuellen UTC-Zeit. Verwende page:/pricing für exakte deklarierte Seitenaufrufe oder page:/docs/* für ein sicheres deklariertes Pfadpräfix, gemischt mit benannten Zielen und abschließendem $payment. Ein Trichter verlangt streng geordnete Zeitstempel; jeder geeignete Einstieg kann einen Pfad beginnen, und jeder pseudonyme Besucher wird einmal gezählt. Source gilt für den Einstieg. Fehlende Einwilligung oder Besucher-Verknüpfung können keine Zahlungs-Conversion erzeugen.
Der reservierte abschließende Schritt $payment liest ausschließlich erfolgreiche Zahlungen aus dem Zahlungsjournal. Ein Browser-Ereignis namens purchase oder payment ist niemals ein Finanzbeleg. Erstattungen löschen keine Conversions erfolgreicher Zahlungen. Umsatzsummen verwenden ganzzahlige kleinere Währungseinheiten des Anbieters; Währungen werden niemals zusammengeführt oder implizit umgerechnet.
Dimensionsabfragen und Seitennavigation
GET /api/projects/:id/events akzeptiert from/to als ISO-Zeitstempel (maximal 366 Tage), limit (1–1000), cursor, groupBy und filters als URL-kodiertes JSON. Dimensionen: source, type, page, referrer, country, device. Fehlende Werte sind Unknown und werden nicht geschätzt. Operatoren: is, is_not, contains, not_contains. Bis zu zehn Filter werden mit AND verbunden; contains unterscheidet nicht zwischen Groß- und Kleinschreibung.
Lasse groupBy für chronologisch geordnete Einzelereignisse weg; setze es für Ereignis- und eindeutige Besucherzahlen. Antworten enthalten die normalisierten from/to-Grenzen und nextCursor. Verwende in Folgeanfragen genau diese Grenzen und Filter erneut, da ein wandernder Endzeitpunkt die Abfrage ändert. Cursor sind an die Abfrage gebunden, keine Zugangsdaten.
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);Pseudonyme Besucherpfade
GET /api/projects/:id/journey akzeptiert visitorId, from/to, limit und cursor. Es liefert mit Einwilligung erfasste Ereignisfakten, verknüpfte erfolgreiche Zahlungen und deren Erstattungszustände in chronologischer Reihenfolge. Es ermittelt weder eine Person noch E-Mail-Adresse, Gerätegraph oder websiteübergreifende Identität. Ein fehlender Besucher liefert einen leeren Pfad statt erfundener Historie. Erstattungsbeträge bleiben währungsspezifisch und Zustände sichtbar.
Bedeutung von Anbieteranbindung und Import
Stripe-Kundenanalysen und dein Reylin-Abonnement haben getrennte Vertrauensgrenzen. Die Verbindungseinrichtung verifiziert das Anbieterkonto, erstellt einen Entwurf mit stabilem Webhook-Endpunkt und aktiviert anschließend das verschlüsselte Signaturgeheimnis. Signaturen prüfen die unveränderten Zustellungsbytes; Geldbeträge werden anhand des aktuellen Anbieterobjekts abgeglichen und dedupliziert.
Der auf 7 oder 30 Tage begrenzte historische Zahlungsimport rekonstruiert weder historische Besucher noch jede Erstattung oder Streitfälle. Hinweise zur Abdeckung bleiben sichtbar. Nicht angebundene Einnahmen sind nicht verfügbar; null gespeicherte Zahlungen beweisen nicht null tatsächliche Verkäufe. Der reale Anbieter-Abnahmetest bleibt eine Bereitstellungsvoraussetzung.
Suchdaten sind keine Einnahmen
Die Search-Console-Integration ist eine getrennt autorisierte, schreibgeschützte Suchberichterstattung. Klicks, Impressionen, CTR und Position sind Google-Suchkennzahlen, keine Zahlungen oder eindeutigen Website-Besucher. Googles Datumsgrenzen richten sich nach Pacific Time, anders als das UTC-Fenster der Ereignisberichte. API-Ergebnisse können Zeilen auslassen und nur führende Zeilen liefern; begrenzte Seitennavigation beweist niemals einen vollständigen Export. OAuth-Bereitstellung und echte Kontoautorisierung benötigen eine separat konfigurierte Integration.
Gespeicherte Konfiguration und Kalenderberichte
GET und POST /api/projects/:id/config/:kind unterstützen segment, funnel, goal, note und preferences. Aktualisierungen verwenden /:id, Löschungen POST {action: delete}. Nur Inhaber ändern Daten. Notizen sind nur für Inhaber; andere gespeicherte Definitionen können freigegebene Viewer lesen. Ziel-Ereignisschlüssel sind unveränderlich; Anzeigebezeichnungen schreiben niemals Ereignisverläufe um. Einstellungen werden ausdrücklich gespeichert und auf Anfrage auf den aktuellen Bericht angewandt.
GET /api/projects/:id/trend akzeptiert from, to, timezone, bucket hour/day/week/month, currency und compare=true. Das halboffene Fenster [from,to) verhindert Doppelzählungen an Grenzen. Intervalle folgen tatsächlichen lokalen Kalendergrenzen einschließlich Sommerzeitwechseln; Wochen beginnen montags. Der Vorperiodenvergleich hat dieselbe verstrichene Dauer; bei einem Ausgangswert von null liefert die prozentuale Änderung den JSON-Wert null, nicht null Prozent.
Kundenabonnements und wiederkehrende Verträge
Kundenanalysen können Ereignisse customer.subscription.created, customer.subscription.updated und customer.subscription.deleted abgleichen. Aus signierten Ereignisauslösern bleiben nur Abonnement-IDs erhalten; der aktuelle Abonnementstatus wird über das passende verifizierte Konto abgerufen. Abonnement-Snapshots erzeugen niemals Zahlungseingänge im Zahlungsjournal.
GET /api/projects/:id/subscriptions liefert vertragliche monatlich wiederkehrende Bruttobeträge, getrennt nach Währung und vor Rabatten und Steuern. Unterstützt werden nur feste lizenzierte wiederkehrende Positionen: pausierte, verbrauchsabhängige, gestaffelte, transformierte, unbekannte und veraltete Snapshots werden mit Abdeckungshinweisen ausgeschlossen. Testphasenäquivalente bleiben von aktivem MRR getrennt. Eine exakte rationale Aggregation wird einmal je Währung kaufmännisch (half-up) gerundet. Die Normalisierung von Monat/Jahr/Woche/Tag wird ausdrücklich ausgewiesen.
Bekannte Abonnements werden in begrenzten Hintergrundstapeln aktualisiert. Fehlgeschlagene Lesezugriffe schließen das betreffende Abonnement sofort aus; Snapshots älter als 24 Stunden werden nicht als aktuell gemeldet. Inhaber können unter Recurring contracts einen fortsetzbaren Ermittlungslauf starten. Abschluss bedeutet, dass verfügbare aktuelle Abonnements seitenweise durchlaufen wurden, nicht dass jeder historische Lebenszyklus oder veränderte Anbieterdatensatz rekonstruiert wurde. Die Ermittlung erfordert Leseberechtigung für Abonnementauflistung und -abruf.
Deklarative Ziele und sichere Warteschlangen
Nach ausdrücklicher Einwilligung sendet data-reylin-event auf einem anklickbaren Element pro Klick ein benanntes Ziel. data-reylin-view-event sendet pro Einwilligung einmal, sobald mindestens die Hälfte des Elements sichtbar ist. Optional liefert data-reylin-page eine ausdrückliche sichere Pfadbezeichnung. Formularwerte, Linkziele und DOM-Text werden niemals abgegriffen. Ein Widerruf trennt Beobachter und bricht ausstehende Anfragen ab, soweit unterstützt.
Warteschlangeneinträge vor dem Laden und bei verweigerter Einwilligung werden verworfen, nicht später erneut abgespielt. Nach dem Laden sendet reylinQueue.push([track, eventName, dimensions]) nur, solange die Einwilligung aktuell true ist. Weder ein automatischer Seitenaufruf noch automatische Einwilligung werden hinzugefügt.
Beobachtete Sitzungen und private Besuchersuche
GET /api/projects/:id/session-metrics berichtet über eine Kohorte von Sitzungseinstiegen innerhalb [from,to). Sitzungen gruppieren mit Einwilligung erfasste Ereignisse nach pseudonymer Browser-ID und einer Lücke von strikt mehr als 30 Minuten. Gespeicherter Vorverlauf verhindert eine künstliche neue Sitzung nur deshalb, weil ein Berichtsfenster beginnt; Aufbewahrung und Löschung können Kontinuitätsbelege dennoch entfernen.
Ein Absprung ist eine durch Inaktivität abgeschlossene Sitzung mit genau einem Seitenaufruf und ohne andere Ereignisse. Offene Sitzungen sind vom Nenner der Absprungrate ausgeschlossen. Die mittlere beobachtete Spanne ist der Unterschied zwischen erstem und letztem erfasstem Ereignis, keine Verweildauer oder Aufmerksamkeitsschätzung. Erster beobachteter Seitenaufruf und letzte beobachtete Seitenbezeichnung beweisen kein tatsächliches Einstiegs- oder Ausstiegsverhalten. Fehlende Daten sind Unknown, keine Geolokalisierung und kein erfundenes Browserprofil.
GET /api/projects/:id/visitors ist privat und erfordert eine Projektsitzung, einen Viewer oder ein read:journeys-Token. Unterstützt werden source, eventType, customerStatus all/paid/unpaid, Kennungssuche, limit und abfragegebundener cursor. Quellen- und Ereignistypfilter müssen auf dasselbe beobachtete Ereignis zutreffen. Zählungen beschreiben die beobachteten Ereignisse dieses Besuchers im gewählten Fenster. Paid bedeutet verknüpfte Journalzahlungen im selben Fenster; purchase-Ereignisse im Browser begründen diesen Status nicht. Zahlungszahlen werden pro Währung getrennt.
Aggregierte Sitzungskennzahlen erlauben read:reports-Tokens und enthalten niemals individuelle Besucher-IDs. Besucherzeilen sind pseudonyme Beobachtungen, keine verifizierten Personen, E-Mail-Adressen, Identitätsabgleiche oder CRM-Profile.
Akquisitionsdimensionen und festgeschriebene Einnahmen
Ausdrückliche Ereignisdimensionen können campaign, medium, content und term als nicht personenbezogene kleingeschriebene Slugs mit bis zu 64 Zeichen, hostname als DNS-Hostname sowie grobe Browser-/Betriebssystemkategorien enthalten. Es sind deklarierte Bezeichnungen: Reylin leitet sie nicht aus einem Fingerprint ab und erfasst keine rohen Suchanfragen automatisch. Fehlende Dimensionen bleiben Unknown. Die bestehenden Felder page, referrer und device bleiben unterstützt.
Neue verifizierte Zahlungsdatensätze schreiben den mit Einwilligung erfassten Dimensionsstand des ersten Kontakts innerhalb des konfigurierten Zuordnungsfensters fest. Ein späteres Ereignis, gelöschter Ereignisverlauf oder geänderte Anbietermetadaten können ihn nicht überschreiben. Ältere Zahlungen ohne Dimensions-Snapshot bleiben für diese Dimension Unknown; historische Zuordnung wird nicht erfunden.
GET /api/projects/:id/acquisition akzeptiert dimension, metric, from, to und currency. Es ist ein aggregierter Lesezugriff für Projektsitzungen, Viewer und read:reports-Tokens. Der Bericht verwendet eine Zahlungskohorte: Zahlungen innerhalb des halboffenen Fensters und ihre zulässigen erfolgreichen Erstattungen vor dessen Ende, begrenzt je Zahlung. Er ist kein Bericht über tatsächliche Erstattungs-Geldbewegungen. Geldbeträge bleiben je Währung getrennt. Conversion erfordert einen beobachteten Besucher mit Einwilligung im selben Dimensionsintervall und Zeitfenster; Verhältnisse mit Nenner null sind nicht verfügbar, keine erfundenen Nullwerte.
Berichte liefern höchstens 100 sortierte Gruppen sowie ausdrückliche Anzahlen und Summen ausgelassener Gruppen. Besucher können in mehreren Dimensionsgruppen vorkommen; die Summe der Besucher je Gruppe muss daher nicht der global eindeutigen Besucherzahl entsprechen. Gespeicherte Ereignisabfragesegmente unterstützen dieselben deklarierten Akquisitions- und Plattformdimensionen.
Kategorische Zieleigenschaften
Inhaber deklarieren zuerst reine Enum-Schemata unter Goal properties, zum Beispiel signup → plan → starter oder growth. Ereignis- und Eigenschaftsschemaschlüssel verwenden kleingeschriebenes snake_case mit bis zu 32 Zeichen; höchstens 20 Ereignisschemata, jeweils 8 Eigenschaften und 20 Werte pro Eigenschaft. Bezeichnungen sind kurze kleingeschriebene Slugs, niemals Personenkennungen oder Geheimnisse. Die Zugehörigkeit zu einem Enum beweist keine Anonymität: Der Projektinhaber ist für nicht personenbezogene Bezeichnungen verantwortlich. Unbekannte Schlüssel oder Werte werden vor Speicherung und Kontingentverbrauch abgelehnt.
Sende Eigenschaften als drittes Tracker-Argument, zum Beispiel reylin.track("signup", {page:"/pricing"}, {plan:"starter"}). Einwilligung ist erforderlich. DOM-Text und Formularwerte werden nicht automatisch erfasst. Der Server validiert gegen das aktuelle Schema dieses Projekts. Schemaänderungen betreffen zukünftige Ereignisse, keine historischen Datensätze.
GET /api/projects/:id/goal-properties akzeptiert eventType, property, from und to (halboffenes UTC-Fenster). Konfigurierte Kategorien und eine eigene Gruppe für fehlende Werte enthalten Ereignis- und eindeutige Besucherzahlen, niemals Besucher-IDs. Entfernte historische Kategorien zählen als excludedEvents/excludedVisitors, ohne entfernte Bezeichnungen wiederzugeben. Inhaber, Viewer und read:reports-Tokens können dieses Aggregat lesen; nur Inhaber dürfen GET/POST /property-schemas verwenden. Rohe Eigenschaften bleiben Teil der auf Besucherpfade begrenzten Ereignis-Lesezugriffe.
Besucherbereinigungsaufträge für Inhaber
GET /api/projects/:id/visitor-erasure listet die bereinigten Auftragsstatus dieses Inhabers; für einen einzelnen Status hänge die Auftrags-ID an. Ein POST an die Sammlung startet einen Auftrag mit visitorId, einer stabilen zufälligen requestId und retainFinancialRecords:true. Das rohe Besucher-Pseudonym gehört in den JSON-Body, niemals in eine URL. Nur verifizierte Inhabersitzungen sind erlaubt; Viewer und API-Bearer-Tokens können diese Aufträge weder starten noch einsehen.
Dieselbe Anfrage-ID mit demselben Ziel ist idempotent; ein widersprüchliches Ziel wird abgelehnt. Der öffentliche Status lässt Sperrhashes und Worker-Tokens weg. Der Abschluss erhält Geldbeträge und festgeschriebene Zuordnung, während das bekannte Pseudonym entkoppelt wird; er garantiert keine rechtliche, physische oder anbieterseitige Löschung. Lies vor der Verwendung die Anleitung zum Datenlebenszyklus und die Bestätigung zu aufbewahrten Daten.
Erfassung und finanzielle Schreibvorgänge pausieren für das betroffene Projekt, während transaktionslokale Sperrgrenzen und fortsetzbare Stapel laufen. Auf ungewisse Versandvorgänge wartende Aufträge bleiben sichtbar ausstehend. Manuelle Aufbewahrung sowie Projekt- oder Kontolöschung können nicht parallel in eine aktive Bereinigung eingreifen. Umfangsgrenzen betreffen ältere nicht indexierte Empfangsbelege, selbst verfasste Notizen und Bezeichnungen, externe Kopien und Backups.
Bestandsübersicht des Inhaber-Datenexports
GET /api/account/data-export liefert die unterstützten lokalen Abschnitte, Feldprojektionen, Verfügbarkeit und Ausschlüsse. Ergänze section, optional eine eigene projectId, limit (1–100) und cursor, um eine Seite zu lesen. Der Server ermittelt den Inhaber aus der authentifizierten Sitzung, niemals aus einer übergebenen Inhaber-ID. Viewer-Rollen und schreibgeschützte API-Tokens berechtigen nicht zu dieser Kontoroute.
Der Cursor ist an Abschnitt, Inhaber und Projekt gebunden. Zeilen werden über statisches SQL und JSON-Feldzulassungslisten ausgewählt; es gibt keine beliebigen Parameter für Datenbank, Tabelle, Pfad oder Spalte. Fehlender oder schemaunverträglicher Speicher liefert ausdrücklich nicht verfügbare Abdeckung. Zugangsdaten-Hashes, Chiffretexte, rohe Tokens und Worker-Interna werden weggelassen. Das Ergebnis ist weder ein atomarer Snapshot noch eine allgemeingültige Vollständigkeitszusage.
Berichte und Benachrichtigungen für Inhaber
Projektinhaber können einen Wochenbericht mit ausdrücklichem UTC-Wochentag, Uhrzeit und Währung oder Benachrichtigungen zu benannten Ereignissen aktivieren. Nachrichten gehen nur an die verifizierte Konto-E-Mail-Adresse; es gibt kein frei wählbares Empfängerfeld. Neue Zielbenachrichtigungen beginnen am serverseitigen Empfangsprüfpunkt; das Aktivieren einer Regel spielt daher niemals ältere Ereignisse nach. Ein verspätet eintreffendes Ereignis kann benachrichtigen, wenn es nach Aktivierung der Regel ankommt. Browser-Ziele sind kein Einnahmenbeleg.
Die Zustellung ist standardmäßig unabhängig deaktiviert. Testlaufregeln können Berichte einreihen, versenden aber keine E-Mails. Eine angenommene Nachricht bedeutet Annahme durch den E-Mail-Anbieter, nicht Eingang im Postfach. Ausstehende Warteschlangen- und tägliche Inhaber-Zustelllimits unterdrücken überzählige Benachrichtigungen; es entstehen keine Mehrverbrauchskosten. Disable all unter Reports & alerts bricht wartende Nachrichten ab. Bereits angenommene Nachrichten können nicht zurückgerufen werden.
Nur Inhabersitzungen haben Zugriff auf /api/projects/:id/notifications. Schreibgeschützte Bearer-Tokens und Viewer können weder Berichte konfigurieren noch die private Warteschlange lesen. POST-Aktionen sind weekly, goal, remove_goal und unsubscribe.
Öffentliche Aggregatlinks und Widgets
Inhaber erstellen ausdrücklich eine Freigabe in den Sharing-Einstellungen des Projekts. Wer die Bearer-URL besitzt, kann nur aggregierte Besucher, Ereignisse, Zahlungen, Brutto-/erstattete/Nettozahlungseingänge, Währung und Zeitraum lesen. Quellen, einzelne Besucher, Notizen oder zugrunde liegende Datensätze sind nicht enthalten. Links und Widget-Einbettungen werden nicht automatisch veröffentlicht. Rotation oder Widerruf macht die alte URL sofort ungültig, kann aber bereits angesehene Kopien nicht löschen.
Freigabeseite und Einbettung sind noindex und verwenden no-referrer/no-store-Header. Das Widget ist absichtlich erst dann in Frames einbettbar, nachdem ein Inhaber diese Zugriffsmöglichkeit erstellt hat. Private Dashboard-Routen bleiben nicht einbettbar. Eine aggregierte Journalanzahl von null belegt nicht, dass ein nicht angebundenes reales Unternehmen keine Verkäufe hatte.
Schreibgeschütztes SDK und CLI
reylin-client.mjs ist ein serverseitiges SDK ohne Abhängigkeiten mit summary/events/journey/trend/search. reylin-cli.mjs bietet dieselben Leseoperationen und gibt JSON aus. Setze REYLIN_API_TOKEN in der Umgebung, niemals in Befehlszeilenargumenten oder Browser-Bundles. Tokens können weder Abrechnung noch Anbietereinstellungen oder Nutzerkonten ändern. Diese Quellwerkzeuge sind lokal; es wurde weder ein npm-Registry-Paket noch eine MCP-Anbindung eines Drittanbieters veröffentlicht.
node reylin-cli.mjs summary --origin https://YOUR_APPROVED_HOST --project PROJECT_ID --days 30 --currency USDFehler und Datenverarbeitung
Wiederhole eine kostenpflichtige Aktion niemals mit einem neuen Idempotenzschlüssel, nur weil ihre Antwort verloren ging. Trage keine Geheimnisse in Query-Strings, eigene Ereignisse oder Support-Screenshots ein. Exporte und pseudonyme Besucherpfade sind authentifizierte Projektdaten; begrenze ihren Zugriff und beachte Aufbewahrungs- und Löschregeln. Es gibt keine öffentliche unauthentifizierte Analytics-Lese-API.
Quellen
Diese Dokumentation beschreibt den Code und seine Grenzen; sie bestätigt keine aktive Verbindung. Technische Beispiele behalten ihre ursprünglichen Bezeichner.