Test&Target global Mbox strategi

Et af de emner der skaber mest forvirring for mine kunder ved opstart af Test&Target projekter, er hvilken strategi der skal benyttes i forhold til implementeringen af mboxe? Hvilken cost (antal server calls) er der forbundet med hver enkel strategi? Og ikke mindst, hvilken strategi kræver mest af IT gutterne i firmaet?
Forhåbentlig, så vil du efter at have læst dette indlæg være bedre rustet til at tage den rette beslutning. Der er 2 overordnet strategier til implementeringen, der hver især kan tweakes på hver deres måde. For ikke at gøre det mere kompliceret end nødvendigt, så vil jeg fokusere på de to grundlæggende implementeringer. Så lad os springe ud i det og starte med standard implementeringen.

Standard Implementering
En standard implementering kræver individuelle mboxe (hver med et unikt mbox navn) der bliver implementeret omkring de specifikke elementer på siden som man ønsker at optimere. Kodemæssigt ser det således ud:

Standard implementeringen gør det ekstremt nemt at udskifte indholdet, da det blot vil kræve et html offer med det nye billede man ønsker at teste:

Ved at benytte denne implementering kræver det at du ved på forhånd hvad du vil teste/optimere, så du kan sende en request til IT om at få implementeret de nødvendige mboxe. Det betyder også at har man flere elementer på samme side som man ønsker at optimere, så kræver det altså en mbox for hvert element. Det kunne f.eks. være ved en MVT hvor man benytter en 3×2 array, hvor det dermed kræver du har 3 mboxe implementeret på samme side.

Fordele

  • Der kræves ikke nogen større teknisk forståelse for at oprette offers
  • Opsætningen af kampagnen er mere simpel
  • Begrænset antal mbox requests (server calls) – du opretter kun de mboxe du har behov for

Ulemper

  • Det er nødvendigt at inddrage IT for at oprette nye mboxe
  • IT er ligeledes nødvendige for at fjerne dem igen (det er dog også muligt at disable dem via Test&Target interfacet)

Der er ingen tvivl om at IT kommer til at være den helt store skurk i standard implementeringen. Hvis din organisation er som de fleste andre, så fungerer det ved at du oprettet en ticket hos IT om at få ændret/tilføjet/fjernet mboxe. IT svarer tilbage at det vil de meget gerne og at det bliver inkluderet i den næste release der går live om 6 uger. Det er nu at den globale mbox bliver din bedste ven.

Global Mbox implementering
Den globale mbox er blot en almindelig mbox som bliver implementeret i toppen på alle sider (eller på enkelte udvalgte sider, som du ønsker at optimere). Modsat standard implementeringen, så har den globale mbox det samme navn på tværs af alle sider. Kodemæssigt ser den således ud:

Læg mærke til at mboxen ikke er implementeret rundt om noget indhold, samt at jeg har tilføjet en mbox parameter, som bliver populeret med URL’en hvor mbox bliver loadet:

Som nævnt, så har mboxen samme navn på tværs af alle sider. Så for at undgå at den kampagne jeg ønsker at køre på forsiden ikke bliver aktiv på alle andre sider – hvor den globale mbox også er implementeret – kan jeg nu target min kampagne på ovenstående mbox parameter ‘path’ og sikre at kampagnen kun er aktiv på den side jeg ønsker den skal være aktiv på. Den globale mbox giver mig også mulighed for at teste det element jeg ønsker – også selvom at der ikke er implementeret en mbox omkring det. Det kræver dog at dine offers bliver sat op lidt anderledes. Istedet for standard html skal du nu istedet skrive et script der manipulerer med DOM’en. Hvis vi skal holde fast i eksemplet fra standard implementeringen, så vil dit offer nu se således ud:

Når først du bliver vant til at benytte den globale mbox, så vil du være i stand til at teste hvor som helst og når som helst.

Fordele

  • IT behøver kun at være involveret i implementeringen af én mbox, nemlig den globale
  • Du behøver ikke vente på en release fra IT for at få de nødvendige mboxe implementeret
  • Efter at have identificeret et element der skal optimeres vil du være i stand til at oprette en test med det samme
  • Den globale mbox implementering supporterer bedre den iterative optimerings strategi for organisationen

Ulemper

  • Øget antal af mbox requests (server calls), da de nu vil matche dine page views for sitet (én mbox på hver side)
  • Oprettelse af offers kræver man har lidt mere teknisk kunnen/forståelse

Så hvis mig dog et eksempel
Det kan du tro – jeg benytter en global mbox på sitet her. Du kan se det enten ved at se kildekoden (se også nedenstående eksempel) eller du kan benytte DigitalPulse Debuggeren.

Afslutningsvis vil jeg meget gerne høre hvilken implementerings strategi du benytter, samt hvilke ulemper og fordele du oplever?


Skriv et svar