WooCommerce agent-checkout analyse

En kunde trenger ikke lenger å besøke butikken din for å handle i den. I 2026 kan en KI-agent lese katalogen din, legge til et produkt og fullføre en WooCommerce-ordre på kjøperens vegne, og alt skjer gjennom et grensesnitt, ikke i en nettleserfane. Ordren lander i adminpanelet. Pengene kommer inn. Og analysen din registrerer ingenting.

Dette er ikke hypotetisk. WooCommerces egen utviklerblogg la ut veikartet for KI og agentic commerce, inkludert tester av umiddelbar kasse utenfor butikken med partnere som Google og Stripe, og økosystemet fyller seg inn rundt den raskere enn sporingsutvidelsene rekker å følge med. Hos WPPoland bygger og instrumenterer vi WooCommerce-butikker for kunder som selger i hele EU, og de første butikkene som får agent-ordrer, ser allerede gapet mellom hva de solgte og hva dashbordene sier de solgte.

Her er mekanismen, de konkrete tingene som ryker, hvorfor Conversions API ikke redder deg automatisk, og måten å instrumentere det riktig på.

Omfanget vokser raskt: ifølge Stripe håndterer betalingsløsningen Link nå rundt 200 AI-agenter, mot rundt 70 i selskapets tall fra september (Upstarts Media, 18.10.2026). Stripe påpeker at Anthropic og OpenAI bruker Link, men ennå ikke til kjøp gjennom agenter.

#Hva skjer med analysen din når en KI-agent handler

Det korte svaret: ingenting skjer med analysen din, og det er problemet. Rapporteringsstakken din ble bygget på antakelsen om at hvert kjøp innledes av et menneske som laster sider i en nettleser. En agent bryter den antakelsen. Den fullfører ordren på serversiden, så hvert nettleserbaserte signal analysen din er avhengig av, rett og slett aldri utløses.

Du står igjen med en WooCommerce-ordre uten en tilhørende sesjon i Google Analytics, uten en tilhørende hendelse på Meta-pikselen og uten attribusjon, fordi det ikke var noe klikk, ingen UTM-merket landing og ingen nettleser å lese noe fra. Inntekten er ekte. Sporet er tomt.

#Hvorfor sporingen din bor i nettleseren

Mesteparten av målingen i WooCommerce er klientside av design. Google Analytics 4 samler inn via gtag.js, et skript som den besøkendes nettleser laster ned og kjører. Meta-pikselen er samme idé: et kodesnutt som kjører i nettleseren og rapporterer PageView, AddToCart, InitiateCheckout og Purchase etter hvert som kjøperen beveger seg gjennom trakten. Google Tag Manager, containeren de fleste butikker ruter disse taggene gjennom, er også et nettlesermiljø.

Hvert eneste av disse verktøyene trenger en rendret side og et kjørt skript. Det er det ene enkeltpunktet for svikt. Ta bort nettlesersesjonen, og du har tatt bort det eneste stedet disse taggene noen gang skulle kjøre.

En agent-checkout tar bort nettlesersesjonen.

#Hvilke WooCommerce-rapporter ryker med agent-ordrer

Det er verdt å være presis, for “analysen ryker” skjuler hvor mange separate rapporter som går galt samtidig.

1. GA4-trakt og kjøpshendelser. Ingen page_view, ingen add_to_cart, ingen begin_checkout, ingen purchase. Ordren når aldri GA4, så inntekt, konverteringsrate og traktfrafall er alle underrapportert.
2. Meta-pikselkonverteringen. Ingen Purchase-hendelse når Meta fra nettleseren, så salget mangler i annonserapporteringen og i optimaliseringssignalet algoritmen lærer av.
3. Attribusjon. Attribusjonsmodeller leser et klikk, en referrer, UTM-parametere eller en lagret klient-ID fra nettlesersesjonen. En agent-ordre har ingen av disse, så den kan ikke attribueres til en kanal, en kampanje eller en kilde. Den dukker i beste fall opp som direkte eller ikke-tildelt, og ofte ikke i det hele tatt.
4. Remarketing-målgrupper. En kjøper pikselen aldri så, kan ikke legges til i en kundemålgruppe eller ekskluderes fra en prospekteringsmålgruppe. Du fortsetter å betale for å annonsere til folk som allerede har kjøpt via en agent.
5. Avkastning på annonsebruk. Inntekten i WooCommerce slutter å stemme med inntekten i annonsedashbordene dine. ROAS ser dårligere ut enn virkeligheten, og den naturlige, men feilaktige reaksjonen er å kutte nettopp de kampanjene som virker.

Ingenting av dette kaster en feilmelding. Det er det som gjør det farlig. Butikken kjører videre, ordrene kommer videre, og dashbordene glir stille bort fra sannheten.

#Fanger Meta Conversions API opp agent-ordrer

Den åpenbare innvendingen er at Meta allerede løste server-side-sporing. Conversions API sender hendelser rett fra serveren din, uten nettleser. Så agent-ordrer burde være dekket.

Det er de ikke, i hvert fall ikke med en standardinstallasjon, og grunnen er deduplisering. Conversions API er designet for å jobbe ved siden av pikselen, ikke i stedet for den. Du forventes å sende samme konvertering to ganger, én gang fra nettleser-pikselen og én gang fra serveren, og Meta slår paret sammen til ett via en delt event_id og event_name. Det er hele poenget: måle pålitelig uten å dobbelttelle.

En agent-ordre har ingen nettleserhalvdel. Det finnes ingen pikselhendelse å pare med serverhendelsen, og de populære CAPI-oppsettene for WooCommerce bygger dedup-nøkkelen i det øyeblikket takkesiden rendres. For en agent-ordre rendres den siden aldri, så nøkkelen skapes aldri, og serverhendelsen blir enten ikke sendt eller sendt uten identitetsinformasjonen Meta forventer. Den samme dedup-modellen som beskytter deg mot å dobbelttelle nettleser-pluss-server-ordrer, mister stille en ordre som bare noen gang fantes på serveren.

Server-side-sporing er rett retning. Å lime den på en nettleser-først-antakelse er ikke det samme som å være klar for agenter.

#Slik sporer du WooCommerce-kjøp på serversiden

Den varige løsningen er å slutte å behandle rendringen av takkesiden som sannhetens øyeblikk og begynne å behandle selve ordren som sannhetens øyeblikk. Ordren er den ene tingen som pålitelig finnes uansett hvordan salget ble lagt inn.

Konkret:

• Utløs kjøpet på serversiden fra en ordre-hook. WooCommerce reiser woocommerce_order_status_completed og beslektede betalings-hooks på serveren for hver eneste ordre, nettleser eller agent. Send GA4-kjøpet ditt via Measurement Protocol og Meta-Purchase via Conversions API fra den hooken, slik at innsamlingen ikke lenger avhenger av at en side laster.
• Dedupliser på ordre-ID-en. Bruk WooCommerce-ordre-ID-en som event_id. En nettleser-ordre og dens server-tvilling smelter fortsatt sammen til én fordi begge bærer samme ordre-ID, og en ren agent-ordre går rent gjennom fordi nøkkelen ikke trenger en pikselmotpart.
• Merk ordrekilden. Lagre hvor ordren kom fra, gateway-ID-en eller et dedikert meta-felt, ved opprettelse. Nå kan hver rapport skille agent-inntekt fra nettleser-inntekt i stedet for å smelte dem til et gjennomsnitt som skjuler skiftet.
• Bygg attribusjonen om rundt identitet du faktisk har. For agent-ordrer er kundekontoen, e-posten eller agentens egne identifikatorer det du har. Kartlegg disse bevisst mot kanalene dine i stedet for å håpe at en UTM-streng dukker opp.

Dette er alminnelig WooCommerce-ingeniørarbeid, hooks, webhooks og server-til-server-hendelser, men det må designes for agent-tilfellet fra starten, ikke lappes på en piksel som forutsetter en nettleser.

#Hvordan WooCommerce registrerer hvor en ordre kom fra

Før du lager et eget kildefelt, bør du se på de to stedene der WooCommerce allerede skriver opphavsdata, fordi begge oppfører seg ulikt med agent-ordrer.

Det første er ordreegenskapen created_via. I kildekoden til WooCommerce setter den klassiske shortcode-kassen den til checkout (class-wc-checkout.php), Store API setter den til store-api (OrderController.php), og ordre-endepunktet i REST API v3 setter den til rest-api, med mindre forespørselen sender med sin egen created_via-verdi (class-wc-rest-orders-controller.php). Den siste detaljen er nyttig: en integrasjon som oppretter agent-ordrer over REST, kan merke dem med en egen verdi. Begrensningen ligger i Store API. Blokk-kassen i nettleseren går også gjennom Store API, så store-api alene skiller ikke en kunde i en fane fra en agent som kaller det samme endepunktet.

Det andre er ordreattribusjon. WooCommerce sin dokumentasjon om ordreattribusjon beskriver et sett med sbjs_-informasjonskapsler som holder henviser, UTM-parametere, enhetstype og sidevisninger i økten. De leses først når ordren legges inn, og lagres som ordremetadata med prefikset _wc_order_attribution. Opphavsetiketten i ordrelisten bygges fra en kildetype: UTM, organisk, henvisning, direkte, mobilapp, webadministrator eller salgssted. Alt annet havner på “Ukjent” (OrderAttributionMeta.php). En agent som aldri laster butikken din, får aldri disse informasjonskapslene, så ordrene dens dukker opp i kolonnen Opphav som Ukjent, sammen med alle andre ordrer der dataene forsvant.

Den praktiske rekkefølgen blir derfor: les created_via først, legg til din egen markering bare der den ikke skiller agent fra nettleser, og se en voksende andel ukjent opphav som et tidlig tegn på at agenttrafikken har startet.

#Hva ACP og UCP gir forhandleren av attribusjonsdata

Om en agent-ordre kommer med noen attribusjon, avhenger av protokollen bak. WooCommerce sitt eget innlegg nevner Stripes Agentic Commerce Protocol og MCP-arbeidet; det nevner ikke UCP eller AP2. Sjekk derfor hva betalings- eller agentintegrasjonen din faktisk implementerer før du stoler på noen av feltene nedenfor.

Agentic Commerce Protocol vedlikeholdes av OpenAI og Stripe, er fortsatt i beta, publiseres under Apache 2.0 og versjoneres etter dato. I kassespesifikasjonen 2026-04-17 jobber agenten gjennom POST /checkout_sessions, deretter /complete eller /cancel på den økten. Både opprettings- og fullføringskallet godtar et valgfritt affiliate_attribution-objekt: en påkrevd provider, pluss enten et token eller en publisher_id, valgfrie id-er for kampanje, annonsemateriell og underssporing, og et touchpoint med verdien first eller last. Spesifikasjonen sier at objektet bare kan skrives: det lagres sammen med ordren, men returneres ikke i svaret. Ordren som returneres ved fullføring, har sin egen id, checkout_session_id, en permalink_url og en status, og forhandleren sender senere ordrehendelser tilbake til agentplattformen, signert med en HMAC i headeren Merchant-Signature. checkout_session_id er nøkkelen det lønner seg å lagre på WooCommerce-ordren: den knytter ordren til agentsamtalen som skapte den.

Oppdatering, 28. oktober 2026. Kasseøkten som er beskrevet over, er nå en vei bare for godkjente partnere. 24. mars 2026 begrenset OpenAI Instant Checkout i ChatGPT til godkjente partnere, lot forhandlere bruke sin egen kasse og sa at selskapet konsentrerer seg om at kundene skal finne produktene, mens ACP brukes til å dele produktdata og kampanjer (OpenAI). For de fleste WooCommerce-butikker ender derfor et kjøp som starter i ChatGPT, som et besøk i din egen kasse i nettleseren. Det besøket laster butikken, så sbjs_-informasjonskapslene, kolonnen Opphav og GA4- og Meta-taggene dine ser det som enhver annen økt: attribusjonen skjer på nettstedet ditt, ikke i et ACP-felt. Før du lager en egen regel for slike besøk, sjekk i dine egne ordredata hvilken henviser eller hvilke UTM-parametere de faktisk kommer med.

Universal Commerce Protocol har et generelt attribusjonsfelt. Oversikten over spesifikasjonen definerer et attribution-felt som plattformer kan sende med forespørsler om handlekurv, kasse og katalog. Det bærer de samme kampanjeparameterne og klikk-id-ene, som gclid eller fbclid, som ellers ville kommet i en URL. UCP foreskriver ingen attribusjonsmodell, feltet er valgfritt, og spesifikasjonen påpeker at klikk-id-er og øktnøkler kan være personopplysninger, så dine regler for samtykke og lagringstid gjelder også her. Ordren kan vise en skrivebeskyttet kopi av kassens attribusjon, og hendelser i ordrens livsløp går til plattformen som webhooks med Standard Webhooks-headere.

AP2, kunngjort 16. september 2025, er et tillitslag for betalinger og ikke en analysekilde. Det signerte Checkout Mandate og Payment Mandate beviser hva brukeren godkjente. De forteller deg at en agent la inn ordren, ikke hvilken kampanje som førte dit.

#Begrensninger i Measurement Protocol og Conversions API for agent-ordrer

Å flytte innsamlingen til serveren løser de manglende hendelsene, men begge API-ene har regler som en ordre uten sidevisning støter på.

GA4 sin Measurement Protocol forventer for nettstrømmer en client_id som samsvarer med ID-en Google-taggen laget i besøkendes nettleser. En agent-ordre har ingen slik ID, så du må lage en, og bør lagre den på ordren slik at refusjoner og senere hendelser bruker den samme. Hendelser kan tilbakedateres opptil 72 timer, en forespørsel kan inneholde maks 25 hendelser, og api_secret må bli på serveren. Google beskriver protokollen som laget for servermiljøer, med hendelser som kobles til det gtag.js samler inn. En agent-ordre sendt med en nylaget client id teller derfor som en ny bruker, ikke som slutten på en tidligere nettleserøkt.

Metas parametere for serverhendelser har en strengere frist: event_time kan være maks 7 dager gammel, og én eldre hendelse får Meta til å avvise hele forespørselen. Hver hendelse trenger en action_source, en av email, website, app, phone_call, chat, physical_store, system_generated, business_messaging eller other. Sender du website, er event_source_url påkrevd, og en agent-ordre har ingen side-URL å sette inn. Metas liste har ingen verdi for KI-agenter, så velg en bevisst, noter hvorfor og hold deg til den, fordi et senere bytte gjør før-og-etter-sammenligninger vanskeligere. Den samme siden bekrefter at et ordrenummer er en gyldig event_id.

Disse fristene er også budsjettet ditt for nye forsøk. Feiler hooken som sender hendelsen, har et nytt forsøk i kø 72 timer hos GA4 og 7 dager hos Meta før hendelsen er tapt.

#Agent-ordrer, bokføringsloven og SAF-T

I Norge har dette gapet et andre lag. En agent-ordre må likevel bokføres etter bokføringsloven og inngår i SAF-T-uttrekket til Skatteetaten, så for regnskapet finnes ordren i høyeste grad, selv når GA4 aldri så den. Det er ofte første stedet butikkeieren merker problemet: antallet bilag i regnskapet stemmer ikke med antallet transaksjoner i markedsføringspanelet. Å avstemme det bokførte salget mot tallene i annonsedashbordet er en praktisk måte å i det hele tatt oppdage hvor mange ordrer som kom via agenter, før du fikser innsamlingen på serversiden.

#Bør en WooCommerce-butikk slippe inn AI-agenter

Før en agentordre kan forsvinne fra GA4, må agenten i det hele tatt komme gjennom kassen. The Verge skrev 17. oktober 2026 at stadig flere tjenester stenger døren for agenter: Yelp slipper bare inn agenter som betaler for datalisensen, Delta Air Lines hindrer dem i å bestille billetter, og JPMorgan Chase og Charles Schwab sperrer dem ute fra kontoer av sikkerhetshensyn. Amazon stengte ute handleagenten til Perplexity og saksøkte selskapet; etter at en ankedomstol opphevet forbudet i august, leverte Amazon et endret søksmål. På den andre siden har Meta inngått avtaler med Walmart, Gap, Sephora og Best Buy slik at assistenten Muse kan handle der, og Shopify har åpnet butikkene sine for agenter.

For en WooCommerce-butikk er den senere delen av artikkelen viktigst: agenter stopper også i antibot-systemer som aldri ble satt opp mot dem. Brukere meldte om problemer i kassen hos Walmart til tross for avtalen med Meta. I WordPress gir WAF-regler, Bot Fight Mode i Cloudflare, Turnstile eller CAPTCHA i bestillingsskjemaet og forespørselsgrenser i en sikkerhetsutvidelse samme effekt. En slik ordre ser du verken i GA4 eller i WooCommerce, fordi den aldri ble opprettet.

Beslutningen er butikkeierens, men den bør tas bevisst:

1. Gå gjennom WAF-hendelser og serverlogger for /checkout/ og Store API (/wp-json/wc/store/v1/checkout), og tell hvor mange forespørsler som ender med 403 eller en utfordring.
2. Vil du ta imot agentordrer, slipp agentene inn gjennom en integrasjon du velger selv (ACP eller UCP), ikke ved å skru av skjemabeskyttelsen for alle.
3. Vil du ikke, blokker dem uttrykkelig med en regel for bestemte stier eller user-agenter, i stedet for å overlate til tilfeldighetene hvilken bot som slipper gjennom antibot-laget.

Walmarts regler for handleagenter, oppdatert 23. oktober 2026: 21. oktober kunngjorde Walmart tre deler. Agent Profiles, som skal lanseres i løpet av neste måned, gir hver agent kunden godkjenner en egen profil i kundens konto, slik at agentens kjøp vises for seg. Kunden velger om hver ordre må godkjennes, eller om agenten får en utgiftsgrense. Walmart Agent Gateway lar agenter handle via MCP i stedet for å klikke seg gjennom sider laget for mennesker, og starter som beta for bedrifter og utviklere. Vilkårene for AI-agenter sier at kunden godkjenner agentkjøp som standard, at agenter aldri får kortopplysninger eller kan endre betalingsmåter, at Walmarts returordning gjelder også når en agent ikke handler som tiltenkt, og at agenter som bryter vilkårene, blir blokkert. For kunden tetter Agent Profiles det samme hullet som denne artikkelen beskriver for butikken: å skille agent-ordrer fra ordrer lagt av mennesker. Enhver butikk, på WooCommerce, Shopify eller egen plattform, kan bruke ideen allerede nå: registrer agenten som egen ordrekilde, behold en menneskelig godkjenning før betaling, og publiser hva agenter får og ikke får gjøre på nettstedet ditt. Vår tjeneste for klargjøring til AI-handel dekker det oppsettet.

#Når du bør fikse sporing av agent-ordrer i WooCommerce

Foreløpig er agent-ordrer en liten strøm for de fleste butikker, og nettopp derfor er nå rett øyeblikk å fikse det. Butikkene som instrumenterer server-side-innsamling mens volumet er lite, vil ha rene, sammenlignbare tall når det ikke lenger er lite. Butikkene som venter, vil bruke 2027 på å forklare et voksende gap mellom WooCommerce-inntekten og annonsedashbordene, og å bygge attribusjonen om under press er langt dyrere enn å bygge den én gang, i ro, nå.

Hvis du selger via WooCommerce og begynner å se ordrer pikslene dine ikke kan forklare, er det signalet. Det er et rørleggerproblem med en kjent løsning, og det er den typen arbeid som betaler seg første gang en kampanje du var i ferd med å kutte, viser seg å ha vært lønnsom hele tiden.

Vi gjør dette arbeidet som del av våre WooCommerce-utvikling-oppdrag, og det står ved siden av det bredere spørsmålet om butikken din i det hele tatt er oppdagbar og kjøpbar for agenter, som vi dekker i guiden om klarhet for AI-handel og i forklaringen av Universal Commerce Protocol. Vil du forstå hvordan agenter når katalogen din i det hele tatt, viser vår skrivebeskyttede WooCommerce MCP-server mekanikken, og for klientside-fundamentet som fortsatt teller, dekker guiden vår Google Analytics 4 for WordPress nettlesersiden som agent-ordrer omgår.

Sist oppdatert: 20. oktober 2026.