Agentisk produktdataside

Formål: gi en KI-handelsagent nok eksakt, oppdatert, maskinlesbar informasjon til å identifisere en vare, vurdere et tilbud, beregne om den kan leveres, forklare returrisikoen, og overlevere eller fullføre en transaksjon uten å gjetting.

Primært spørsmål: «Kan jeg kjøpe dette eksakte produktet for denne kunden, til denne prisen, på dette stedet, under disse leverings- og returvilkårene?»

En agentisk produktdataside er en stabil offentlig representasjon av ett produkt eller variantfamilie bygget for både inspeksjon og handling. I motsetning til en konvensjonell produktside , som kan stole på visuell hierarki og overbevisende kontekst, behandler denne typen identitet, tilbud, tilgjengelighet, frakt og returer som eksplisitte felt med omfang. De to formatene bør normalt sameksistere på én kanonisk URL: mennesker får forklaring og dokumentasjon; agenter får de samme faktaene i synlig tekst, strukturert markering og pålitelige handelsgrensesnitt.

Spørsmål den besvarer

Siden må la en handleagent besvare alle disse uten å måtte anta en manglende verdi:

• Hvilket eksakt produkt og variant beskriver denne posten?
• Hvilken selger-SKU, global identifikator, merke, modell, størrelse, farge, kapasitet og tilstand identifiserer det?
• Hva er gjeldende pris, valuta, enhet, skattebehandling og gyldig tilbudsperiode?
• Er den valgte varianten faktisk tilgjengelig, restbestilt, forhåndsbestillbar eller utgått?
• Kan det sendes til kundens destinasjon, til hvilken kostnad, via hvilken metode, og innen hvilket leveringsvindu?
• Hvem selger og oppfyller det, og hvor overføres ansvaret?
• Hva kan returneres, innen hvor mange dager, med hvilken metode, på hvis kostnad, og med hvilke unntak?
• Hvilken handling er gyldig nå: kjøp, reserver, be om tilbud, bli med i venteliste, eller velg et annet tilbud?

Siden er klar for agentisk bruk først når fravær er eksplisitt. «Frakt ikke oppgitt» er forskjellig fra gratis frakt; «tilgjengelighet ukjent» er forskjellig fra på lager.

Når du skal bruke denne innholdstypen

Bruk den når et produkt kan velges eller handles og en automatisert klient trenger mer enn en markedsbeskrivelse. Den er spesielt verdifull der varianter, selgere, destinasjoner eller policy-unntak gjør svaret betinget.

Ikke opprett en separat indekserbar «KI-versjon» som gjentar den menneskelige siden. Duplisering skaper konkurrerende kanoniske URL-er og to steder der flyktige fakta kan avvike. Bruk en separat representasjon bare når innholdsforhandling, et dokumentert endepunkt eller et ikke-indekserbart datasvar tjener et reelt klientbehov.

Best for disse forretningstypene

1. Netthandel . Den sterkeste matchingen fordi pris, variant, lager, frakt og returer allerede finnes i operasjonelle systemer. Oppgaven er å eksponere dem med de samme identifikatorene og omfanget som brukes i kassen.
2. Markedsplasser . Essensielt når ett produkt har flere selgere eller tilstander. Produktidentitet må holdes adskilt fra tilbudsidentitet slik at en agent ikke knytter én selgers pris til en annen selgers levering eller returvilkår.
3. Produsenter og industribedrifter . Verdifullt for modellnumre, teknisk kompatibilitet, pakningsmengder, regionale distributører, ledetider og tilbudsbasert tilgjengelighet. «Kontakt oss» bør fortsatt eksponere hva som kan pristilbys og hvilke fakta som varierer.
4. SaaS . Nyttig når en plan, tillegg, setepakke eller brukspakke faktisk er kjøpbar. Erstatt fysiske fraktfelt med aktiveringstidspunkt og regional eller kontobasert kvalifisering, mens du holder prisgrunnlag, fornyelse, kansellering og selgeridentitet eksplisitt.

Søkeintensjon

Intensjonen befinner seg ved beslutnings- og transaksjonsgrensen. Spørringer kombinerer et kjent produkt eller modell med «pris», «på lager», «levering til», «returer», en størrelse eller farge, eller en kjøpsinstruksjon. En KI-forespørsel kan legge til begrensninger i én setning: «Finn den svarte 256 GB-modellen under €900, levert til Oslo neste uke, med minst 30 dagers returrett.»

Det riktige svaret er ikke en generell anbefaling. Det er et begrensningsbevarende tilbud: eksakt variant, eksakt selger, gjeldende total, destinasjonskvalifisering, leveringsestimat, returbetingelser og en stabil handling. Hvis én betingelse ikke kan verifiseres, må svaret identifisere gapet i stedet for å stille slippe på den.

Sidestruktur

Ordbånd holder forklaringen proporsjonal. Det meste av det kritiske innholdet er feltdata, ikke prosa, og må genereres fra styrte kilder i stedet for å kopieres inn i redaksjonell tekst.

Påkrevde elementer

Plassering følger avhengighet: et tilbud kan ikke vurderes før identitet er stabil, og et leveringsløfte kan ikke vurderes før tilbud og destinasjonsomfang er kjent.

Frontmatter

Følg frontmatter-spesifikasjonen . På denne spesifikasjonssiden, bruk entity = "post-type-agentic-product-data" og schemaTypes = [ "Article", "FAQPage" ] fordi siden forklarer en innholdstype i stedet for å selge det fiktive eksemplet.

På en produsert handelsside må entity identifisere det stabile produktet, for eksempel northstar-travel-charger-65w, mens SKU og globale identifikatorer identifiserer salgbare varianter. Bruk Product for produktet og Offer for én selgers kjøpsbare tilbud; bruk AggregateOffer bare når den synlige siden virkelig oppsummerer flere tilbud. Legg til gjeldende frakt- og selgerreturpolicy-egenskaper. En produktside som inneholder synlig FAQ-innhold kan også kvalifisere for FAQPage, underlagt gjeldende søkemotorregler, men FAQ-markering er ikke en erstatning for Product- og Offer-data.

Sannhetskilden bør også styre feeder, API-er og kassen. Påkrevde operasjonelle felt inkluderer valuta, marked, selger, oppfyllelseseier, valgt SKU, prisgyldighet, tilgjengelighetstidsstempel, fraktdestinasjonsomfang, returpolicyomfang, kanonisk URL og dataeier. Skjemafullstendighet betyr at påkrevde beslutningsfelt både er fylt ut og korrekte – ikke at hver mulig egenskap vises.

Fullstendig eksempel

Denne fiktive siden demonstrerer minimumstransaksjonskontrakten. Verdiene er eksempler, ikke påstander om en ekte forhandler.

# Northstar 65 W reiselader — EU, svart

Northstar 65 W reiselader, SKU NS-65-EU-BLK og GTIN 09506000134352, selges ny av Northstar Direct for €49,00 inkludert mva. Denne svarte EU-varianten er på lager. Standard frakt til Norge koster €4,90 og er estimert til 1.–3. september 2026 ved bestilling før 14:00 CEST den 27. august.

## Produktidentitet

| Felt | Verdi |
|---|---|
| Merke | Northstar |
| Modell | Travel Charger 65 W |
| Selger-SKU | NS-65-EU-BLK |
| GTIN-14 | 09506000134352 |
| Variant | EU-plugg, svart |
| Tilstand | Ny |
| Inkludert | Lader og 1 m USB-C-kabel |

## Tilbud

| Selger | Pris | Valuta | Mva. | Tilgjengelighet | Gyldig til |
|---|---|---|---:|---|---|
| Northstar Direct | 49,00 | EUR | Mva. inkludert | På lager | 31. august 2026, 23:59 CEST |

Prisen gjelder for én NS-65-EU-BLK-enhet. Maksimalt antall på nett er fire per bestilling. Selger og oppfyllelsesleverandør er Northstar Direct.

## Frakt til Norge

| Metode | Kostnad | Behandling | Transitt | Estimert levering |
|---|---|---|---:|---|---|
| Standard sporbar | €4,90 | Samme virkedag før 14:00 CEST | 2–4 virkedager | 1.–3. september 2026 |
| Ekspress sporbar | €12,90 | Samme virkedag før 14:00 CEST | 1–2 virkedager | 31. august–1. september 2026 |

Litiumbatterier er ikke inkludert. Leveringsestimater ekskluderer adressekorrigeringer og transportørforstyrrelser. Beregn frakt på nytt etter at destinasjon eller handlekurvens innhold endres.

## Returer og garanti

Ubrukte produkter kan returneres innen 30 kalenderdager etter levering via nettskjemaet for retur. Kunden betaler returporto med mindre produktet er defekt eller feil. Åpnet emballasje aksepteres når laderen, kabelen og dokumentasjonen er komplette og uskadde. Refusjoner går tilbake til opprinnelig betalingsmiddel etter inspeksjon. En begrenset toårsgaranti dekker produksjonsfeil, men ikke utilsiktet skade eller væskeskade.

## Transaksjonsstatus

Verifisert mot katalog-, lager-, frakt- og retursystemer kl. 10:00 CEST den 27. august 2026. Revalider pris, lager, destinasjonskvalifisering, leveringsestimat og returomfang umiddelbart før kassen.

[Kjøp den svarte EU-varianten]

Eksemplet holder pris og gyldighet sammen, skiller behandling fra transitt, navngir returbetaleren og avgrenser alle flyktige påstander. Et menneske kan lese det; en agent kan kartlegge det til felt uten å tolke et reklameuttrykk.

Designgalleri

Bruk samme produkt, variant, selger, destinasjon og tidsstempel i hvert design slik at gjennomgangstester datforståelse i stedet for ulike eksempler.

Kvalitetssjekkliste

• Én kanonisk produktidentitet er adskilt fra SKU-nivå-varianter og selgernivå-tilbud.
• SKU-, GTIN-, ISBN- eller produsentdelenummerverdier tilhører den eksakte varianten; ingen identifikator er utledet eller oppdiktet.
• Produktnavn, merke, modell, tilstand, valgte attributter og kanonisk URL samsvarer i synlig innhold, skjema, feed og kasse.
• Pris inkluderer valuta, enhet eller faktureringsgrunnlag, skatteomfang, selger, kvantitetsregel og gyldighet der det er relevant.
• Tilgjengelighet beskriver valgt SKU og selger, ikke overordnet produkt eller en tilstøtende lagerpost.
• Frakt oppgir destinasjonsomfang, kostnad, terskel, behandlingstid, transittid, estimert levering og begrensninger uten å behandle et estimat som en garanti.
• Returer oppgir vindu, starthendelse, akseptert tilstand, metode, gebyrer, refusjonsvei og produkt- eller regionale unntak.
• Ukjente verdier identifiseres som ukjente; tomme celler innebærer aldri gratis, inkludert eller tilgjengelig.
• Flyktige fakta kommer fra operasjonelle systemer og eksponerer et meningsfylt verifiseringstidspunkt.
• JavaScript-deaktiverte og gjengitte svar eksponerer begge de kritiske identitets- og tilbudsfaktaene som trengs av tiltenkte klienter.
• Product- og Offer-markering samsvarer med synlig innhold og bruker riktig variant, selger, valuta og policyomfang.
• Kjøps- eller overleveringshandlingen bevarer variant, tilbud, destinasjon, kvantum og attribusjon.
• Utsolgte, forhåndsbestillbare, tilbudsbaserte og utgåtte tilstander endrer både meldingen og den tillatte handlingen.
• Automatiserte tester oppdager avvik mellom side, skjema, feed, API og kasse før et foreldet tilbud når en agent.
• Menneskeleg gjennomgang kontrollerer unntaksformulering, regulerte påstander og uvanlige frakt- eller returtilfeller som feltvalidering ikke kan vurdere.

Vanlige feil

Å behandle skjema som skjult produktkopi. Strukturerte data beskriver synlige fakta; de må ikke introdusere en bedre pris, annen vurdering, bredere tilgjengelighet eller returløfte enn siden viser.

Å bruke en overordnet SKU for hver variant. Et blått medium-plagg og et svart large-plagg er forskjellige salgbare valg. Bind identifikatorer, pris, bilde, lager og handling til den valgte varianten.

Å publisere pris uten omfang. «€49» er ufullstendig når mva., enhet, abonnementsperiode, selger, minimumskvantum, marked eller utløp endrer beløpet.

Å kalle ukjent frakt gratis. Frakt må beregnes eller være eksplisitt utilgjengelig for destinasjonen. En nullverdi er et kommersielt løfte, ikke en plassholder.

Å kombinere behandling og transitt. En todagers transportørtjeneste sendt etter fem dager er ikke todagers levering. Lagre og vis begge intervallene, og beregn deretter et estimert datospenn.

Å lenke kun til en generisk returnside. Agenten trenger gjeldende vindu og unntak på tilbudssiden, pluss en stabil policy-URL for detaljer. Kategoriunntak må ikke skjules bak lenken.

Å mellomlagre lager som redaksjonelt innhold. Beholdning kan endres mellom gjennomsøking og kasse. Bruk passende mellomlagringslevetid, ugyldiggjøring, tidsstempler og obligatorisk revalidering før forpliktelse.

Å opprette en ny «KI-produktside.» Parallelle indekserbare sider avviker og splitter signaler. Foretrekk én kanonisk kilde for menneske og maskin med alternative representasjoner kun for et dokumentert teknisk behov.

Å la CTA-en lyve. En utsolgt vare kan ikke ha en aktiv «Kjøp nå»-handling. Erstatt den med et lagervarsel, forhåndsbestilling, tilbud eller et alternativ som gjenspeiler den virkelige tilstanden.

Intern lenking

Lenk oppover til kategorisiden når en agent må velge mellom produkter, og sidelengs til den kanoniske produktside -spesifikasjonen når produksjonsteamet trenger menneskerettede dokumentasjons- og overtalelsesregler. Lenk til en dokumentasjonsartikkel for oppsett, kompatibilitetsdetaljer, stell eller etterkjøpsbruk i stedet for å overfylle transaksjonsfelt med instruksjoner.

Innenfor produktposten, hold lenker ved siden av betingelsen som skaper neste spørsmål: den fullstendige returpolicyen ved siden av den oppsummerte returregelen, leveringsbegrensninger ved siden av frakt, og kompatible tilbehør ved siden av den relevante spesifikasjonen. Bruk en intern lenkemodul kun for et lite sett med forklarte alternativer eller støttesider. Ikke få en agent til å navigere gjennom flere vage «lær mer»-lenker for å rekonstruere en transaksjon.

Hvert lenket tilbud må bevare variant- og selgerkontekst. Parameteriserte valg bør løses forutsigbart, og kanoniske regler bør hindre at filter-, valuta- og destinasjonstilstander multipliseres til dupliserte indekserbare URL-er.

Hvordan måle resultater

Mål pålitelig produktoppløsning og transaksjonsprogresjon, ikke bare sidetrafikk. Etabler en baseline per marked, enhet, klient, produkt, variant og selger der volum tillater det.

Spor:

• gyldige produkter og salgbare varianter med fullstendige identifikatorer;
• Product- og Offer-poster som består teknisk validering og kommersiell avstemming;
• avvik i pris, valuta, lager, selger, frakt, returer og valgt SKU på tvers av side, skjema, feed, API og kasse;
• gjennomsøkings- eller agentforespørsler som mottar brukbare kritiske data uten skript-, samtykke-, autentiserings- eller tidsavbruddsfeil;
• handlesvar og siteringer som bevarer variant, selger, pris, tilgjengelighet, destinasjon, levering og policybetingelser;
• produktvalg-, legg-i-handlekurv-, kassestart-, tilbuds-, reservasjons- og fullførte ordrehendelser tilskrevet den opprinnelige klienten eller overleveringen;
• mislykkede overleveringer forårsaket av utdatert lager, endret pris, ikke-støttet destinasjon, ugyldig variant, utløpt økt eller policyuoverensstemmelse;
• kanselleringer, returer og kundeservicehenvendelser forårsaket av et faktum som agenten presenterte feil eller utelot;
• tid fra endring i kildesystem til korrigert offentlig representasjon.

Bruk KI-tilgjengelighet og agentberedskap for å teste om automatiserte klienter kan nå og tolke handelsflaten. Åpne AmICited Cockpit for å sammenligne synlighet, siterte kilder, landingsaktivitet og kommersielle resultater over samme observasjonsperiode.

Følg hvordan vi måler resultater for å skille oppdagelse, korrekt representasjon, engasjement, transaksjonsfremgang og inntekter. Annoter katalogmigreringer, priskampanjer, lagerhendelser, policyendringer og protokollutgivelser før du tilskriver bevegelse. Et sitert produktsvar er ikke en suksess hvis tilbudet ikke overlever kassevalidering.

FAQ

Ofte stilte spørsmål