Erfasste Ereignisse

Ein Seitenaufruf zeigt, welche Seite geöffnet wurde. Er sagt nicht, ob der Leser das Snippet kopiert, den Assistenten gefragt, über die Einleitung hinaus gescrollt oder zu Ihrer Registrierungsseite gewechselt hat. Auf dieser Seite finden Sie die vollständige Liste dessen, was sonst noch erfasst wird, Feld für Feld, damit Sie vor dem Erstellen eines Ziels oder Trichters feststellen können, ob das, was Sie messen möchten, bereits erfasst wird.

Das erhalten Sie#

Sechsunddreißig benannte docs.*-Ereignisse in sieben Kategorien, die auf jeder Dokumentationsseite ohne Konfiguration und ohne Tag-Manager aufgezeichnet werden. Jedes davon ist eine Zeile, nach der Sie in Feeds filtern, ein Ziel zuordnen, im Analyseüberblick einordnen oder pro Besucher über MCP auslesen können.

Die Aufzeichnung wird nicht auf das Guthaben Ihres Projekts angerechnet, und an der Liste ändert sich durch Ihren Tarif nichts.

Der Katalog#

Jedes Ereignis enthält den vollständigen Namen Ihres Projekts (owner/repo). Die Spalte Ebenfalls enthalten gibt an, was zusätzlich dazu enthalten ist. Ereignisse, die als Beacon markiert sind, werden von navigator.sendBeacon ausgeliefert, sobald der Leser die Seite verlässt; der Rest wird über den gewöhnlichen Logging-Transport gesendet, der zwei Sekunden lang bündelt.

KI-Assistent#

docs.ai_navigate und docs.ai_outbound sind bewusst zwei Ereignisse und nicht eines. Das erste besagt, dass der Leser der Antwort genug vertraut hat, um die von ihr zitierte Seite zu öffnen; das zweite besagt, dass der Assistent ihn an Ihre App, Ihr Repository oder ganz woanders weitergeleitet hat — eine kommerzielle Frage, keine Frage des Verständnisses.

Suche#

Lesen und Engagement#

docs.pageview ist das einzige Ereignis, das der Browser nicht sendet. Es wird serverseitig geschrieben und existiert daher auch für Leser mit deaktiviertem JavaScript — weshalb ein Besuch, der ausschließlich aus Seitenaufrufen besteht, als Crawler behandelt wird. Auf Seiten, die aus dem Cache ausgeliefert werden, wird der Seitenaufruf stattdessen vom Browser als Beacon gesendet. Der Ingest-Endpunkt ergänzt dieselbe IP-Adresse und Geografie, sodass beide Pfade dieselbe Zeile erzeugen.

seconds wird unverarbeitet ausgegeben und auf 300 Sekunden gekürzt, bevor ein Bericht die Summe bildet. Diese Kürzung und der Grund dafür werden unter Lesezeit erläutert.

Inhaltsaktionen#

Navigation#

docs.heading_nav und docs.heading_view verwenden absichtlich dasselbe #anchor-Format, damit ein Abschnitt dasselbe aggregiert, unabhängig davon, ob Leser direkt zu ihm gesprungen oder zu ihm gescrollt haben.

Ausgänge und Quellen#

docs.page_exit wird nur bei einem tatsächlichen Verlassen oder Neuladen ausgelöst. Die Navigation innerhalb der Website erzeugt kein solches Ereignis. Dadurch ist das letzte docs.page_exit eines Besuchs die Seite, von der der Leser die Website tatsächlich verlassen hat.

Feedback#

Die Richtung steht im Namen des Ereignisses, nicht in einem vote-Feld: Das Schema des Ereignisspeichers besteht aus einer festen Menge von Feldnamen, und ein nicht erkanntes Feld wird vollständig abgelehnt, statt verworfen zu werden. Stimmen werden über eine Serverroute erfasst, sodass ein Webhook bei ihnen ausgelöst werden kann; wenn diese Anfrage fehlschlägt, erfasst der Browser dasselbe Ereignis direkt, sodass die Anzahl erhalten bleibt.

Automatisch oder von einer Funktion abhängig#

In Docsbook gibt es nirgendwo einen Tracking-Schalter und kein enabled-Flag bei irgendeinem Ereignis. Jedes oben aufgeführte Ereignis wird ausgegeben, sobald das Element, das es erzeugt, vorhanden ist. Dadurch teilt sich die Liste in zwei Teile:

Ein „leeres“ Ereignis in Ihren Berichten kann daher auf zwei Arten interpretiert werden, und sie sind unterschiedlich: Niemand hat es ausgeführt, oder noch nichts kann es ausführen.

Wie es übermittelt wird#

Normale Ereignisse werden über einen Transport gesendet, der zwei Sekunden lang bündelt und über fetch postet. Das ist für einen Klick, der die Seite offen lässt, in Ordnung, und bei einem Klick, der dies nicht tut, geht alles verloren – weshalb die mit dem Verlassen verbundenen Ereignisse einen zweiten Weg nehmen:

1. Komponenten registrieren einen Exit-Collector. Bei pagehide wird jeder Collector in ein einziges Beacon geleert, auf 100 Ereignisse begrenzt und an einen Same-Origin-Endpunkt gesendet.
2. Unter iOS löst visibilitychange → hidden denselben Flush aus, da pagehide dort unzuverlässig ist.
3. Collector geben nur das zurück, was sie noch nicht gesendet haben. Dadurch wird ein iOS-Flush gefolgt von einem tatsächlichen Verlassen nicht doppelt gezählt, und eine aus dem Back-/Forward-Cache wiederhergestellte Seite kann erneut einen Flush ausführen.

Ansichten von Überschriften werden mit einem IntersectionObserver bei einem Schwellenwert von 0 und einem -15% unteren Rand erfasst, und die Beobachtung jeder Überschrift wird aufgehoben, sobald sie gesehen wurde: Eine Überschrift wird einmal pro Seitenaufruf gezählt, und zwar erst, nachdem sie den unteren Rand des Ansichtsfensters passiert hat, nicht bereits in dem Moment, in dem sie kurz hineinschaut.

Warum dies der richtige Weg ist#

Ereignisse eines Besuchers auslesen#

Zwei MCP-Tools rekonstruieren den Pfad eines anonymen Besuchers von Anfang bis Ende, und beide sind Lesevorgänge: get_top_visitors listet die aktivsten Besucher über einen Zeitraum auf, get_visitor_activity gibt die Ereignisse eines Besuchers in der richtigen Reihenfolge zurück.

get_top_visitors(period: "7d", limit: 25)
  → [{ visitor_id: "a1b2…", pageview_count: 14, first_seen, last_seen, country }, …]
 
get_visitor_activity(visitor_id: "a1b2…", period: "7d")
  → { first_seen, last_seen, country, language, pageview_count,
      events: [
        { event: "docs.pageview",           at, path: "guides/quick-start" },
        { event: "docs.page_feedback_down", at, path: "guides/quick-start" },
        { event: "docs.search_no_result",   at, query: "rotate api key" },
        … ] }

visitor_id ist ein gesalzener Hash der IP-Adresse des Lesers, der auf Ihr Projekt beschränkt ist; rohe IP-Adressen werden niemals zurückgegeben. Weitere Informationen finden Sie unter Funktionsweise der Messung.

Grenzen und offene Fragen#

• Kein Webhook kann bei einem docs.*-Ereignis ausgelöst werden. Diese Ereignisse befinden sich im Ereignisdatenlager, und nichts löst sie aus. Sie können in Feeds gefiltert und in einer Liste gespeichert werden. Dort werden sie als not_sent angezeigt, weil sie genau das sind. Das Erstellen von Warnungen zum Verhalten der Leser erfolgt über die abgeleiteten Webhook-Ereignisse — Traffic-Rückgang, beliebte Suche, Suche ohne Ergebnis — und nicht über diesen Katalog. Siehe Webhooks.
• Ereignisse werden pro Ereignis gezählt, nicht pro Besuch. Wenn ein Leser fünf Snippets kopiert, sind das fünf docs.copy_code-Zeilen. Alles, was pro Besuch gezählt werden muss — Absprung, Konversion, ein Ziel — wird durch die Rekonstruktion des Besuchs abgeleitet und nicht durch das Aufsummieren dieser Liste.
• Ein Leser mit deaktiviertem JavaScript trägt nur docs.pageview bei. Jedes andere oben aufgeführte Ereignis benötigt ein laufendes Skript, worauf sich der Filter für den Verhaltens-Crawler genau stützt.
• Die Felder question und answer enthalten alles, was der Leser eingegeben hat. Rohdaten von Ereignissen werden durch einen Redaktor geleitet, der jedes Feld maskiert, dessen Schlüssel oder Wert wie ein Token, Schlüssel, JWT oder Autorisierungsheader aussieht. Wenn ein Leser jedoch persönliche Informationen in Ihren Assistenten eingibt, hat er sie in Ihren Ereignisspeicher eingegeben. Die Aufbewahrungsfrist beträgt 30 Tage.
• Offene Frage: Der Katalog ist maßgeblich, aber nicht vollständig für den Stream. Nachprüfbar ist, dass diese 36 Namen diejenigen sind, die jede Oberfläche — das Panel, Feeds, die Zielvalidierung, MCP — aus einer gemeinsamen Liste liest, sodass ein Ziel nur für einen darin enthaltenen Namen definiert werden kann. Nicht enthalten sind einige zusätzliche docs.*-Namen, die vom Teaser-Ablauf für nicht beanspruchte Websites ausgegeben werden und nicht in dieser Liste stehen. Das bedeutet, dass sie den Speicher erreichen und in der Benutzeroberfläche unsichtbar sind. Betrachten Sie die 36 als vollständige Menge der Ereignisse, auf die Sie reagieren können, nicht als vollständiges Verzeichnis jeder Zeichenfolge im Stream.

Verwandte Inhalte#

• Funktionsweise der Messung — Besucheridentität, Bot-Filterung, Aufbewahrung und Datenschutz für alles auf dieser Seite
• Analytics-Übersicht — die Karten und Kennzahlen, in die diese Ereignisse einfließen
• Ziele und Trichter — das Festlegen eines Ergebnisses für einen dieser Ereignisnamen
• Lesezeit — docs.read_time als Bericht
• Webhooks — die Ereignisse, die Sie benachrichtigen können