Dokumentationsartiklar: Versionsreferens för befintliga användare

En dokumentationsartikel är en underhållen referens för någon som redan använder en produkt, ett API, en tjänst, en enhet eller en operativ process. Den besvarar en precis uppslagsfråga – vad en inställning gör, vilka värden ett fält accepterar, vilken åtkomst som krävs, vilken version som beter sig på detta sätt eller var en gräns gäller – utan att tvinga läsaren att först passera genom ett marknadsföringsargument.

Dess kontrakt är omfattning → förkunskaper → aktuellt beteende → exakt referens → undantag → relaterad uppgift. Sidan lyckas när en användare hämtar rätt fakta för rätt version och roll. Att göra varje gränssnittsetikett till en offentlig webbadress hjälper inte.

Frågor den besvarar

Den primära frågan är: “Vad betyder detta produktbeteende i min version och kontext?” Stödfrågor inkluderar:

• Gäller denna sida för min produkt, plan, roll, region, plattform och version?
• Vad måste redan vara sant innan jag använder denna funktion eller refererar till detta fält?
• Vilka är de accepterade värdena, standardinställningarna, begränsningarna, formaten och bieffekterna?
• Vilket beteende är aktuellt, och vad ändrades från en tidigare version?
• Vilket exempel demonstrerar regeln utan att dölja viktiga förutsättningar?
• Vad bör jag läsa härnäst om jag behöver en procedur, diagnos eller ändringshistorik?
• Är denna information säker och användbar i offentlig sökning, eller kräver den autentiserad kontext?

När du ska använda denna inläggstyp

Använd dokumentation när en stabil sida måste stödja upprepad uppslagning. Ämnet behöver en auktoritativ ägare, testbart beteende och en underhållssignal såsom en release, API, plan eller gränssnittsförändring.

En sida som heter “Hur man konfigurerar exportfält” kan fortfarande vara dokumentation när dess varaktiga värde är en fältkatalog och användare hoppar direkt till enskilda parametrar. Omvänt är “Exportera din första rapport” en instruktionsguide när läsaren måste följa en sekvens och verifiera en nedladdad fil. Rubrikens grammatik avgör inte formatet; läsarens uppgift och svarets form gör det.

Bäst för dessa företagstyper

1. SaaS. Den starkaste passformen eftersom roller, planer, inställningar, integrationer, API:er, datamodeller och releasetakt skapar exakta referensbehov. Dokumentation bör skilja gränssnittsbeteende från API-beteende och användarbehörigheter från prenumerationsrättigheter.
2. E-handel. Starkt för handelsadministration, produktflöden, betalningsregler, returer, integrationer och användning efter köp. Separera kundsupport från handelsdokumentation så att en shoppare inte hamnar på en implementationsreferens.
3. Marknadsplatser. Starkt där köpare, säljare, leverantörer och administratörer ser olika tillstånd. Varje artikel måste identifiera aktören eftersom samma etikett kan exponera olika kontroller eller skyldigheter.
4. Byråer. Användbart för kundportaler, leveransstandarder, återkommande arbetsflöden och delad verktygsuppsättning. Publicera återanvändbar kundreferens offentligt endast när den inte exponerar interna kontroller, inloggningsuppgifter eller proprietära operativa detaljer.
5. B2B-tjänster. Användbart för introduktionssystem, dataöverlämningar, filspecificeringar, godkännandestatus och tjänsteportaler. Undvik att presentera ett avtalsåtagande som ett generiskt hjälpcenterfaktum när villkoren varierar per konto.
6. Tillverkare och industriföretag. Värdefullt för kontroller, programvara, kompatibilitet, konfiguration, underhållsregister och tekniska parametrar. Säkerhetskritiskt material kräver kontrollerad granskning, explicit modelltillämplighet och en väg till den auktoritativa manualen.

Sökintention

Sökintention är det resultat en person förväntar sig från en sökfråga. Dokumentationsintention är vanligtvis navigationsmässig plus informationsmässig: sökaren känner till produkten eller objektet och vill ha ett exakt faktum, såsom “Northstar exportlagring”, “Northstar statusvärden” eller “Northstar API-sidstorlek”. Varumärke, funktion, felfri uppgiftsspråk, version och plattform förekommer ofta tillsammans.

Det ideala resultatet öppnar nära svaret. Använd beskrivande rubriker, stabila ankare, accepterade värden och versionskvalificerare. Ett extraherat uttalande måste bevara sitt villkor: “På Team- och Enterprise-planer förblir slutförda exporter tillgängliga i 30 dagar.”

Offentlig dokumentation bör rankas när den besvarar en varaktig fråga utan att avslöja kontodata: supportade format, offentliga API-fält, kompatibilitet, begränsningar, konfigurationsbetydelse och dokumenterat beteende.

Dokumentation bör inte rankas när den speglar en UI-etikett, duplicerar en aktuell sida, täcker en föråldrad version utan fortsatt behov, exponerar känslig detalj eller behöver privat kontokontext. Använd autentiserad hjälp, vägledning i appen, noindex, konsolidering eller en tydlig arkivstatus istället. Sökefterfrågan rättfärdigar aldrig att publicera hemligheter eller exploateringsvägar.

Sidstruktur

Ordband är produktionskontroller, inte minimikvoter. En snäv fältreferens kan vara kortare; en versionshanterad funktionsreferens kan behöva mer utrymme eftersom tillämplighet och undantag förhindrar kostsamma misstag.

De flesta substantiella dokumentationsartiklar ligger mellan 1 500 och 2 800 ord. Lägg till detaljer endast där de förhindrar tvetydighet: omfattning, förkunskap, värde, standard, bieffekt, undantag eller versionsändring.

Obligatoriska element

Referensläsare skannar. Placera tillämplighetsinformationen före referensen så att ett tekniskt korrekt värde inte tillämpas på fel plan eller release.

Frontmatter

Följ frontmatter-specifikationen. På denna inläggstypspecifikation, entity = "post-type-documentation-article". På en producerad dokumentsida, använd ett stabilt produktobjektvärde såsom northstar-scheduled-export-settings, inte ett marknadsföringsuttryck som anstrangningsfri-rapportering och inte ett versionsnummer som skulle tvinga fram en ny identitet efter varje release.

Använd schemaType = "Article". Schemmamarkering måste beskriva den synliga sidan; välj inte HowTo enbart för att ett exempel innehåller tre åtgärder. Lägg till FAQ-strukturerad data endast när synliga frågor och svar matchar den exakt. API-referens eller programvaruspecifik semantik kan representeras någon annanstans i webbplatsens datamodell, men en mer specifik schematyp bör inte uppfinnas i frontmatter utan mallstöd.

Lagra de fält som underhållssystemet kan upprätthålla: produktområde, planer, roll, plattform, versionsintervall, verifierat datum, ägare och ersättnings-URL. lastmod innebär att beteende granskades, inte att ett stavfel åtgärdades. Bevara den kanoniska webbadressen över kompatibla releaser.

Fullständigt exempel

Detta fiktiva analys-exempel demonstrerar en referenssida, inte en komplett exportprocedur.

# Inställningar för schemalagd export

Schemalagda exporter skapar en CSV- eller JSON-fil från en sparad rapport vid en fast UTC-tid och levererar den till en godkänd destination. De är tillgängliga för redaktörer och administratörer på Team- och Enterprise-planer. Denna referens gäller Northstar Analytics webbapp 6.4 och verifierades den 27 augusti 2026.

## Innan du använder denna referens

Du behöver en befintlig sparad rapport, en aktiverad destination samt redaktörs- eller administratörsåtkomst. En visningsbehörig användare kan ladda ner en befintlig export men kan inte skapa eller ändra ett schema. Destinationsadministratörer kan införa ytterligare begränsningar för lagring eller filstorlek.

## Referens för inställningar

| Inställning | Accepterat värde | Standard | Effekt och begränsningar |
|---|---|---|---|
| Namn | 1–80 tecken | Rapportnamn | Identifierar schemat; att ändra det byter inte namn på tidigare filer. |
| Format | `csv` eller `json` | `csv` | CSV använder rapportens synliga kolumnordning. JSON använder stabila fältnycklar. |
| Körningstid | `HH:MM` i UTC | `08:00` | Sommartidsändringar flyttar inte UTC-körningstiden. |
| Inkludera tomma rader | På eller av | Av | Tillgängligt endast för tabellrapporter; ignoreras för sammanfattningsrapporter. |
| Lagring | 1–30 dagar | 7 dagar | Befintliga filer löper ut oberoende av schemat som skapade dem. |

## Beteende och gränser

Ett schema läser den sparade rapportkonfigurationen när körningen börjar. Att redigera rapporten ändrar därmed framtida filer men inte redan genererade filer. Att pausa ett schema förhindrar nya körningar; det tar inte bort lagrade filer. Att ta bort destinationen inaktiverar leverans och placerar schemat i `Behöver åtgärd`.

## Exempel

För en daglig CSV som behövs kl. 09:00 i Bratislava under normaltid, ställ in UTC-körningstiden till `08:00`. Granska tiden när sommartidsregler ändras eftersom scheman förblir låsta till UTC.

Ogiltigt exempel: att ange `Europe/Bratislava` i körningstidsfältet. Fältet accepterar en UTC-tid, inte en tidszonsbeteckning.

## Versionsskillnader

- Version 6.4: JSON-exporter använder stabila fältnycklar; den visade kolumnetiketten blir inte längre nyckeln.
- Versionerna 6.1–6.3: JSON-nycklar följer visade kolumnetiketter. Befintliga integrationer bör kontrolleras före uppgradering.
- Före 6.1: schemalagd JSON-export är inte tillgänglig. Använd CSV eller uppgradera till en supportad version.

## Om en export inte anländer

Lägg inte till spekulativa lösningar här. Öppna felsökningsguiden "Schemalagd export kom inte fram", som kontrollerar schemastatus, destinationsauktorisering, filbegränsningar och tjänsteincidenter i diagnostisk ordning.

## Relaterade uppgifter

- Skapa din första schemalagda export — ordnad installation och framgångskontroll
- Felsök en saknad schemalagd export — symptomledd diagnos
- Northstar Analytics 6.4 versionsinformation — beteendeförändringar och migrationsanteckning

## Verifieringsprotokoll

Verifierad mot webbapp 6.4 av rapportproduktägaren den 27 augusti 2026. Granska när behörigheter, format, lagring, schemaläggning eller destinationsbeteende ändras.

Designgalleri

Använd identiska inställningar, begränsningar, roller och versionsfakta över varianter så att designgranskningen mäter hämtningshastighet snarare än kopieskillnader.

Kvalitetskontrollista

En dokumentationsartikel är redo först när varje tillämpligt påstående är sant:

• Öppningen namnger det exakta objektet och ger det aktuella beteendet före bakgrund eller fördelar.
• Produkt, plan, roll, region, plattform och versionstillämplighet är explicit där de ändrar svaret.
• Förkunskaper visas före inställningar eller exempel som är beroende av dem.
• Varje teknisk term definieras vid första användning, uttrycks via en bekant gränssnittsetikett eller länkas till dess kanoniska definition.
• Fält, värden, standardinställningar, enheter, format, begränsningar och bieffekter kommer från en auktoritativ källa eller verifierat produkttest.
• Referenstabeller använder konsekventa dimensioner; tomma celler döljer inte okända standardinställningar eller undantag.
• Exempel anger de villkor som gör dem giltiga och inkluderar ett ogiltigt eller gränsexempel när förvirring är sannolik.
• Varningar visas före destruktivt, oåterkalleligt, säkerhetskänsligt, kostsamt eller behörighetsändrande beteende.
• Skärmbilder inkluderar en infångningsversion och textekvivalent; bilden är inte den enda källan till ett värde eller en instruktion.
• Rubriker och ankare matchar de substantiv användare söker efter och förblir stabila för djup-länkar.
• Materiella versionsskillnader anger det påverkade intervallet, aktuell ersättning och migrationskonsekvens.
• Det verifierade datumet återspeglar en beteendegranskning, och ett namngivet team eller en roll ansvarar för nästa granskning.
• Procedurer, diagnos och releasehistorik länkar till kanoniska syskonsidor istället för att dupliceras ofullständigt.
• Offentlig indexering är avsiktlig; föråldrat, duplicerat, privat och säkerhetskänsligt material har lämplig sökhantering.
• FAQ-poster matchar synliga svar, och CTA respekterar en supportstadieläsares nästa uppgift.

Vanliga misstag

Att skriva en funktionslandningssida för en befintlig användare. “Lås upp kraftfulla exporter” försenar det faktum läsaren behöver. Led med beteende, tillämplighet och begränsningar; förmånstext hör bara hemma där den förtydligar syftet.

Att göra varje uppgift till dokumentation. En 20-stegsinstallation begravd under en fältlista tjänar varken uppslagning eller slutförande. Dela upp den ordnade proceduren i en instruktionsguide och länka den från relevant förkunskaps- eller relaterad-uppgiftssektion.

Att publicera en sida per gränssnittsetikett. Tunna sidor överlappar och multiplicerar underhåll. Gruppera fält kring ett stabilt produktobjekt om inte en inställning har distinkt beteende.

Att använda “senaste” som version. Senaste ändras. Ange den testade releasen, supportade intervallet, plattformen och verifieringsdatumet, uppdatera dem sedan genom releaseprocessen.

Att hålla gamla och nya sidor indexerbara utan avgränsning. Konsolidera kompatibelt beteende; märk annars den gamla versionen, länka till den aktuella sidan och kontrollera indexering avsiktligt.

Att dölja förkunskaper inuti fel. Om endast administratörer kan ändra ett fält, säg det före referensen. Låt inte en visningsbehörig användare upptäcka rollgränsen efter att ha följt ett exempel.

Att kopiera skärmbilder istället för beteende. En infångning är bevis på ett gränssnittstillstånd, inte specifikationen. Skriv etiketter, sökvägar, värden och villkor i tillgänglig text och registrera den infångade versionen.

Att fejka färskhet. Att ändra datumet utan att testa om beteendet gör sidan säkrare till det yttre samtidigt som risken ökar. Uppdatera verifieringsprotokollet endast efter att dess ägare kontrollerat de tillämpliga påståendena.

Att låta offentlig sökning exponera intern detalj. Interna eskaleringsvägar, hemligheter, kundidentifierare, exploateringsinstruktioner och oannonserat beteende blir inte säkra för att de minskar supportarbete. Separera offentlig hjälp från autentiserad och intern kunskap.

Intern länkning

Länka uppåt till SEO-inläggstyper när författaren kan behöva en annan svarsform. Länka från en dokumentationsförkunskap till den kanoniska instruktionsguiden endast när en läsare måste slutföra den uppgiften först. Länka från ett feltillstånd till felsökning istället för att infoga en generisk åtgärdslista. Länka från en versionsskillnad till releasehändelsen när ändringshistoriken tillför kontext; versionsinformation bör länka tillbaka till den aktuella dokumentationen som den varaktiga sanningskällan.

Organisera länkar kring produktobjekt och läsartillstånd. Håll en specifik länk bredvid påståendet som skapar nästa fråga istället för att förlita dig på en lång lista med relaterade artiklar.

En kanonisk aktuell sida bör äga stabilt beteende. Behåll versionssidor endast för materiellt annorlunda beteende som användare fortfarande behöver, och gör den distinktionen explicit. Använd stabila ankare såsom #retention, inte #tabell-2.

Hur man mäter resultat

Mät om användare hämtar rätt svar för sin version. Trafik ensam är svaga bevis: en ökning kan spegla en trasig produkt eller ett föråldrat svar.

Registrera målsökfrågor, rankningsadress, indexerbarhet, supportade versioner, supportsökningar, utgångar till relaterade uppgifter och en lämplig produktaktivitet. Granska sedan:

• sökintryck och kvalificerade besök för produktobjekt-, fält-, gräns-, syntax-, roll- och versionsfrågor;
• interna sökförfiningar, sökningar utan resultat och upprepade sökningar som avslöjar saknad terminologi;
• engagemang med ankrade sektioner snarare än odifferentierad tid på sidan;
• klick till rätt installation, felsökning, release eller supportdestination;
• supportkontakter vars fråga sidan borde besvara, segmenterade efter version och roll där integriteten tillåter;
• citeringar som bevarar värdet tillsammans med dess plan, version, enhet eller förkunskap;
• föråldrade webbadresser som fortfarande rankas eller citeras efter konsolidering eller avveckling;
• dokumentationsändringar orsakade av releaser, gränssnittsändringar, policyändringar och återkommande supportärenden.

Använd sökordsbevakning för varumärkta uppslagsfrågor och versionsvarianter. Använd käll- och citeringsintelligens för att se vilken webbadress en svarsmotor citerar och om dess sammanfattning bevarar villkor. Öppna AmICited Cockpit för att jämföra citerade webbadresser, synlighet, organisk landningsaktivitet och den valda produkt- eller supportaktiviteten över samma observationsperiod.

Följ hur vi mäter resultat för att separera upptäckt, representation, engagemang, uppgiftsframsteg och retention. Kommentera releaser och incidenter innan du tolkar rörelser. Ett klickfritt svar fungerar bara när det bevarar det aktuella värdet och dess villkor.

FAQ

Vanliga frågor