Dokumentationsartikler: Versioneret opslagsværk for eksisterende brugere

En dokumentationsartikel er en vedligeholdt reference for en person, der allerede bruger et produkt, API, en tjeneste, enhed eller driftsproces. Den besvarer et præcist opslagsspørgsmål – hvad en indstilling gør, hvilke værdier et felt accepterer, hvilken adgang der kræves, hvilken version der opfører sig på denne måde, eller hvor en grænse gælder – uden at tvinge læseren til først at passere gennem et salgsargument.

Dens kontrakt er omfang → forudsætninger → nuværende adfærd → præcis reference → undtagelser → relateret opgave. Siden lykkes, når en bruger henter den rigtige kendsgerning for den rigtige version og rolle. Det hjælper ikke at gøre hver grænsefladeetikette til en offentlig URL.

Spørgsmål den besvarer

Det primære spørgsmål er: “Hvad betyder denne produktadfærd i min version og kontekst?” Understøttende spørgsmål omfatter:

• Gælder denne side for mit produkt, plan, rolle, region, platform og version?
• Hvad skal allerede være sandt, før jeg bruger denne funktion eller slår op i dette felt?
• Hvad er de accepterede værdier, standardindstillinger, begrænsninger, formater og bivirkninger?
• Hvilken adfærd er aktuel, og hvad blev ændret fra en tidligere version?
• Hvilket eksempel demonstrerer reglen uden at skjule vigtige betingelser?
• Hvad skal jeg læse næste gang, hvis jeg har brug for en procedure, diagnose eller ændringshistorik?
• Er denne information sikker og nyttig i offentlig søgning, eller kræver den en autentificeret kontekst?

Hvornår skal denne indlægstype bruges

Brug dokumentation, når én stabil side skal understøtte gentagne opslag. Emnet har brug for en autoritativ ejer, testbar adfærd og et vedligeholdelsessignal såsom en udgivelse, API, plan eller grænsefladeændring.

En side kaldet “Sådan konfigurerer du eksportfelter” kan stadig være dokumentation, når dens varige værdi er et feltkatalog, og brugere hopper direkte til individuelle parametre. Omvendt er “Eksporter din første rapport” en how-to, når læseren skal følge en sekvens og verificere en downloadet fil. Titlens grammatik afgør ikke formatet; læserens opgave og svarformen gør.

Bedst til disse forretningstyper

1. SaaS. Den stærkeste pasform, fordi roller, planer, indstillinger, integrationer, API’er, datamodeller og udgivelseskadence skaber præcise referencebehov. Dokumentation bør skelne grænsefladeadfærd fra API-adfærd og brugertilladelser fra abonnementsrettigheder.
2. E-handel. Stærk til administration af forhandlere, produktfeeds, betalingsregler, returneringer, integrationer og brug efter køb. Adskil kundehjælp fra forhandlerdokumentation, så en shopper ikke lander på en implementeringsreference.
3. Markedspladser. Stærk, hvor køber, sælger, udbyder og administratorroller ser forskellige tilstande. Hver artikel skal identificere aktøren, fordi samme etikette kan vise forskellige kontroller eller forpligtelser.
4. Agenturer. Nyttig til klientportaler, leverancestandarder, tilbagevendende arbejdsgange og fælles værktøjer. Udgiv genanvendelig klientreference offentligt kun, når det ikke blotlægger interne kontroller, legitimationsoplysninger eller proprietære driftsdetaljer.
5. B2B-tjenester. Nyttig til onboardingsystemer, dataoverdragelser, filspecifikationer, godkendelsestilstande og serviceportaler. Undgå at fremstille en kontraktlig forpligtelse som et generisk hjælpecenter-faktum, når vilkår varierer efter konto.
6. Producenter og industrivirksomheder. Værdifuld til kontroller, software, kompatibilitet, konfiguration, vedligeholdelsesregistreringer og tekniske parametre. Sikkerhedskritisk materiale kræver kontrolleret gennemgang, eksplicit modelanvendelighed og en vej til den autoritative manual.

Søgehensigt

Søgehensigt er det resultat, en person forventer af en forespørgsel. Dokumentationshensigt er normalt navigationsmæssig plus informationsmæssig: den søgende kender produktet eller objektet og ønsker en præcis kendsgerning, såsom “Northstar eksportopbevaring”, “Northstar statusværdier” eller “Northstar API-sidestørrelse”. Brand, funktion, fejlfri opgavesprog, version og platform optræder ofte sammen.

Det ideelle resultat åbner tæt på svaret. Brug beskrivende overskrifter, stabile ankre, accepterede værdier og versionskvalifikatorer. En udtrukket udsagn skal bevare sin betingelse: “På Team- og Enterprise-planer forbliver fuldførte eksporter tilgængelige i 30 dage.”

Offentlig dokumentation bør rangere, når den besvarer et holdbart spørgsmål uden at afsløre kontodata: understøttede formater, offentlige API-felter, kompatibilitet, grænser, konfigurationsbetydning og dokumenteret adfærd.

Dokumentation bør ikke rangere, når den spejler én UI-etikette, duplikerer en nuværende side, dækker en forældet version uden fortsat behov, udsætter følsomme detaljer eller har brug for privat kontokontekst. Brug autentificeret hjælp, in-app-vejledning, noindex, konsolidering eller en klar arkivtilstand i stedet. Søgeefterspørgsel retfærdiggør aldrig offentliggørelse af hemmeligheder eller udnyttelsesveje.

Sidestruktur

Ordbånd er produktionskontroller, ikke minimumskvoter. En smal feltreference kan være kortere; en versioneret funktionsreference kan have brug for mere plads, fordi anvendelighed og undtagelser forhindrer dyre fejl.

De fleste væsentlige dokumentationsartikler ligger mellem 1.500 og 2.800 ord. Tilføj kun detaljer, hvor det forhindrer tvetydighed: omfang, forudsætning, værdi, standard, bivirkning, undtagelse eller versionsændring.

Påkrævede elementer

Opslagslæsere scanner. Placer anvendelighedsinformationen før referencen, så en teknisk korrekt værdi ikke anvendes på den forkerte plan eller udgivelse.

Frontmatter

Følg frontmatter-specifikationen. På denne indlægstype-specifikation er entity = "post-type-documentation-article". På en produceret dokumentationsside skal du bruge en stabil produktobjektværdi såsom northstar-scheduled-export-settings, ikke en salgsfremmende sætning som effortless-reporting og ikke et versionsnummer, der ville tvinge en ny identitet efter hver udgivelse.

Brug schemaType = "Article". schema-markup skal beskrive den synlige side; vælg ikke HowTo blot fordi ét eksempel indeholder tre handlinger. Tilføj FAQ-strukturerede data kun, når synlige spørgsmål og svar matcher dem præcist. API-reference eller softwarespecifik semantik kan repræsenteres andetsteds i sitets datamodel, men en mere specifik skematype bør ikke opfindes i frontmatter uden skabelonunderstøttelse.

Gem de felter, vedligeholdelsessystemet kan håndhæve: produktområde, planer, rolle, platform, versionsinterval, verificeret dato, ejer og erstatnings-URL. lastmod betyder at adfærd blev gennemgået, ikke at en stavefejl blev rettet. Bevar den kanoniske URL på tværs af kompatible udgivelser.

Fuldstændigt eksempel

Dette fiktive analyseeksempel demonstrerer en referenceside, ikke en komplet eksportprocedure.

# Indstillinger for planlagte eksporter

Planlagte eksporter opretter en CSV- eller JSON-fil fra en gemt rapport på et fastsat UTC-tidspunkt og leverer den til en godkendt destination. De er tilgængelige for redaktører og administratorer på Team- og Enterprise-planer. Denne reference gælder for Northstar Analytics webapp 6.4 og blev verificeret den 27. august 2026.

## Før du bruger denne reference

Du skal have en eksisterende gemt rapport, en aktiveret destination og redaktør- eller administratoradgang. En seer kan downloade en eksisterende eksport, men kan ikke oprette eller ændre en tidsplan. Destinationsadministratorer kan pålægge yderligere opbevarings- eller filstørrelsesgrænser.

## Reference for indstillinger

| Indstilling | Accepteret værdi | Standard | Effekt og begrænsninger |
|---|---|---|---|
| Navn | 1–80 tegn | Rapports navn | Identificerer tidsplanen; ændring af det omdøber ikke tidligere filer. |
| Format | `csv` eller `json` | `csv` | CSV bruger rapportens synlige kolonnerækkefølge. JSON bruger stabile feltnøgler. |
| Kørselstid | `TT:MM` i UTC | `08:00` | Sommer-/vintertidsændringer flytter ikke UTC-kørselstiden. |
| Inkludér tomme rækker | Til eller fra | Fra | Kun tilgængelig for tabelrapporter; ignoreres for oversigtsrapporter. |
| Opbevaring | 1–30 dage | 7 dage | Eksisterende filer udløber uafhængigt af den tidsplan, der oprettede dem. |

## Adfærd og grænser

En tidsplan læser den gemte rapportkonfiguration, når kørslen begynder. Redigering af rapporten ændrer derfor fremtidige filer, men ikke allerede genererede filer. Sætning af en tidsplan på pause forhindrer nye kørsler; det sletter ikke opbevarede filer. Sletning af destinationen deaktiverer levering og sætter tidsplanen i `Kræver opmærksomhed`.

## Eksempel

For en daglig CSV, der er nødvendig kl. 09:00 i Bratislava om vinteren, sæt UTC-kørselstiden til `08:00`. Gennemgå tidspunktet, når sommertidsregler ændres, fordi tidsplaner forbliver fastlåst til UTC.

Ugyldigt eksempel: indtastning af `Europe/Bratislava` i kørselstidsfeltet. Feltet accepterer et UTC-tidspunkt, ikke en tidszoneidentifikator.

## Versionsforskelle

- Version 6.4: JSON-eksporter bruger stabile feltnøgler; den viste kolonneetikette bliver ikke længere nøglen.
- Version 6.1–6.3: JSON-nøgler følger viste kolonneetiketter. Eksisterende integrationer bør kontrolleres før opgradering.
- Før 6.1: planlagt JSON-eksport er ikke tilgængelig. Brug CSV eller opgrader til en understøttet version.

## Hvis en eksport ikke ankommer

Tilføj ikke spekulative rettelser her. Åbn fejlfindingsguiden "Planlagt eksport ankom ikke", som kontrollerer tidsplanstatus, destinationsgodkendelse, filgrænser og servicehændelser i diagnostisk rækkefølge.

## Relaterede opgaver

- Opret din første planlagte eksport – struktureret opsætning og succescheck
- Fejlfind en manglende planlagt eksport – symptomledet diagnose
- Northstar Analytics 6.4 versionsnoter – adfærdsændringer og migrationsnote

## Verifikationsregistrering

Verificeret mod webapp 6.4 af rapporteringsproduktejeren den 27. august 2026. Gennemgå når tilladelser, formater, opbevaring, planlægning eller destinationsadfærd ændres.

Designgalleri

Brug identiske indstillinger, grænser, roller og versionsfakta på tværs af varianter, så designgennemgang måler indhentningshastighed frem for tekstforskelle.

Kvalitetstjekliste

En dokumentationsartikel er kun klar, når hver relevant udsagn er sand:

• Åbningen navngiver det præcise objekt og giver den nuværende adfærd før baggrund eller fordele.
• Produkt-, plan-, rolle-, regions-, platforms- og versionsanvendelighed er eksplicit, hvor de ændrer svaret.
• Forudsætninger vises før indstillinger eller eksempler, der afhænger af dem.
• Hvert teknisk begreb defineres ved første brug, udtrykkes gennem en velkendt grænsefladeetikette eller linkes til sin kanoniske definition.
• Felter, værdier, standarder, enheder, formater, grænser og bivirkninger kommer fra en autoritativ kilde eller verificeret produkttest.
• Referencetabeller bruger konsekvente dimensioner; tomme celler skjuler ikke ukendte standarder eller undtagelser.
• Eksempler angiver de betingelser, der gør dem gyldige, og inkluderer et ugyldigt eller grænsetilfælde, når forvirring er sandsynlig.
• Advarsler vises før destruktiv, irreversibel, sikkerhedsfølsom, dyr eller tilladelsesændrende adfærd.
• Skærmbilleder inkluderer en optagelsesversion og teksteækvivalent; billedet er ikke den eneste kilde til en værdi eller instruktion.
• Overskrifter og ankre matcher de navneord, brugere søger efter, og forbliver stabile for dybe links.
• Væsentlige versionsforskelle angiver det berørte interval, nuværende erstatning og migrationskonsekvens.
• Den verificerede dato afspejler en adfærdsgennemgang, og et navngivet team eller en rolle ejer den næste gennemgang.
• Procedurer, diagnose og udgivelseshistorik linker til kanoniske søstersider i stedet for at blive duplikeret ufuldstændigt.
• Offentlig indeksering er tilsigtet; forældet, duplikeret, privat og sikkerhedsfølsomt materiale har en passende søgebehandling.
• FAQ-poster matcher synlige svar, og CTA’en respekterer en supportfaselæsers næste opgave.

Almindelige fejl

At skrive en funktionslandingsside for en eksisterende bruger. “Lås op for kraftfulde eksporter” forsinker det faktum, læseren har brug for. Start med adfærd, anvendelighed og begrænsninger; fordele hører kun til, hvor det tydeliggør formålet.

At gøre hver opgave til dokumentation. En 20-trins opsætning begravet under en feltliste hjælper hverken opslag eller færdiggørelse. Del den strukturerede procedure op i en how-to og link til den fra den relevante forudsætning eller relateret opgave-sektion.

At publicere én side pr. grænsefladeetikette. Tykke sider overlapper og formerer vedligeholdelse. Gruppér felter omkring et stabilt produktobjekt, medmindre én indstilling har en tydelig forskellig adfærd.

At bruge “seneste” som en version. Seneste ændrer sig. Angiv den testede udgivelse, understøttede interval, platform og verifikationsdato, og opdatér dem derefter gennem udgivelsesprocessen.

At holde gamle og nye sider indekserbare uden en grænse. Konsolidér kompatibel adfærd; ellers mærk den gamle version, link til den nuværende side og kontrollér indeksering bevidst.

At skjule forudsætninger inde i fejl. Hvis kun administratorer kan ændre et felt, så sig det før referencen. Lad ikke en seer opdage rollebegrænsningen efter at have fulgt et eksempel.

At kopiere skærmbilleder i stedet for adfærd. En optagelse er bevis på én grænsefladetilstand, ikke specifikationen. Skriv etiketter, stier, værdier og betingelser i tilgængelig tekst og registrér den optagede version.

At forfalske friskhed. Ændring af datoen uden at genteste adfærden får siden til at se sikrere ud, mens risikoen øges. Opdatér verifikationsregistreringen kun, efter dens ejer har kontrolleret de relevante påstande.

At lade offentlig søgning eksponere interne detaljer. Interne eskalationsveje, hemmeligheder, kundeidentifikatorer, udnyttelsesinstruktioner og uannonceret adfærd bliver ikke sikre, fordi de reducerer supportindsatsen. Adskil offentlig hjælp fra autentificeret og intern viden.

Intern linking

Link opad til SEO-indlægstyper, når forfatteren måske har brug for en anden svarform. Link fra en dokumentationsforudsætning til den kanoniske how-to kun, når en læser skal fuldføre den opgave først. Link fra en fejltilstand til fejlfinding i stedet for at indsætte en generisk rettelsesliste. Link fra en versionsforskel til udgivelseshændelsen, når ændringshistorikken tilføjer kontekst; versionsnoter bør linke tilbage til den nuværende dokumentation som den holdbare sandhedskilde.

Organisér links omkring produktobjekter og læserens tilstand. Hold et specifikt link ved siden af udsagnet, der skaber det næste spørgsmål, i stedet for at stole på en lang liste af relaterede artikler.

Én kanonisk nuværende side bør eje stabil adfærd. Bevar versionssider kun for væsentligt anderledes adfærd, brugere stadig har brug for, og gør denne skelnen eksplicit. Brug stabile ankre såsom #retention, ikke #table-2.

Hvordan man måler resultater

Mål om brugere henter det korrekte svar for deres version. Trafik alene er et svagt bevis: en stigning kan afspejle et defekt produkt eller et forældet svar.

Registrér målrettede forespørgsler, rangordnings-URL, indekserbarhed, understøttede versioner, supportsøgninger, udgange til relaterede opgaver og en passende produktbegivenhed. Gennemgå derefter:

• søgevisninger og kvalificerede besøg for produktobjekt-, felt-, grænse-, syntaks-, rolle- og versionsforespørgsler;
• interne søgeforfinelser, nul-resultat-søgninger og gentagne søgninger, der afslører manglende terminologi;
• engagement med forankrede sektioner frem for udifferentieret tid på siden;
• klik til den korrekte opsætning, fejlfinding, udgivelse eller supportdestination;
• supporthenvendelser, hvis spørgsmål siden bør besvare, segmenteret efter version og rolle, hvor privatlivets fred tillader det;
• citater, der bevarer værdien sammen med dens plan, version, enhed eller forudsætning;
• forældede URL’er, der stadig rangerer eller bliver citeret efter konsolidering eller pensionering;
• dokumentationsændringer forårsaget af udgivelser, grænsefladeændringer, politikændringer og tilbagevendende supportsager.

Brug prompt-sporing til brandede opslagsspørgsmål og versionsvarianter. Brug kilde- og citationsindsigt til at se hvilken URL en svarmotor citerer, og om dens opsummering bevarer betingelser. Åbn AmICited Cockpit for at sammenligne citerede URL’er, synlighed, organisk landingssideaktivitet og den valgte produkt- eller supportbegivenhed over samme observationsvindue.

Følg hvordan vi måler resultater for at adskille opdagelse, repræsentation, engagement, opgaveprogression og fastholdelse. Annotér udgivelser og hændelser før fortolkning af bevægelse. Et nul-klik-svar virker kun, når det bevarer den nuværende værdi og dens betingelser.

FAQ

Ofte stillede spørgsmål