Ett lyckat svar betyder inte alltid att rapporten över annonseringen i ChatGPT är komplett. När resultaten delas upp på flera sidor kan första sidan innehålla korrekta värden men sakna en stor del av kampanjhistoriken. En rapport som bygger på bara den sidan kan laddas utan fel och ändå visa för låg kostnad.
OpenAI:s allmänna Insights-rapportering är sidindelad. Exakta regler för anrop och svar hör hemma i den aktuella API-referensen och behöver följas av integrationsansvarig. Här granskar vi fullständigheten runt hämtningen. Guiden hittar inte på ett format för fortsättningsvärden och förutsätter inte att AthillyAds visar kontroller för API-sidindelning.
Bestäm vad komplett betyder före exporten
Skriv ett hämtningsunderlag med konto, datum, tidszon, rapportnivå, begärda fält och filter. Lägg till körningsidentifierare och starttid. Alla sidor i körningen ska höra till samma definition, bortsett från parametern som används för att fortsätta hämtningen.
Ändra inte datumintervallet efter första sidan för att resultatet verkar för stort. Då får ni en samling giltiga svar som inte längre representerar en sammanhängande rapport. Behöver urvalet ändras ska en ny körning startas. Bevara den första som ofullständig i stället för att blanda dess rader med det nya urvalet.
En komplett körning ska ha följt den dokumenterade fortsättningsmekanismen till dess dokumenterade slutvillkor. Att anropet lyckades, att en fil skapades eller att sista sidan innehöll färre rader än väntat räcker inte som generell definition. Sådana genvägar bygger på antaganden som kan vara fel.
För en logg över sidorna
En enkel logg innehåller körningens ID, sidans ordningsnummer, anropstid, svarsstatus och accepterat radantal. Spara tillräcklig information om fortsättningen för att kunna undersöka en loop eller omstart utan att exponera behörighetsuppgifter. Behåll originalsvaret eller en kontrollerad kopia när er datalagringspolicy tillåter det.
I ett hypotetiskt exempel ger tre sidor 100, 100 respektive 37 rader. En avslutad körning accepterar 237 rader efter det specificerade slutvillkoret. Om andra sidan misslyckas är de första hundra raderna ett ofullständigt underlag, inte en mindre men komplett rapport. Märk körningen som partiell och använd den inte som färdigt resultat i kampanjjämförelsen.
En tom sida behöver också tolkas enligt dokumentationens regler. Utgå inte från att tomhet alltid betyder att hämtningen är färdig. Fortsätt inte heller anropa samma fortsättningstillstånd obegränsat. Ett upprepat tillstånd bör utlösa ett kontrollerat stopp med felsökningsinformation så att integrationen inte fastnar tyst.
När är hämtningen klar?
- Sida ett: 100 rader
Ett lyckat svar är fortfarande bara en del av körningen.
- Fortsätt samma urval
Nästa 100 och sista 37 måste accepteras utan dubletter.
- Slutvillkor verifierat
237 rader blir komplett först när dokumenterad fortsättning är avslutad.
Bestäm hur omförsök tas emot
Ett nätverksfel kan uppstå efter att ett svar kommit fram men innan programmet sparat att steget är klart. Ett omförsök kan då lämna rader som redan finns i lagringen. Inläsningen behöver kunna känna igen vilka rapportposter som redan accepterats i den aktuella körningen.
Definiera radens identitet utifrån rapportnivån, exempelvis kampanj, datum och begärd uppdelning. Rensa inte dubletter på bara kampanj-ID när rapporten innehåller flera datum. Det skulle ta bort riktig historik samtidigt som det ser ut att lösa ett dubbleringsproblem.
Bestäm om ett omförsök ersätter den föregående sidkopian eller sammanför poster med en verifierad unik nyckel. Båda modellerna kräver kontroll av att summorna består. Enbart antal inlästa rader räcker inte, eftersom dubblerade och saknade rader kan råka ta ut varandra i antalet utan att innehållet blir rätt.
Stäm av den sammansatta rapporten
Efter hämtningen granskas unika kampanj-ID:n, första och sista datum samt det förväntade urvalet. Leta efter dubbla radidentiteter och oväntade luckor. Jämför summan med ett förenligt aggregerat underlag när det finns, men ta hänsyn till att färska data kan ha ändrats mellan hämtningarna.
En avvikelse i en stabil historisk period bör undersökas före publicering. För en ny period sparas båda hämtningstiderna och jämförelsen upprepas enligt en bestämd rutin. Guiden om kostnadsuppgifternas aktualitet förklarar varför två ögonblicksbilder kan skilja sig utan ett fel i sidindelningen.
Gör fullständigheten synlig i själva underlaget. En körningsstatus som anger komplett, misslyckad eller partiell är mer tillförlitlig än en muntlig överlämning. Rapportvyn ska använda den status som passar ändamålet. En incidentvy kan visa preliminära rader med märkning, medan en kundrapport behöver ett tydligt definierat färdigt urval.
Överför inte samma regel till alla rapportanrop
Olika rapportfunktioner kan hantera storleksgränser på olika sätt. En särskild konverteringsrapport måste granskas mot sin egen dokumentation och inte pressas in i samma sidindelningsmodell som allmän Insights. Om ett anrop avvisar för stort underlag kan problemet kräva uppdelning i mindre urval.
Den separata situationen behandlas i uppdelning av stora konverteringsrapporter. Skillnaden hindrar att en utvecklare bygger en omförsöksloop kring ett anrop som egentligen behöver ändrad omfattning.
Inför leverans ska granskaren kunna förklara vad som begärdes, hur slutvillkoret verifierades och hur saknade eller dubbla rader kontrollerades. Bevara svaret genom dokumentation av datans ursprung. Plattformskällan är OpenAI:s rapporteringsdokumentation. Ett trovärdigt kampanjresultat börjar med fullständigt underlag.
Källor och avgränsning
Verifiera att alla sidor ingår i en komplett hämtning och att omförsök bevarar rapportens summor.
Arbetsmetoder och exempel är redaktionella förslag. Kontrollera aktuella plattformsvillkor och funktioner inför genomförandet.