Tänk dig ett kalkylblad med två rader som har namnet “Höstens kundanskaffning”. Den ena är en omdöpt kampanj i ChatGPT och den andra är en separat kampanj för ett annat test. En uppslagning på namn ger båda samma ansvarig och blandar samman resultaten. Rapporten ser prydlig ut men kampanjhistoriken är fel.
Problemet ligger i hur data kopplas ihop. En annonsör som exporterar kampanjresultat från ChatGPT behöver en identitet som överlever namnbyten och skiljer liknande etiketter åt. OpenAI:s rapporteringsexempel innehåller kampanj-ID tillsammans med kampanjnamn. Behåll båda: identifieraren pekar ut posten och namnet hjälper människan att känna igen den. OpenAI:s kampanjdokumentation rekommenderar identifierare som bestående referenser eftersom namnuppslagning kan ge flera träffar.
Tabellen som behövs före diagrammet
Skapa ett kampanjregister med en rad per kampanjidentitet. Ta med konto-ID, kampanj-ID, aktuellt namn, intern ansvarig och datum för senaste kontroll. Om flera kundkonton ingår i samma rapportfil kan konto-ID tillsammans med kampanj-ID användas som kopplingsnyckel. Det är en försiktig intern princip som inte kräver antaganden om identifierarnas unikhet mellan konton.
Förvara resultatraderna i en separat tabell. En daglig observation behöver kampanjnyckel, rapportdatum och de dimensioner som gör raden unik. Rader som delas upp per land kan exempelvis inte behandlas som om kampanj och datum vore hela nyckeln. Då riskerar en koppling eller dublettrensning att slå ihop observationer som ska vara skilda.
Skriv med vanliga ord vad en rad betyder ovanför varje tabell. En kampanj under en rapportdag är en nivå. En kampanj, ett land och en rapportdag är en annan. Den meningen ska vara klar innan någon bygger en uppslagsformel eller skriver en databasfråga.
Ett namnbyte ska ändra etiketten
Anta en påhittad kampanj med identifieraren cmp-example-17. På måndagen heter den “Septembertest leads” och på onsdagen “Test kvalificerade leads”. Båda dagarnas leverans tillhör samma kampanj. En koppling via dagens namn kan lämna måndagens data utan träff eller felaktigt skapa två skilda kampanjhistoriker.
Ett enkelt register kan behålla det nuvarande namnet och den stabila identifieraren. Behöver ni visa namnet som gällde vid ett tidigare beslut kan en separat namnhistorik med giltighetsdatum användas. Lägg inte bara till gamla namn som extra rader i huvudregistret om kopplingen inte uttryckligen hanterar sådan historik.
Det farliga fallet är en koppling där en resultatrad matchar flera registerrader och kostnaden därmed multipliceras. Om tre gamla namn matchar samma kampanj-ID kan varje resultatpost dyka upp tre gånger. Summan kan ändå se trovärdig ut i ett hårt sammanfattat diagram. Kontrollera därför radantal och kostnad före och efter kopplingen.
Tre kontroller visar om modellen håller
Kontrollera först att nyckeln är unik i registret. Två aktiva rader ska inte dela samma identitet om modellen inte uttryckligen innehåller ännu en dimension. Lös modellproblemet när dubletter hittas i stället för att välja den första rad som kalkylbladet råkar lämna tillbaka.
Räkna sedan resultatrader utan registerträff. En kampanj som saknas i registret ska hamna i en lista för åtgärd och inte försvinna ur kostnadssumman. En ny kampanj i ChatGPT behöver kanske bara läggas till. Om den tappas bort i rapporten underskattas förbrukningen samtidigt som bristen i arbetsrutinen blir osynlig.
Stäm slutligen av summorna före och efter att beskrivande information lagts till. Om total kostnad eller klickantal ändras när ansvariga och läsbara namn kopplas på har rader sannolikt försvunnit eller dubblerats. Berikningen ska ge mer sammanhang utan att förändra måtten. Avsiktliga urvalsfilter behöver vara ett eget dokumenterat steg.
Ett namnbyte, samma kampanj
- ID och konto
Koppla resultat med verifierad identitet, inte liknande namn.
- Beskrivande register
En aktiv registerrad per nyckel hindrar att historiska namn multiplicerar kostnaden.
- Kontrollsumma
Kostnad och klick ska vara oförändrade efter att ansvarig lagts till.
Byrårapporter kräver tydligt kundurval
Kundseparering hör hemma i datamodellen och inte bara i mappnamnet. Att filen heter kund A:s veckorapport visar inte att varje rad tillhör kund A. Välj underlag med verifierad kontoidentifierare och granska vilka unika konton som faktiskt finns med innan en kundversion skapas.
Undvik att kopiera föregående kunds register och bara ändra de synliga namnen. Gamla kampanj-ID:n, ansvariga eller länkar kan finnas kvar bakom presentationen. Bygg rapporten från ett uttryckligt kontourval och kontrollera sedan resultatets omfattning. Detta är en intern kontrollmetod och inget påstående om åtkomstfunktioner i AthillyAds.
Affärsetiketter som tjänsteområde och kampanjens syfte bör ha en ansvarig person i registret. Plattformens kampanjnamn kan ändras av praktiska skäl. Er interna klassificering ska däremot ändras när den underliggande affärsbetydelsen förändras, inte för att någon putsar ett namn inför ett möte.
Lämna vidare något som går att förstå
Ge nästa analytiker registret, beskrivningen av radnivån, identitetsfälten och kontrollpunkterna. Lägg gärna till ett exempel på en omdöpt kampanj och en rad utan träff. Det förklarar modellen bättre än en skärmbild av den färdiga rapporten.
Behåll identifierare i exporten även om kundversionen döljer dem. De gör senare avstämning möjlig. Fortsätt med datans ursprung i kampanjrapporter eller kundseparering i byrårapporter. Kampanjidentifierare i rapporteringen beskrivs i OpenAI:s dokumentation. Registermodellen ovan är ett eget arbetssätt och utlovar ingen inbyggd registerfunktion i AthillyAds.
Källor och avgränsning
Bevara kampanjidentitet vid namnbyten och undvika dubblerade mått när exporter berikas.
Arbetsmetoder och exempel är redaktionella förslag. Kontrollera aktuella plattformsvillkor och funktioner inför genomförandet.