Salgssporing

Sporings af salg er forbindelsen mellem det, Clerk viser besøgende, og de ordrer, de afgiver. Uden dette kan Clerk ikke lære af reelle køb, personalisere anbefalinger eller vise præcis omsætningsattribution i dashboardet.

Denne artikel forklarer, hvordan sporing fungerer på API-niveau, hvordan det opsættes, og hvordan du fejlsøger, hvis ordrer ikke bliver registreret korrekt.

Sådan fungerer det #

Hver sporet ordre i Clerk gennemgår en kæde af tre sammenkoblede elementer.

Visitor ID #

Når en besøgende ankommer til webshoppen, genererer din server et anonymt sessions-ID og inkluderer det i alle API-kald foretaget under denne session. Det er dette, der gør det muligt for Clerk at forbinde en besøgendes browse-aktivitet — de produkter, de så og klikkede på — med den ordre, de til sidst afgiver.

I en Clerk.js-opsætning genereres og administreres visitor ID automatisk. I en direkte API-opsætning er du ansvarlig for at oprette det, gemme det (f.eks. i en sessionsvariabel) og overføre det konsekvent i alle kald.

Labels #

Hvert API-kald, der returnerer resultater — search matches, recommendations, email results — skal inkludere en labels parameter. Dette er et array med mindst én beskrivende streng, som f.eks. ["Homepage - Trending"] eller ["Search - Predictive"], der identificerer hvilket element, der viste disse produkter.

Når en besøgende klikker på et produkt og senere afgiver en ordre, bruger Clerk labelen fra klikket til at spore salget tilbage til det element, der drev det. Dette danner grundlaget for omsætnings-attributionen i analytics.

Labels, der mangler, er identiske på tværs af alle elementer eller er for generiske, gør det umuligt for Clerk at adskille, hvilket element der påvirkede et salg. Dette er en af de mest almindelige årsager til, at attribution ser forkert ud eller mangler helt.

Sale Call #

Når den besøgende afgiver en ordre, bindes en POST-anmodning til log/sale ordren til visitor ID’et. Clerk kan nu forbinde hele kæden: denne besøgende blev vist produkter af element X (labelen), klikkede på et af dem og gennemførte et køb.

For at denne kæde virker, skal hvert klik på et produkt vist af Clerk også blive logget via log/click. I en Clerk.js-opsætning sker dette automatisk. I en API-opsætning skal du selv kalde log/click, hver gang en besøgende klikker på et Clerk-produkt — se API-guide for detaljer.

Denne kæde — label → klik → salg — driver både personaliseringen og omsætningsanalysen i my.clerk.io.

Hvad Clerk gemmer #

Hver sporet ordre indeholder:

• Et unikt salg-ID
• Produkt-ID’er, antal og enhedspriser
• Visitor ID (kobler salget til deres session)
• Kunde-email og kunde-ID — valgfrit, aktiverer personalisering på tværs af sessioner

Opsætning #

Placer kaldet til salgssporing på ordrebekræftelsessiden, som indlæses én gang efter et gennemført køb. Placer det ikke på kurvsiden eller noget andet sted i checkout-flowet.

API #

Lav en POST-anmodning til log/sale fra din server, når en ordre er gennemført. Send det samme visitor ID, der blev brugt igennem hele sessionen.

curl -X POST \
  -H 'Content-Type: application/json' \
  -d '{
    "key": "YOUR_PUBLIC_API_KEY",
    "sale": 567,
    "products": [
      {"id": 12793, "price": 99.95, "quantity": 2},
      {"id": 1546, "price": 14.00, "quantity": 1}
    ],
    "email": "luke@skywalker.com",
    "customer": 1234,
    "visitor": "abc123"
  }' \
  https://api.clerk.io/v2/log/sale

price er altid enhedsprisen på en enkelt vare. Clerk multiplicerer den med quantity internt, når omsætningen beregnes. Send ikke linjetotalen.

Se API-guide for komplette detaljer om generering og persistering af visitor ID på tværs af en session.

Clerk.js #

Clerk.js håndterer visitor ID automatisk og foretager log/sale-kaldet for dig. Tilføj følgende snippet til din ordrebekræftelsesside og udskift pladsholderne med platformens variabler:

<span
  class="clerk"
  data-api="log/sale"
  data-sale="ORDER_ID"
  data-email="CUSTOMER_EMAIL"
  data-customer="CUSTOMER_ID"
  data-products='[{"id": 12, "quantity": 1, "price": 99.95}, {"id": 54, "quantity": 2, "price": 9.50}]'>
</span>

Clerk.js opfanger snippen ved indlæsning af siden og sender salgsdata til API’et med det samme visitor ID, som er blevet sporet igennem sessionen.

Verificering af opsætning #

Tjek disse tre steder efter at have gennemført en testordre.

Developers > Logs — Eventuelle fejl fra sporingskaldet vises her i realtid. Dette er det hurtigste sted at få øje på et forkert konfigurert request.

Data > Orders — Bekræftede sporede ordrer vises her. Klik på en ordre for at se, hvilke produkter der blev sporet, og om Clerk kan identificere dem. Viser et produkt et pladsholderbillede, matchede produkt-ID’et i salgsopkaldet ikke noget produkt i dit katalog.

Data > Visitors — Søg efter et visitor ID for at undersøge deres fulde session: hvilke produkter de så, hvilke Clerk-elementer de klikkede på, og hvilke ordrer de afgav. I en Clerk.js-opsætning kan du tvinge et bestemt visitor ID under test ved at tilføje ?clerk_visitor=VISITOR_ID til enhver side-URL — Clerk.js vil bruge det ID til sessionen, hvilket gør det nemt at følge et komplet testflow fra ende til anden.

Health dashboard viser en statusindikator på øverste niveau for sporingen af salg. En rød status betyder, at der ikke er modtaget sporede ordrer for nylig.

Fejlfinding #

Følg disse trin, hvis salg ikke bliver sporet korrekt.

Tjek Logs #

Gå til Developers > Logs og se efter fejl fra log/sale-endpointet. Dette gælder både for API- og Clerk.js-opsætninger — ethvert afvist request vises straks her med en fejlbesked, der forklarer, hvad der var galt.

For Clerk.js-opsætninger, kør også Clerk("debug") i browserens konsol, før du gennemfører en testordre. Dette aktiverer debug-mode, hvilket får Clerk.js til at logge detaljerede oplysninger om hvert sporingskald — inklusive det visitor ID, der bruges, de labels der knyttes til resultatkald, og eventuelle fejl. Kig efter poster, der starter med [Clerk] i konsoloutputtet.

Bekræft API-respons #

log/sale-endpointet returnerer altid et svar. Et vellykket svar ser sådan ud:

{"status": "ok"}

Et fejlslagent svar returnerer en fejl med en beskrivelse af, hvad der gik galt, eksempelvis:

{"status": "error", "error": "Missing required argument: sale"}

Læs fejlbeskeden — den peger som regel direkte på problemet.

API-opsætning: Log det rå HTTP-svar fra log/sale-kaldet i din backend. Hvis du ikke allerede gør dette, kan du teste kaldet direkte med en kendt-gyldig payload:

curl -X POST \
  -H 'Content-Type: application/json' \
  -d '{
    "key": "YOUR_PUBLIC_API_KEY",
    "sale": 999,
    "products": [{"id": 12793, "price": 99.95, "quantity": 1}],
    "visitor": "test-visitor-1"
  }' \
  https://api.clerk.io/v2/log/sale

Hvis dette lykkes, men produktionskald ikke gør, så sammenlign de to payloads nøje — forskellen vil afsløre problemet.

Clerk.js-opsætning: Åbn browserens DevTools, gå til fanen “Network”, og filtrer efter clerk. Gennemfør en testordre og led efter et request, der starter med sale?key=.... Klik på det og undersøg svaret.

Tjek Request-parametre #

Hvis ordrer ikke spores eller ikke bliver tilskrevet korrekt, så bekræft følgende over din opsætning:

API key — Bekræft at key matcher Public API Key fundet i Developers > API Keys. En forkert nøgle returnerer straks en godkendelsesfejl.

Visitor ID — Tjek at visitor er til stede og at det er den samme værdi, der blev brugt i resultatkald tidligere i sessionen. Hvis du genererer et nyt ID ved hvert request, eller gemmer det et sted, der bliver tømt før checkout, vil ID’et i salgskaldet ikke matche det, der blev knyttet til klikkene.

Labels — Bekræft at hvert kald, der returnerer resultater tidligere i sessionen, inkluderede et labels array med unikke labels for hvert element. Hvis labels mangler eller er identiske på tværs af elementerne, registrerer Clerk salget, men kan ikke tilskrive det noget specifikt element.

Produkt-ID’er — Bekræft at ID’erne i products array matcher dem, Clerk har i kataloget. Søg efter en af ID’erne i Data > Products for at bekræfte. Hvis du ikke kan finde det, sender du sandsynligvis variant-ID’er eller SKUs i stedet for parent produkt-ID’er.

Sale ID — Bekræft at sale-værdien er unik pr. ordre og ikke bruges igen i flere requests. Clerk ignorerer stille og roligt dublerede sale IDs.

Intet kald udført #

API-opsætning: Kaldet bliver ikke sendt fra din server. Tjek din handler for ordregennemførelse — bekræft at den virkelig nås efter et køb, og at ingen undtagelse undertrykker sporingskaldet. Tilføj midlertidig logning omkring log/sale-kaldet for at sikre, det udføres.

Clerk.js-opsætning: Clerk.js-biblioteket kører ikke på bekræftelsessiden. Åbn browserens konsol og skriv Clerk. Hvis du ser følgende fejl, blev biblioteket ikke indlæst:

Uncaught ReferenceError: Clerk is not defined

Bekræft at Clerk.js-sporingsscriptet er til stede i skabelonen for bekræftelsessiden og ikke bliver blokeret af et andet script eller et cookie consent-værktøj.

Ingen Clerk-indflydelse #

Hvis salgsopkaldet lykkes, men ingen ordrer vises som Clerk-påvirkede i analytics, har Clerk registreret ordren, men kunne ikke forbinde den til en session eller attributere den til et element.

log/click bliver ikke kaldt — Den hyppigste årsag. Clerk kan ikke attribuere et salg til et element, medmindre et klik blev logget før købet. I en Clerk.js-opsætning spores klik automatisk — bekræft at biblioteket er indlæst på siderne, hvor Clerk-resultater vises. I en API-opsætning, tjek at din kode kalder log/click, hver gang en besøgende klikker på et product vist af Clerk, og at kaldet faktisk når API’et (tjek dine server-logs eller svaret).

Manglende eller ugyldige labels — Tjek at hvert resultatkald og hvert log/click-kald inkluderer et gyldigt labels array. Hvis labels mangler, er tomme eller kun indeholder whitespace, kan Clerk ikke afgøre, hvilket element den besøgende interagerede med, og salget bliver ikke attribueret.

API-opsætning: Bekræft at visitor ID i log/sale-kaldet nøjagtigt matcher det, der blev sendt i log/click-kaldet, da den besøgende klikkede på produktet. Selv en lille forskel — et andet format, et ekstra tegn eller et genskabt ID — bryder forbindelsen.

Clerk.js-opsætning: Visitor ID’er håndteres automatisk, men forbindelsen kan brydes, hvis sporingsscriptet ikke er med på en eller flere sider i checkoutflowet. Tjek at Clerk.js er indlæst på hver side mellem produktsiden og bekræftelsessiden.

Almindelige fejl #

Her er de mest hyppige årsager til, at salgssporing fejler eller attribution ikke fungerer korrekt.

Ugyldig produktsyntaks #

Produkt-ID’er skal sendes som samme type, der anvendes i dit datafeed. Hvis du bruger heltal der, skal de også være heltal i salgskaldet — ikke strenge. At sende "id": "123" når Clerk forventer "id": 123 får kaldet til at fejle.

products-værdien skal også være gyldig JSON. Escape-de eller dobbelt-encodede strenge som "products": "[{\"id\":\"123\"}]" bliver ikke parset korrekt.

Manglende argumenter #

Argumenterne key, sale og products er alle krævede. Hvis en af dem udelades, returneres en fejl. products array’et skal indeholde mindst ét element.

Clerk.js ikke indlæst #

Hvis Clerk.js-biblioteket mangler på bekræftelsessiden eller er blokeret for at køre, foretages intet salgsopkald. To hyppige årsager:

• Sporingsscriptet er ikke inkluderet i bekræftelsessidens skabelon.
• Et cookie consent-værktøj (såsom iubenda i automatisk blokeringstilstand) blokerer cdn.clerk.io eller api.clerk.io. Tilføj begge domæner til allowlisten, så sporingen ikke forsvinder uden varsel, hvis besøgende afviser ikke-essentielle cookies.

Forkerte produkt-ID’er #

Spor parent produkt-ID, ikke variant-ID’et. Hvis en besøgende køber en rød, størrelse M t-shirt, så spor parent-ID’et — ikke ID’et på den specifikke variant. Samme ID skal bruges både i kliksporing og i salgskaldet. Mismatchede ID’er ødelægger attribution selv hvis begge kald lykkes.

Visitor ID skifter #

I en API-opsætning skal visitor ID være det samme fra første sidevisning og frem til salgskaldet. Hvis du genskaber ID’et ved hver sideload, er klik og salg forbundet til forskellige sessioner, og Clerk kan ikke forbinde dem.

I en Clerk.js-opsætning håndteres dette automatisk, men det kan brydes, hvis sporingsscriptet mangler på en eller flere sider i checkoutflowet.

Unit price mismatch #

price i products array skal være enhedsprisen for én vare. Clerk multiplicerer den med quantity for at beregne omsætning. Hvis du sender en forud-ganget linjetotal, får du oppustede omsætningstal i analytics.

Genbrugte sale IDs #

Clerk gemmer kun det første kald for et givet sale ID. Hvis ordrebekræftelsessiden kan opdateres eller besøges igen, bliver sporingskaldet fyret igen med samme sale ID. Det næste kald ignoreres stille og roligt.

Brug et server-side flag eller et sessionmærke for at sikre, at sporingskaldet kun bliver fyret én gang per ordre.

Manglende besøgsdata #

Hvis hverken visitor eller email er inkluderet i salgskaldet, registrerer Clerk ordren, men kan ikke knytte den til en session eller kundeprofil. Ordren vises i Data > Orders, men vises aldrig som Clerk-påvirket i analytics.

Indsæt altid parameteren visitor. Tilføj også email og customer, når det er muligt, så personaliseringen forbedres på tværs af fremtidige sessioner for kunden.

Deaktivering af besøgs-sporing #

For at stoppe sporing for en specifik besøgende — f.eks. hvis de har afvist al sporing via en cookie consent-banner — send "visitor": null i alle API-kald for denne session. Clerk behandler anmodningerne normalt, men logger ingen aktivitet til en besøgsprofil.

I en Clerk.js-opsætning sættes det i konfigurationen i stedet:

Clerk('config', {
  key: 'YOUR_API_KEY',
  visitor: null
});

Salg bliver stadig logget, selvom besøgs-sporing er deaktiveret. Clerk modtager ordredataene og tager dem med i analytics, men uden nogen sessionkontekst — ingen klik-historik, ingen browsede produkter, ingen element-attribution. Clerk ved kun, hvad der blev købt, men ikke, hvordan den besøgende nåede dertil.