När en annonsör jämför en kampanjexport från ChatGPT med webbplatsens order kan ett köp strax efter midnatt hamna på olika kalenderdagar. Inget av systemen behöver ha räknat fel. Samma tidpunkt kan tillhöra olika rapportdagar eftersom systemen använder olika tidszoner. Att flytta budget på grund av den skenbara luckan vore då att fatta beslut med oförenliga klockor.
Börja därför med att dokumentera tidszonen innan siffrorna jämförs. OpenAI:s rapporteringsexempel anger kontots tidszon uttryckligen. Använd inställningen för ert annonskonto, inte platsen i dokumentationens exempel eller klockan på analytikerns dator. Arbetsgången här gäller rapportunderlaget och förutsätter inte att AthillyAds erbjuder en väljare för tidszon.
Skriv en enkel överenskommelse om tiden
Anteckna begärd datumperiod, rapportens tidszon, hämtningstid och datumkolumnens betydelse. Den sista punkten är lika viktig som själva zonen. Datumet kan avse när annonsinteraktionen inträffade eller när kunden köpte. Att ändra tidszon kan inte förena två rapporter som från början beskriver olika slags händelser.
En begriplig rapportinledning kan ange kampanjleverans för 1 till 7 september enligt annonskontots inställda tidszon, tillsammans med den dokumenterade hämtningstiden i UTC. Lägg till kontots faktiska zonidentifierare. Undvik korta förkortningar som kan betyda olika saker i olika delar av världen.
Behåll ursprungliga tidsstämplar i maskinläsbart format. Gör om dem till lokala datum först när rapportens princip är bestämd. Om en import till kalkylblad tar bort tidsdelen eller offseten bör originaldata återställas innan daglig avstämning görs. När bara ett kalenderdatum återstår kan informationen som behövs för korrekt placering redan vara borta.
Följ en order över midnatt
Anta ett hypotetiskt köp vid 2026-09-07T22:20:00Z. Tidpunkten är 00.20 den 8 september i Europe/Stockholm och 18.20 den 7 september i America/New_York. En butik med Stockholmsdatum räknar ordern till den 8 september, medan en rapport med New York-datum placerar den på den 7 september. Summan för dessa två datum kan ändå vara identisk. Exemplet visar enbart tidsomvandling och säger inget om vilka länder annonsören kan köpa annonser i.
Följ ursprunglig tidsstämpel, källans tidszon, omvandlingsregel och slutligt rapportdatum. Flytta inte ordern manuellt för att diagrammet ska se rimligare ut. Använd en dokumenterad regel på hela datamängden och stäm sedan av summorna igen. Manuella undantag gör analysen svår att upprepa för nästa person.
Ett dagligt budgetbeslut bör bygga på en avslutad dag enligt vald princip. Om rapporterna stänger vid olika tidpunkter kan den senaste dagen fortfarande vara ojämförbar. Ofullständiga rapportperioder behöver därför kontrolleras separat även när tidszonerna har anpassats.
Från tidpunkt till rapportdag
- Bevara originalet
Spara tidsstämpel med offset innan importen tar bort tidsdelen.
- Välj kontots zon
Använd samma zonregel för hela urvalet, även nära klockomställning.
- Stäm av två dagar
En order nära midnatt kan flytta dag utan att totalsumman ändras.
Hantera klockomställningar i databehandlingen
Vissa tidszoner ändrar sin relation till UTC under året. En lokal kalenderdag vid en klockomställning behöver därför inte motsvara exakt tjugofyra förflutna timmar. Lagra en erkänd tidszonsidentifierare och använd datumhantering som förstår den i stället för att lägga på samma fasta antal timmar på varje observation.
Detta är en rekommendation för databehandling och inte ett påstående om ett visst gränssnitt för ChatGPT. Implementationen behöver kontrolleras mot det programmeringsspråk och bibliotek som faktiskt används. Prova ett datum nära klockomställning, ett vanligt datum och en tidpunkt nära midnatt. Testet ska visa vilket kalenderdatum varje värde får, inte bara att körningen saknar felmeddelanden.
Undvik att räkna om lokal midnatt genom att alltid dra bort samma antal timmar. Genvägen kan förskjuta periodens början eller slut när offseten är en annan. Ett fel på en dag kan få stor betydelse om den dagen innehåller en kampanjstart eller en ovanligt stor beställning.
Skilj klockproblem från attribuering
Efter tidsjusteringen kan kampanjkonverteringar fortfarande skilja sig från butikens köp. Annonsrapporten beskriver attribuerade utfall, medan ordersystemet registrerar transaktioner. Alla köp behöver inte vara kvalificerade för annonskreditering, och rapporterna kan använda olika tidsbas. Samma tidszon tar bort en möjlig felkälla men gör inte datamängderna identiska.
Använd en avstämning med skilda kategorier för tidsskillnader, skillnader i urval och ännu oförklarade skillnader. Kalla inte varje order som saknar motsvarighet för ett spårningsfel. Läs vidare om annonstid och konverteringstid när datumen representerar olika händelser.
Bestäm en standard för kampanjbeslut
Välj en tidsprincip för veckans beslut om annonseringen i ChatGPT och skriv in den i rapportmallen. Behåll en annan vy endast när verksamheten behöver den, exempelvis för lokal bemanning eller redovisning. Märk vyerna så att kunden inte jämför ett teams tisdag med ett annat teams måndagskväll.
Kontrollera rapporthuvud, hela dagar och hämtningstid före en budgetomfördelning. Fundera på om slutsatsen skulle ändras när en enskild order nära dygnsgränsen flyttas till rätt dag. Om svaret är ja behöver underlaget granskas före åtgärden. Sparade rapportversioner bevarar den vy som låg bakom beslutet. Plattformens rapporteringssammanhang finns i OpenAI:s dokumentation.
Källor och avgränsning
Samordna dygnsgränser mellan kampanjdata och order utan att blanda ihop tidszon med attribuering.
Arbetsmetoder och exempel är redaktionella förslag. Kontrollera aktuella plattformsvillkor och funktioner inför genomförandet.