Antalet köp kan se rimligt ut samtidigt som intäkten är hundra gånger för stor. Därför bör köpbeloppens enheter kontrolleras innan en annonsör använder intäkter från ChatGPT-kampanjer för att höja budgeten. Talet, valutan och den affärshändelse beloppet beskriver behöver granskas var för sig.
Den här rutinen gäller beloppsskalan i mätkedjan. Den beräknar inte lönsamhet och avgör inte vilka köp som ska attribueras. Ett korrekt kodat köp kan ligga utanför kampanjens attribueringsregler, och en korrekt tillskriven försäljning kan fortfarande ge förlust efter leveranskostnader.
Följ en bestämd order genom kedjan
Välj en order som ni har rätt att granska och vars total är känd i ordersystemet. Anteckna beloppet som kunden såg, det lagrade beloppet med valuta och det värde som sätts samman i utgående event. Använd en säker orderreferens i utredningen i stället för att sprida kunduppgifter.
Exemplet bör innehålla decimaler när valutan tillåter det. Ett jämnt belopp som 100 kan dölja fel i omvandling eller avrundning. För en hypotetisk order på 249,50 SEK blir det väntade eventbeloppet 24950 i valutans mindre enhet. Valutan behöver följa med heltalet, eftersom talet ensamt inte beskriver ett fullständigt penningvärde.
OpenAI:s dokumentation för konverteringar anger valutans normala mindre enhet för eventbelopp. Anta inte att varje valuta har två decimaler. En valuta utan sådan decimaldel kräver annan behandling än SEK eller USD. Använd valutans definition i implementationen i stället för en generell multiplikation med hundra.
Samma köp, olika talformat
- Order
249,50 SEK i butikens ordervy.
- Köpevent
24950 i valutans mindre enhet, med SEK som valuta.
- Rapport
Kontrollera rapportfältets valuta och skala separat.
Skilj lagringens enhet från överföringens
En handelsdatabas kan redan lagra belopp i mindre enheter. Om integrationen multiplicerar det heltalet igen blir eventet för stort. Ett annat system kan lämna ut decimalbelopp i huvudenheten som faktiskt behöver omvandlas. Läs verkliga värden från den aktiva kodvägen i stället för att dra slutsatser av variabelnamn som pris eller total.
Dokumentera gränsen med källfält, källenhet, omvandling, målfält och målenhet. Lägg till regel för avrundning och var den sker. Flera onödiga decimalomvandlingar kan skapa små avvikelser som blir svåra att förklara när många order summeras i samma rapport.
Om både webbläsare och server skickar köpet ska beloppen jämföras för samma handling. Gemensamma event-ID hanterar dubblettidentiteten men bevisar inte att belopp och valuta överensstämmer. Följ ert kontrakt för event-ID samtidigt som värdenas överensstämmelse granskas separat.
Bestäm vilken ordersumma eventet beskriver
Den integrationsansvariga och ekonomiansvariga bör komma överens om beloppet omfattar moms, frakt, rabatter eller bara varor. Det är ett internt val av ekonomisk definition som behöver följa fältets dokumenterade krav. Byt inte beräkningsgrund utan förklaring för att få annonsavkastningen att se bättre ut.
En hypotetisk kassa innehåller exempelvis varor för 300 SEK, rabatt på 60 SEK och frakt på 49 SEK. Att skicka motsvarande 300, 240 eller 289 i huvudenheter ger tre olika innebörder. Rätt val i er analys beror på den deklarerade definitionen. Valet får däremot inte växla mellan webbläsare och server eller mellan varukategorier utan att skillnaden är avsiktlig och synlig.
Håll orderjusteringar åtskilda från beloppsskala. En återbetalning ändrar affärsutfallet. Att dividera ett felaktigt skalerat tal med hundra rättar ett representationsfel. Guiden om återbetalningar i anskaffningsanalysen behandlar den första frågan utan att beskriva den som ett enkelt kodningsfel.
Läs rapportbelopp enligt rapportens regler
För inte över eventets enhetsregel till alla rapportberäkningar. Rapportfält och kampanjbudgetar har egna enheter. Kontrollera det aktuella rapportschemat och kontovalutan innan ett exporterat värde jämförs med eventets innehåll. Budget i micros är en separat konfigurationsgräns som behandlas i omvandling av budgetenheter.
Om transaktionen och annonskontot använder olika valutor ska originalvalutan finnas kvar i granskningsunderlaget. En rapportsumma i kontovaluta kan inte stämmas av genom att summera råa heltal från flera valutor. Ta först reda på vilket underlag för omräkning som finns innan ni utlovar en exakt matchning mellan order och rapport.
Prova gränsfallen i den verkliga butiken
Granska ett litet urval som täcker butikens faktiska variation: en rabatterad order, ett decimalbelopp, en valuta utan decimaldel om den stöds och en order med frakt. Ta även med ett högt men giltigt belopp för att upptäcka numeriska begränsningar. Det är kontroller av implementationen och inget skäl att skapa konstgjorda kundköp i produktion.
Skriv det förväntade beloppet innan det skickade eventet inspekteras. Annars är det lätt att omedvetet godta vad koden råkar ge. Spara förväntning, observerat värde och förklaring till eventuell skillnad i samma kontrollpost så att en annan granskare kan följa resonemanget.
Vid fel behöver ni avgränsa berörda datum och leveransvägar innan den historiska analysen korrigeras. Märk relevanta intäktstal som osäkra medan omfattningen utreds. En rättad avsändare visar att kommande kodning ändrats, men bevisar inte att tidigare rapporter har räknats om automatiskt. Avsluta med korrekt fältmappning, verifierade exempelbelopp och en tydlig uppgift om vilka äldre budgetbeslut som behöver ses över.
Källor och avgränsning
Verifiera beloppsskala och valuta för köpevent genom ordersystem, eventleverans och rapporter.
Arbetsmetoder och exempel är redaktionella förslag. Kontrollera aktuella plattformsvillkor och funktioner inför genomförandet.