Dokumentationsartikel: Versionsverwaltete Referenz für bestehende Benutzer

Ein Dokumentationsartikel ist eine gepflegte Referenz für jemanden, der bereits ein Produkt, eine API, einen Dienst, ein Gerät oder einen Betriebsprozess nutzt. Er beantwortet eine präzise Nachschlagerage – welche Funktion eine Einstellung hat, welche Werte ein Feld akzeptiert, welcher Zugriff erforderlich ist, welche Version sich so verhält oder wo ein Limit gilt – ohne den Leser zuerst durch ein Marketingargument zu führen.

Sein Vertrag ist Umfang → Voraussetzungen → aktuelles Verhalten → exakte Referenz → Ausnahmen → verwandte Aufgabe. Die Seite ist erfolgreich, wenn ein Benutzer die richtige Tatsache für die richtige Version und Rolle abruft. Jedes UI-Label in eine öffentliche URL zu verwandeln, hilft nicht.

Fragen, die er beantwortet

Die primäre Frage lautet: „Was bedeutet dieses Produktverhalten in meiner Version und meinem Kontext?" Unterstützende Fragen sind:

• Gilt diese Seite für mein Produkt, meinen Plan, meine Rolle, meine Region, meine Plattform und meine Version?
• Was muss bereits gegeben sein, bevor ich diese Funktion nutze oder auf dieses Feld verweise?
• Was sind die akzeptierten Werte, Standardwerte, Grenzen, Formate und Nebenwirkungen?
• Welches Verhalten ist aktuell und was hat sich gegenüber einer früheren Version geändert?
• Welches Beispiel demonstriert die Regel, ohne wichtige Bedingungen zu verbergen?
• Was sollte ich als Nächstes lesen, wenn ich eine Anleitung, Diagnose oder Änderungshistorie benötige?
• Sind diese Informationen in der öffentlichen Suche sicher und nützlich, oder erfordern sie einen authentifizierten Kontext?

Wann dieser Beitragstyp verwendet wird

Verwende Dokumentation, wenn eine stabile Seite wiederholtes Nachschlagen unterstützen muss. Das Thema benötigt einen autoritativen Verantwortlichen, testbares Verhalten und ein Wartungssignal wie eine Veröffentlichung, API, Plan- oder Schnittstellenänderung.

Eine Seite mit dem Titel „Exportfelder konfigurieren" kann dennoch Dokumentation sein, wenn ihr dauerhafter Wert ein Feldkatalog ist und Benutzer direkt zu einzelnen Parametern springen. Umgekehrt ist „Ersten Bericht exportieren" eine How-to-Anleitung, wenn der Leser einer Sequenz folgen und eine heruntergeladene Datei überprüfen muss. Die Titelgrammatik entscheidet nicht über das Format; die Aufgabe des Lesers und die Antwortform tun es.

Am besten geeignet für diese Geschäftstypen

1. SaaS. Die stärkste Passung, da Rollen, Pläne, Einstellungen, Integrationen, APIs, Datenmodelle und Veröffentlichungsrhythmen exakte Referenzbedürfnisse erzeugen. Die Dokumentation sollte das Verhalten der Benutzeroberfläche vom API-Verhalten und Benutzerberechtigungen von Abonnementberechtigungen unterscheiden.
2. E-Commerce. Stark für Händlerverwaltung, Produktfeeds, Zahlungsregeln, Retouren, Integrationen und Nutzung nach dem Kauf. Trenne die Kundenbetreuung von der Händlerdokumentation, damit ein Käufer nicht auf einer Implementierungsreferenz landet.
3. Marktplätze. Stark, wo Käufer-, Verkäufer-, Anbieter- und Administratorenrollen unterschiedliche Zustände sehen. Jeder Artikel muss den Akteur identifizieren, da dasselbe Label unterschiedliche Steuerelemente oder Pflichten offenbaren kann.
4. Agenturen. Nützlich für Kundenportale, Leistungsstandards, wiederkehrende Workflows und gemeinsame Werkzeuge. Veröffentliche wiederverwendbare Kundenreferenzen nur dann öffentlich, wenn sie keine internen Steuerelemente, Anmeldedaten oder proprietäre Betriebsdetails offenlegen.
5. B2B-Dienstleistungen. Nützlich für Onboarding-Systeme, Datenübergaben, Dateispezifikationen, Genehmigungszustände und Serviceportale. Vermeide es, eine vertragliche Verpflichtung als allgemeine Helpcenter-Tatsache darzustellen, wenn die Bedingungen je nach Konto variieren.
6. Hersteller und Industriebetriebe. Wertvoll für Steuerungen, Software, Kompatibilität, Konfiguration, Wartungsaufzeichnungen und technische Parameter. Sicherheitskritisches Material erfordert eine kontrollierte Überprüfung, explizite Modellanwendbarkeit und einen Weg zum maßgeblichen Handbuch.

Suchintention

Suchintention ist das Ergebnis, das eine Person von einer Suchanfrage erwartet. Die Dokumentationsintention ist in der Regel navigational plus informational: Der Suchende kennt das Produkt oder Objekt und möchte eine exakte Tatsache, wie „Northstar-Export-Aufbewahrung", „Northstar-Statuswerte" oder „Northstar-API-Seitengröße". Marke, Funktion, fehlerfreie Aufgabensprache, Version und Plattform treten oft gemeinsam auf.

Das ideale Ergebnis öffnet nahe der Antwort. Verwende beschreibende Überschriften, stabile Anker, akzeptierte Werte und Versionsqualifikatoren. Eine extrahierte Aussage muss ihre Bedingung bewahren: „Bei Team- und Enterprise-Plänen bleiben abgeschlossene Exporte 30 Tage lang verfügbar."

Öffentliche Dokumentation sollte ranken, wenn sie eine dauerhafte Frage beantwortet, ohne Kontodaten preiszugeben: unterstützte Formate, öffentliche API-Felder, Kompatibilität, Grenzen, Konfigurationsbedeutung und dokumentiertes Verhalten.

Dokumentation sollte nicht ranken, wenn sie nur ein UI-Label spiegelt, eine aktuelle Seite dupliziert, eine veraltete Version ohne fortlaufenden Bedarf abdeckt, sensible Details offenlegt oder einen privaten Kontokontext benötigt. Verwende stattdessen authentifizierte Hilfe, In-App-Anleitungen, noindex, Konsolidierung oder einen klaren Archivierungszustand. Suchnachfrage rechtfertigt niemals die Veröffentlichung von Geheimnissen oder Exploit-Pfaden.

Seitenstruktur

Wortbänder sind Produktionskontrollen, keine Mindestvorgaben. Eine schmale Feldreferenz kann kürzer sein; eine versionsbezogene Funktionsreferenz benötigt möglicherweise mehr Platz, da Anwendbarkeit und Ausnahmen kostspielige Fehler verhindern.

Die meisten umfangreichen Dokumentationsartikel liegen zwischen 1.500 und 2.800 Wörtern. Füge nur dort Details hinzu, wo sie Mehrdeutigkeit verhindern: Umfang, Voraussetzung, Wert, Standardwert, Nebenwirkung, Ausnahme oder Versionsänderung.

Erforderliche Elemente

Referenzleser scannen. Platziere die Anwendbarkeitsinformationen vor der Referenz, damit ein technisch korrekter Wert nicht auf den falschen Plan oder das falsche Release angewendet wird.

Frontmatter

Befolge die Frontmatter-Spezifikation. Bei dieser Beitragstypspezifikation lautet entity = "post-type-documentation-article". Verwende auf einer erstellten Dokumentationsseite einen stabilen Produktobjektwert wie northstar-scheduled-export-settings, nicht einen werblichen Ausdruck wie effortless-reporting und keine Versionsnummer, die nach jeder Veröffentlichung eine neue Identität erzwingen würde.

Verwende schemaType = "Article". Schema-Markup muss die sichtbare Seite beschreiben; wähle nicht HowTo nur, weil ein Beispiel drei Aktionen enthält. Füge FAQ-Strukturierte-Daten nur hinzu, wenn die sichtbaren Fragen und Antworten exakt übereinstimmen. API-Referenz oder softwarespezifische Semantik können an anderer Stelle im Datenmodell der Site dargestellt werden, aber ein spezifischerer Schema-Typ sollte ohne Vorlagenunterstützung nicht im Frontmatter erfunden werden.

Speichere die Felder, die das Wartungssystem durchsetzen kann: Produktbereich, Pläne, Rolle, Plattform, Versionsbereich, Prüfdatum, Verantwortlicher und Ersatz-URL. lastmod bedeutet, dass das Verhalten überprüft wurde, nicht dass ein Tippfehler korrigiert wurde. Erhalte die kanonische URL über kompatible Releases hinweg.

Vollständiges Beispiel

Dieses fiktive Analysebeispiel demonstriert eine Referenzseite, keine vollständige Exportprozedur.

# Geplante Exporteinstellungen

Geplante Exporte erstellen eine CSV- oder JSON-Datei aus einem gespeicherten Bericht zu einer festgelegten UTC-Zeit und liefern sie an ein genehmigtes Ziel. Sie sind für Editoren und Administratoren bei Team- und Enterprise-Plänen verfügbar. Diese Referenz gilt für die Northstar Analytics Web-App 6.4 und wurde am 27. August 2026 verifiziert.

## Bevor du diese Referenz verwendest

Du benötigst einen vorhandenen gespeicherten Bericht, ein aktiviertes Ziel und Editor- oder Administratorzugriff. Ein Betrachter kann einen vorhandenen Export herunterladen, aber keinen Zeitplan erstellen oder ändern. Zieladministratoren können zusätzliche Aufbewahrungs- oder Dateigrößenbeschränkungen auferlegen.

## Einstellungsreferenz

| Einstellung | Akzeptierter Wert | Standardwert | Wirkung und Einschränkungen |
|---|---|---|---|
| Name | 1–80 Zeichen | Berichtsname | Identifiziert den Zeitplan; eine Änderung benennt frühere Dateien nicht um. |
| Format | `csv` oder `json` | `csv` | CSV verwendet die sichtbare Spaltenreihenfolge des Berichts. JSON verwendet stabile Feldkeys. |
| Ausführungszeit | `HH:MM` in UTC | `08:00` | Sommerzeitumstellungen verschieben die UTC-Ausführungszeit nicht. |
| Leere Zeilen einschließen | Ein oder Aus | Aus | Nur für tabellarische Berichte verfügbar; wird bei zusammenfassenden Berichten ignoriert. |
| Aufbewahrung | 1–30 Tage | 7 Tage | Vorhandene Dateien laufen unabhängig vom Zeitplan, der sie erstellt hat, ab. |

## Verhalten und Grenzen

Ein Zeitplan liest die Konfiguration des gespeicherten Berichts, wenn die Ausführung beginnt. Die Bearbeitung des Berichts ändert daher zukünftige Dateien, aber nicht bereits generierte Dateien. Das Anhalten eines Zeitplans verhindert neue Ausführungen; es löscht keine aufbewahrten Dateien. Das Löschen des Ziels deaktiviert die Zustellung und versetzt den Zeitplan in den Status „Benötigt Aufmerksamkeit".

## Beispiel

Für einen täglichen CSV-Export, der um 09:00 Uhr in Bratislava während der Standardzeit benötigt wird, setze die UTC-Ausführungszeit auf `08:00`. Überprüfe die Zeit, wenn sich die Sommerzeitregeln ändern, da Zeitpläne an die UTC gebunden bleiben.

Ungültiges Beispiel: Eingabe von `Europe/Bratislava` in das Ausführungszeitfeld. Das Feld akzeptiert eine UTC-Zeit, keine Zeitzonenkennung.

## Versionsunterschiede

- Version 6.4: JSON-Exporte verwenden stabile Feldkeys; die angezeigte Spaltenbeschriftung wird nicht mehr zum Key.
- Versionen 6.1–6.3: JSON-Keys folgen den angezeigten Spaltenbeschriftungen. Bestehende Integrationen sollten vor dem Upgrade überprüft werden.
- Vor 6.1: Geplanter JSON-Export ist nicht verfügbar. Verwende CSV oder upgrade auf eine unterstützte Version.

## Wenn ein Export nicht ankommt

Füge hier keine spekulativen Korrekturen ein. Öffne die Fehlerbehebungsanleitung „Geplanter Export ist nicht angekommen", die den Zeitplanstatus, die Zielautorisierung, Dateigrenzen und Servicevorfälle in diagnostischer Reihenfolge überprüft.

## Verwandte Aufgaben

- Erstelle deinen ersten geplanten Export – geordnete Einrichtung und Erfolgsprüfung
- Fehlerbehebung bei einem fehlenden geplanten Export – symptomgeführte Diagnose
- Northstar Analytics 6.4 Versionshinweise – Verhaltensänderungen und Migrationshinweis

## Verifizierungsnachweis

Verifiziert gegen Web-App 6.4 durch den Product Owner für Berichte am 27. August 2026. Überprüfung bei Änderungen von Berechtigungen, Formaten, Aufbewahrung, Zeitplanung oder Zielverhalten.

Design-Galerie

Verwende identische Einstellungen, Grenzen, Rollen und Versionsangaben über alle Varianten hinweg, damit das Design-Review die Abrufgeschwindigkeit und nicht die Textunterschiede misst.

Qualitäts-Checkliste

Ein Dokumentationsartikel ist erst dann bereit, wenn jede zutreffende Aussage wahr ist:

• Die Eröffnung nennt das genaue Objekt und gibt das aktuelle Verhalten vor Hintergrund oder Nutzen an.
• Die Anwendbarkeit von Produkt, Plan, Rolle, Region, Plattform und Version ist explizit, wo sie die Antwort ändern.
• Voraussetzungen erscheinen vor Einstellungen oder Beispielen, die von ihnen abhängen.
• Jeder technische Begriff wird bei der ersten Verwendung definiert, durch ein vertrautes UI-Label ausgedrückt oder mit seiner kanonischen Definition verlinkt.
• Felder, Werte, Standardwerte, Einheiten, Formate, Grenzen und Nebenwirkungen stammen aus einer autoritativen Quelle oder einem verifizierten Produkttest.
• Referenztabellen verwenden konsistente Dimensionen; leere Zellen verbergen keine unbekannten Standardwerte oder Ausnahmen.
• Beispiele geben die Bedingungen an, die sie gültig machen, und enthalten ein ungültiges oder Grenzbeispiel, wenn Verwirrung wahrscheinlich ist.
• Warnungen erscheinen vor destruktivem, irreversiblem, sicherheitsrelevantem, kostspieligem oder berechtigungsänderndem Verhalten.
• Screenshots enthalten eine Aufnahmeversion und eine Textalternative; das Bild ist nicht die einzige Quelle eines Werts oder einer Anweisung.
• Überschriften und Anker entsprechen den Nomen, nach denen Benutzer suchen, und bleiben für Deep Links stabil.
• Wesentliche Versionsunterschiede nennen den betroffenen Bereich, den aktuellen Ersatz und die Migrationskonsequenz.
• Das Prüfdatum spiegelt eine Verhaltensüberprüfung wider, und ein benanntes Team oder eine benannte Rolle ist für die nächste Überprüfung verantwortlich.
• Anleitungen, Diagnosen und Versionshistorie verlinken zu kanonischen Schwesterngeschäftsseiten, anstatt unvollständig dupliziert zu werden.
• Die öffentliche Indexierung ist beabsichtigt; veraltetes, doppeltes, privates und sicherheitsrelevantes Material hat eine angemessene Suchbehandlung.
• FAQ-Einträge stimmen mit den sichtbaren Antworten überein, und der CTA respektiert die nächste Aufgabe eines Lesers in der Support-Phase.

Häufige Fehler

Eine Feature-Landingpage für einen bestehenden Benutzer schreiben. „Schalte leistungsstarke Exporte frei" verzögert die Tatsache, die der Leser benötigt. Führe mit Verhalten, Anwendbarkeit und Einschränkungen; Nutzenargumente gehören nur dort hin, wo sie den Zweck klären.

Jede Aufgabe in Dokumentation verwandeln. Eine 20-schrittige Einrichtung, die unter einer Feldliste vergraben ist, dient weder dem Nachschlagen noch dem Abschluss. Trenne das geordnete Verfahren in eine How-to-Anleitung und verlinke es aus dem entsprechenden Voraussetzungs- oder Aufgabenbereich.

Eine Seite pro UI-Label veröffentlichen. Dünne Seiten überschneiden sich und vervielfachen den Wartungsaufwand. Gruppiere Felder um ein stabiles Produktobjekt, es sei denn, eine Einstellung hat ein abweichendes Verhalten.

„Neueste" als Version verwenden. Neueste ändert sich. Nenne das getestete Release, den unterstützten Bereich, die Plattform und das Prüfdatum und aktualisiere sie dann durch den Release-Prozess.

Alte und neue Seiten ohne Abgrenzung indizierbar halten. Konsolidiere kompatibles Verhalten; andernfalls kennzeichne die alte Version, verlinke zur aktuellen Seite und steuere die Indexierung bewusst.

Voraussetzungen in Fehlermeldungen verstecken. Wenn nur Administratoren ein Feld ändern können, sage das vor der Referenz. Lass einen Betrachter die Rollengrenze nicht erst nach Befolgen eines Beispiels entdecken.

Screenshots statt Verhalten kopieren. Eine Aufnahme ist ein Nachweis eines bestimmten Oberflächenzustands, nicht die Spezifikation. Schreibe Labels, Pfade, Werte und Bedingungen in zugänglichem Text und notiere die erfasste Version.

Frische vortäuschen. Das Ändern des Datums ohne erneutes Testen des Verhaltens lässt die Seite sicherer erscheinen, während das Risiko steigt. Aktualisiere den Verifizierungsnachweis nur, nachdem der Verantwortliche die zutreffenden Behauptungen überprüft hat.

Öffentliche Suche interne Details offenlegen lassen. Interne Eskalationspfade, Geheimnisse, Kundenkennungen, Exploit-Anleitungen und nicht angekündigtes Verhalten werden nicht dadurch sicher, dass sie den Support-Aufwand reduzieren. Trenne öffentliche Hilfe von authentifiziertem und internem Wissen.

Interne Verlinkung

Verlinke nach oben zu SEO-Beitragsarten, wenn der Autor möglicherweise eine andere Antwortform benötigt. Verlinke von einer Dokumentationsvoraussetzung zur kanonischen How-to-Anleitung nur, wenn der Leser diese Aufgabe zuerst erledigen muss. Verlinke von einem Fehlerzustand zur Fehlerbehebung, anstatt eine generische Korrekturliste einzufügen. Verlinke von einem Versionsunterschied zum Veröffentlichungsereignis, wenn die Änderungshistorie Kontext hinzufügt; Versionshinweise sollten zurück zur aktuellen Dokumentation als dauerhafter Quelle der Wahrheit verlinken.

Organisiere Links nach Produktobjekten und Leserzustand. Platziere einen spezifischen Link neben der Aussage, die die nächste Frage aufwirft, anstatt dich auf eine lange Liste verwandter Artikel zu verlassen.

Eine kanonische aktuelle Seite sollte stabiles Verhalten besitzen. Behalte Versionsseiten nur für materiell unterschiedliches Verhalten, das Benutzer noch benötigen, und mache diese Unterscheidung explizit. Verwende stabile Anker wie #retention, nicht #table-2.

Wie die Ergebnisse gemessen werden

Messe, ob Benutzer die richtige Antwort für ihre Version abrufen. Traffic allein ist ein schwaches Indiz: Ein Anstieg kann ein defektes Produkt oder eine veraltete Antwort widerspiegeln.

Erfasse Zielanfragen, Ranking-URL, Indizierbarkeit, unterstützte Versionen, Support-Suchanfragen, Ausstiege zu verwandten Aufgaben und ein geeignetes Produktereignis. Überprüfe dann:

• Suchimpressionen und qualifizierte Besuche für Produktobjekt-, Feld-, Limit-, Syntax-, Rollen- und Versionsanfragen;
• interne Suchverfeinerungen, Null-Ergebnis-Suchanfragen und wiederholte Suchanfragen, die fehlende Terminologie offenbaren;
• Engagement mit verankerten Abschnitten anstatt undifferenzierter Verweildauer auf der Seite;
• Klicks auf die richtige Einrichtungs-, Fehlerbehebungs-, Release- oder Support-Zielseite;
• Support-Kontakte, deren Frage die Seite beantworten sollte, segmentiert nach Version und Rolle, wo es der Datenschutz erlaubt;
• Zitationen, die den Wert zusammen mit seinem Plan, seiner Version, seiner Einheit oder seiner Voraussetzung bewahren;
• veraltete URLs, die nach Konsolidierung oder Stilllegung noch ranken oder zitiert werden;
• Dokumentationsänderungen, die durch Releases, Oberflächenänderungen, Richtlinienänderungen und wiederkehrende Support-Fälle verursacht werden.

Verwende Prompt-Tracking für markengebundene Nachschlagefragen und Versionsvarianten. Verwende Quellen- und Zitationsanalyse, um zu sehen, welche URL eine Antwort-Engine zitiert und ob ihre Zusammenfassung die Bedingungen bewahrt. Öffne das AmICited Cockpit, um zitierte URLs, Sichtbarkeit, organische Landing-Aktivität und das gewählte Produkt- oder Support-Ereignis über denselben Beobachtungszeitraum zu vergleichen.

Befolge wie wir Ergebnisse messen, um Entdeckung, Repräsentation, Engagement, Aufgabenfortschritt und Bindung zu trennen. Markiere Releases und Vorfälle, bevor du Bewegungen interpretierst. Eine Zero-Click-Antwort funktioniert nur, wenn sie den aktuellen Wert und seine Bedingungen bewahrt.

FAQ

Häufig gestellte Fragen