Lär dig hur du optimerar din Adobe Analytics-implementering med affärskrav, variabelkartor och egenskaper

Fliken Affärskrav

VAD:  Ett dokument om affärskrav (kallas ofta BRD) är viktig dokumentation som viktiga intressenter, affärsanvändare och teknikanvändare kommer att vilja samarbeta på. Här kan du dokumentera alla nyckeltal, rapporteringskrav och alla datapunkter du vill se när implementeringen av Adobe Analytics (AA) är klar.

VARFÖR:  Det fungerar som en startpunkt i dokumentationen som följer (SDR, teknisk specifikation osv.) och är en gemensam informationskälla för en överenskommen slutpunkt för AA. I det här dokumentet samlas tankar från olika team i organisationen i en vägledning för att gå vidare och bygga ut eller förbättra implementeringen.

HUR:  Att dokumentera affärskraven görs vanligtvis av affärsanvändarna av AA, men det är viktigt att få feedback från teknikanvändarna eftersom det kan finnas tekniska problem att notera och vissa datapunkter kan kräva mer arbete än andra, vilket bör tas med i prioriteringen.

Fråga dig själv: ”vad det är vi vill spåra på vår webbplats”, ”vilka datapunkter är viktiga för mig när jag rapporterar användning” och viktigast av allt, ”hur ska dessa datapunkter kunna användas för beslutsfattande”. Det är viktigt att se till att alla era affärskrav är kopplade till en datapunkt som kan användas för att fatta affärsbeslut. Det kan till exempel vara frestande att vilja spåra varje klick på webbplatsen, men vilka insikter får du av den rapporten?

Börja med att fylla i kolumn C i skärmbilden nedan (affärskrav). Det ska vara saker som ”Hur många interna sökningar görs på vår webbplats” eller ”Vilken intern kampanjplats är mest effektiv när det gäller visningar”. När du har fyllt i uppgifterna kan du gå tillbaka och fylla i kolumn B (Kategori) och gruppera kraven i kategorier som ”Sökningar” eller ”Interna kampanjer”, som passar ihop med era avsnitt om tekniska specifikationer.

Du kan även ange om du tänker använda en eVar, händelse, egenskap eller en kombination för att spåra det du vill.

Slutligen fungerar kolumnen Implementeringsstatus som en statuskontroll när ni börjar lägga till saker på webbplatsen.

Fliken Variabelmappning (taggningsdokument/SDR)

VAD:  Ett taggningsdokument (kallas ofta SDR) är viktig dokumentation som är värdefull för både teknik- och affärsanvändare av AA. Den visar alla variabler som används i rapportsviter tillsammans med all relevant information om variabelinställningarna, hur variabeln implementeras och vad den rapporterar. Precis som med era egenskapsdokument bör det här vara ett välorganiserat Excel-dokument med en person som ansvarar för att hålla det uppdaterat när taggningsförbättringar eller implementeringsändringar införs.

VARFÖR:  Det här dokumentet har många syften, men de viktigaste är följande:

• För alla som är nya (nyanställda, företagsägare som vill få en bättre förståelse för tillgängliga rapporter osv.) ger det här dokumentet den bästa bilden av alla variabler som implementerats och vad de är avsedda för så att personerna själva kan lära sig mer om er AA-konfiguration.
• För AA-produktägaren/teknikanvändare fungerar dokumentet som en påminnelse om hur andra variabler är inställda och vilka variabler som kan användas när en ny dimension läggs till.

HUR:  Börja med att lista alla färdiga variabler från Adobe (sida, produkt, geo osv.) samt eVars, egenskaper, händelser och listvariabler i ett Excel-dokument. Det bör ha en flik per webbplats/rapportsvit.
För varje dimension lägger jag till följande kolumner:

• Namn:  Skriv ett enkelt och kort namn som de flesta kan förstå. Det bör vara tillräckligt intuitivt så att en ny användare kan förstå vad variabeln är avsedd att mäta.
• Beskrivning:  Mer information om vad variabeln används för och vilka data den spårar. Jag håller beskrivningen kort och ser till att den matchar beskrivningen som används i gränssnittet. Helst vill jag inte att mina användare någonsin ska behöva läsa taggningsdokumentet. När en ny dimension ställs in på administratörssidan lägger jag till samma beskrivning där. På så sätt kan användaren klicka på informationsikonen direkt i Workspace för att förstå vad en dimension är, hen behöver inte öppna ett Excel-dokument!

• Kod:  Koden från serverdelen som ställer in värdet. Det kan vara fältet från datalagret på sidan eller så kan du ange en startregel, en bearbetningsregel osv.
• Klassificeringsrapporter:  Ange alla klassificeringsrapporter som skapats med Klassificeringsimporteraren eller Klassificeringsregelbyggaren
• Lösningens omfattning:  Jag tycker att det är användbart att lista alla egenskaper (åtminstone de som använder mer än standardvariabler) i små kolumner och lägga till en bock för varje dimension som ställts in för den egenskapen. På så sätt kan du enkelt filtrera efter en viss egenskap och snabbt se var en viss dimension ställts in.
• Konfiguration: Användargränssnittsinställningar för administratörer för varje variabel (t.ex. för eVars – utgångsdatum, allokering, försäljning osv.)

Skärmbild av SDR-exempel:

Vi rekommenderar även att du använder det här taggningsdokumentet för att hålla reda på alla fria variabler och ”skräpvariabler”. När en dimension inte längre är användbar tar det ofta ett tag innan den tas bort av utvecklarna. Även efter det kan cacheminneslagring förekomma eller så kanske du inser att dimensionen även ställts in någon annanstans. Det är inte lätt att rensa bland dimensionerna och det krävs ofta tålamod. Här följer några tips om hur du kan dölja skräpet så att användarna inte blir förvirrade.

• Alla dimensioner/händelser som inte används är antingen ”fria” eller ”raderade”

  • Om dimensionen innehåller skräpvärden under de senaste 90 dagarna är den raderad
  • Om dimensionen är fri och ren under åtminstone de senaste 90 dagarna är den fri
  • Markera dessa under ”Namn” i taggningsdokumentet så att du enkelt kan filtrera efter dem. Jag låter dem vara omarkerade i taggningsdokumentet (Excel-datafilter) så att användarna inte ser dem
  • Markera dessa som eVar-namn i gränssnittet så att användare inte hittar dem vid en sökning (d.v.s. ”(v6)”) och ta bort beskrivningen i gränssnittet

• När en ny dimension behövs kan du enkelt filtrera efter ”fria” i kolumnen ”Namn” för att hitta en ren dimension att använda

• För dimensioner och händelser som ska tas bort rekommenderar jag att du håller reda på dem med Workspace:

  • Skapa ett projekt som bara är synligt för administratörer med tre tabeller: eVars, egenskaper och händelser. Jag använder instanser för specifika eVars och för egenskaper skapar jag träffsegment med ”prop5 exists”, till exempel.
  • Ange datum till de senaste 90 dagarna
  • Använd ovanstående som rader i de tre tabellerna tillsammans med förekomster
  • Så fort något når ”0” markerar jag det som ”fritt” i taggningsdokumentet och tar bort det från Workspace-projektet

På det här sättet är era data alltid rena och ni har en tydlig uppfattning om skräpet.

Fliken Egenskaper

VAD:  I ett egenskapsdokument ska du lista alla digitala egenskaper – webbplatser, mobilappar, andra verktyg (chatt, feedback osv.), oavsett om dessa egenskaper är taggade med Adobe Analytics eller inte. Det bör fungera som ett centralt och levande dokument för affärsanvändare och teknikanvändare.

VARFÖR:  Det ger en tydlig bild av användarens resa över alla era digitala egenskaper och vad Adobe Analytics täcker och inte täcker, så att ni kan börja prioritera att lägga till taggning till alla egenskaper där de saknas. Genom att utforma det digitala ekosystemet på det här sättet kan ni identifiera potentiella möjligheter i taggningsstrategin för att få en fullständig bild av användarens resa. Behöver ni till exempel en global rapportssvit för att spåra flera domäner/webbplatser? Krävs det att besökar-ID skickas mellan domäner eller appar för en hybridupplevelse? Behöver interna URL-filter uppdateras för spårning mellan domäner?

HUR:  Identifiera en ägare av dokumentet som tillhandahåller styrning och ansvarar för att hantera uppdateringar.
Lista följande på fliken Egenskaper:

• Egenskapsnamn:  Det kan vara en domän, en underdomän, ett appnamn osv. Även inom samma domän, om vissa delar av den hanteras separat (som av ett annat team eller med annan teknik), bör dessa delar separeras.
• Länk (URL)  till egenskapen om tillämpligt
• Ägare och kontakter:  Ange huvudägaren eller huvudkontakterna för egenskapen
• Taggningsmetod:  Många av oss har olika kodningsmetoder och implementeringar (Launch, JS-filer, AEP, osv.). Du kan dela upp detta ytterligare om det behövs (t.ex. efter kodversion eller tagghanteringssystem), men det är avsett att hålla reda på alla olika kodningsmetoder och -versioner, var koden behöver uppdateras och hur den behöver underhållas. Om ni använder Adobe Launch anger du namnet på Launch-egenskapen.

Kom ihåg att ta med alla digitala egenskaper, även om de inte är taggade med Adobe Analytics. Det hjälper er att förstå det digitala landskapet och hur era användare interagerar med alla era egenskaper.

Vi rekommenderar att ni gör dokumentet så enkelt som möjligt och inte tynger ner det med för mycket information så att det är lätt att tolka i olika delar av organisationen. Analysteam förstår ofta det digitala landskapet bättre än något annat team, så det här dokumentet används ofta av andra team och chefer för att en grundlig översikt.

Titta på den här videon av Doug Moore om du vill veta mer om hur du fyller i spelboken för implementering.