Datalager

Ett datalager är ett strukturerat objekt som underhålls av en webbplats eller applikation och som innehåller information om den aktuella sidan, användaren och händelserna som inträffar, i ett dokumenterat format som mätverktyg läser. Istället för att varje analys- eller annonstagg extraherar värden från sidans uppmärkning, läser alla konsumenter från en enda, avsiktligt ifylld källa.

Dess värde ligger i hållbarhet. Spårningskonfigurationer som skrapar värden från CSS-väljare, klassnamn eller synlig text är kopplade till presentationsdetaljer som ändras när webbplatsen designas om, omstylas eller omstruktureras, och när de går sönder misslyckas de vanligtvis tyst. Ett datalager frikopplar mätning från presentation: gränssnittet kan ändras helt, och så länge datalageravtalet hålls, fortsätter spårningen att fungera. Detta förvandlar spårning från ett ömtåligt överlägg till ett underhållet gränssnitt.

Den avtalsmässiga karaktären är den viktiga delen. En datalagerspecifikation definierar vilka variabler som finns, vad de innehåller, vilka typer de innehåller, när de fylls i och vilka händelser som skickas med vilka parametrar. Behandlas som ett gränssnitt mellan applikationen och mätstacken blir det ett delat ansvar: utvecklare implementerar det som en del av att bygga funktioner, och analyser konsumerar det utan att behöva förstå användargränssnittet. Behandlas det som en eftertanke blir det inkonsekvent, med samma koncept namngivet på tre sätt i olika mallar och fyllt i vid olika punkter i sidans livscykel.

Timing är det vanligaste tekniska felet. Värden som skickas efter att taggar redan har aktiverats producerar tomma eller standarddata, vilket är anledningen till att datalagret bör initieras i dokumentet före tagghanteringskodavsnittet, med efterföljande händelser som skickas allt eftersom de inträffar. Ensidiga applikationer kräver särskild försiktighet, eftersom virtuella sidändringar inte utlöser normala sidinläsningshändelser, och historikbaserad navigering måste explicit skicka motsvarande händelser med rätt kontext.

Schemats design avgör hur användbar den resulterande datan är. Ett väl utformat datalager fångar de entiteter som företaget faktiskt resonerar kring, inklusive produktidentifierare, kategorier, priser, valuta, användartyp, kontostatus och de identifierare som kopplar en session till den bredare kundposten. Ett dåligt utformat datalager fångar det som var bekvämt för tillfället, vilket producerar analyser som inte kan besvara de frågor som företaget ställer utan ytterligare ingenjörsarbete varje gång.

Dokumentation är det som gör att ett datalager överlever personalomsättning, och det är det element som oftast saknas. En specifikation som listar varje variabel och händelse, med dess typ, dess utlösningsvillkor, ett exempelvärde och den person eller det team som är ansvarig, är en liten artefakt med oproportionerligt värde: den gör det möjligt för nya utvecklare att implementera spårning korrekt utan att behöva bakåtkompilera befintliga sidor, den ger analytiker en referens när de tolkar data och den ger grund för automatiserad validering. Att testa att implementeringen matchar specifikationen, helst som en del av distributionspipelinen, är det som förhindrar den gradvisa avvikelsen där dokumentationen beskriver ett gränssnitt som webbplatsen inte längre hanterar.

Integritetsöverväganden gäller direkt, eftersom datalagret ofta är där personuppgifter först blir tillgängliga för tredjepartstaggar. Personliga identifierare bör inte placeras i det utan en tydlig rättslig grund och en mekanism som respekterar samtyckesstatus, och hashade eller pseudonyma identifierare bör användas där en koppling krävs. I praktiken definieras schemat av uppgifter analytics i samarbete med de team som ska implementera det, och upprätthålla det som en del av definitionen av gjort i produktutveckling är det som förhindrar att mätningen tyst försämras vid varje utgåva.