Jag skickade en instruktion till en e-handelskunds utvecklare i förmiddags som består av två kodblock och en varning.
Situationen är den vanliga. De skickar redan ecommerce-data till sitt datalager, men utan något event som vi kan haka fast på i taggverktyget. Utan event vet vi inte när datan dyker upp, och då kan vi inte skicka den vidare. Det är en liten grej. Den är bara liten om man kommer åt koden.
Det gör vi inte. Vi har inte grepp om alla förekomster i deras kodbas, och vi ska inte ha det heller. Alltså blir min uppgift inte att lösa problemet utan att beskriva lösningen så exakt att någon annan kan utföra den utan att fråga mig.
Det jag bad dem söka efter är den här kombinationen:
dataLayer.push({
'ecommerce': {Och ersätta med:
dataLayer.push({
'event': 'ecomPush',
'ecommerce': {Alltså ett event instoppat i de push:ar som redan skickar ecommerce-data. Då bör vi fånga upp alla förekomster utan att någon behöver förstå vad vi ska göra med dem. Namnet på eventet spelar ingen roll så länge det matchar det vi ställer in i taggverktyget, och det gör vi i vår ände.
Undantaget som gör mig osäker
Det finns ett fall där sök-och-ersätt inte räcker, och jag skrev ut det i mailet i stället för att hoppas att det inte fanns.
Om de har push:ar som skickar in något annat innan ecommerce-datan, så ser blocket inte ut som mitt sökmönster, och då missas det. Det korrekta sättet är att leta upp alla förekomster av dataLayer.push({, titta i varje block efter 'ecommerce', och lägga in event-raden om den finns där. Var i blocket raden hamnar spelar ingen roll - bara den ligger i samma push. Ligger den sist får man hoppa över kommatecknet.
Det är mer jobb, och det kräver att den som gör det tänker efter i stället för att köra ersätt-alla. Jag vet inte hur deras kod ser ut, alltså vet jag inte om det är ett problem hos dem eller bara en teoretisk risk. Därför skrev jag det som en varning och inte som ett krav (det är sällan uppskattat att ge en instruktion som antar att mottagarens kod är rörig).
Det jag har lärt mig är att den där reservationen måste stå med. Skickar man en instruktion som ser vattentät ut, så utför mottagaren den som om den vore vattentät, och sedan sitter alla och undrar varför siffrorna ser konstiga ut. Skriver man ut var den kan gå sönder får man ofta ett svar tillbaka som säger “vi har faktiskt sådana”, och då har mailet gjort sitt jobb innan någon rört koden.
Vem som upptäcker om det blev fel
Det här är den delen som jag tycker är obehaglig, och den gäller långt utanför just den här instruktionen.
Om implementationen blir fel så kraschar ingenting. Sajten fungerar. Kassan fungerar. Kunden märker ingenting. Det enda som händer är att det saknas rader i ett gränssnitt som ingen tittar på förrän någon ska göra en rapport, och det kan vara flera veckor senare. Spårning som slutar fungera är tyst på ett sätt som nästan ingenting annat i en e-handel är.
Alltså kan man inte lägga upp det som att kundens utvecklare implementerar och sedan är det klart. Någon måste titta efteråt, och det bör vara vi, för det är vi som vet hur rätt ska se ut. Jag brukar be om att få veta när det ligger ute så att jag kan lägga en beställning och se att eventet dyker upp där det ska, i stället för att lita på att det gjorde det.
Det låter självklart. Jag har ändå varit med om att det inte gjorts, hos oss, mer än en gång - oftast för att implementationen drog ut över en helg och ingen kände att just den var deras att följa upp.
Ordningen jag försöker hålla på är enkel och tar en kvart. Vi får besked om att koden ligger ute. Vi lägger en riktig beställning, eller en testbeställning om de har en sådan miljö. Vi tittar att eventet dyker upp med rätt namn, att ecommerce-datan följer med i samma anrop, och att beloppen stämmer med vad som faktiskt beställdes. Först därefter säger vi att spårningen är på plats, och först därefter börjar vi använda siffrorna till något.
Det låter överdrivet noggrant för en enda rad kod. Men det är just för att det är en enda rad som ingen kommer att dubbelkolla den, och en rad som hamnade i fel block ger inte ett fel utan ett underskott - och underskott i en mätning ser ut som ett dåligt resultat, inte som ett tekniskt problem. Det är det farliga. Man kan fatta helt vettiga beslut på trasig data i månader utan att någonsin misstänka datan.
Den frestande genvägen
Det finns ett svar på det här som jag återkommer till och som jag tycker man ska låta bli: att be om åtkomst till kodbasen själv.
Frestelsen är begriplig. Deras utvecklare har annat för sig, vår ändring är liten, och jag skulle kunna göra den på tio minuter. Men i samma sekund som vi lägger in kod hos kunden så har vi tagit över ett ansvar som vi inte kan bära - vi vet inte hur deras driftsättningar går till, vi finns inte där när något går sönder klockan sex på kvällen, och nästa gång något är konstigt i kassan är vi en av dem som rört koden.
Gränsen är alltså inte krånglig byråkrati. Den är det som gör att jag kan skriva en instruktion utan att behöva ta ansvar för allt annat som bor i samma fil. Priset är att det tar längre tid och att jag måste skriva tydligare mail. Det är ett rimligt pris.
Det är förresten en märklig vecka att skicka den här sortens mail. Halva stan verkar hålla på att ställa in allt de har planerat, och så sitter jag och skriver om kommatecken i ett dataLayer-anrop. Men beställningarna ska ju fortfarande mätas, kanske särskilt nu när ingen vet vad som händer med dem.
Hur gör ni när ni lämnar över spårningskod till någon annans utvecklare? Skickar ni ett mönster att ersätta, eller en beskrivning av vad ni vill åstadkomma och låter dem lösa det själva?