Pixelen lyser måske på websitet, og hændelserne samler sig måske i annoncekontoen. Det betyder stadig ikke, at målingen fungerer. En købshændelse kan blive udløst to gange, dens værdi kan bruge den forkerte valuta, og et lead kan blive oprettet, blot fordi nogen åbner en formular. Rapporten ser derefter præcis ud. Den beskriver bare noget andet end virksomheden.
Den oprindelige 2022-artikel undersøgte datidens grænseflade, hændelsesliste, målgrupper og indstillinger. Grænseflader ændrer sig hele tiden, og Meta samler nu webdata i datasæt. En stabil proces begynder et andet sted: design først forretningshændelserne, implementér dem derefter, og verificér dem til sidst gennem den virkelige kunderejse.
Meta Pixel måler i browseren; Conversions API sender data fra systemet
Meta Pixel er kode på websitet, som kan registrere besøg og handlinger udført i browseren. Conversions API opretter en direkte forbindelse mellem virksomhedens data — for eksempel fra en webserver, e-handelsplatform eller CRM — og Metas systemer.
For webhændelser anbefaler Meta at overveje Pixel sammen med Conversions API. En serverforbindelse kan være mindre påvirket af fejl ved indlæsning af sider, forbindelsesudfald eller visse browserblokeringer. Det betyder ikke komplette data og giver bestemt ikke tilladelse til at omgå brugernes valg. Meta siger udtrykkeligt, at Conversions API ikke er et værktøj til at omgå privatlivsregler; de aktuelle principper er beskrevet i den officielle dokumentation om Conversions API.
Begynd med det resultat, virksomheden faktisk bruger
Først skriver jeg ned, hvad annoncesystemet skal genkende, og hvilken beslutning virksomheden vil træffe ud fra det. For et e-commerce-site har jeg typisk brug for produktvisninger, tilføjelser til kurven, påbegyndte checkoutforløb og gennemførte køb. For et B2B-website kan et kvalificeret lead, en mødebooking eller et senere CRM-stadie være vigtigt.
Ikke hvert klik behøver sin egen hændelse. Jeg indsamler data med et klart formål:
- at måle kampagnens faktiske resultat;
- at optimere annoncering til en kommercielt vigtig handling;
- at opbygge en relevant målgruppe, hvor det er begrundet;
- at finde ud af, hvor folk forlader kunderejsen;
- at forbinde adfærd på websitet med resultatet i webshoppen eller CRM-systemet.
En hændelse kaldet Lead bør ikke oprettes, blot fordi nogen åbner kontaktsektionen. Purchase bør ikke udløses, når nogen besøger en takkeside-URL uden en gyldig ordre. Det tekniske navn skal stemme overens med forretningsvirkeligheden.
Alle vigtige hændelser har deres egen datakontrakt
Til implementeringen udarbejder jeg en kort beskrivelse: hvornår hændelsen udløses, hvor værdien kommer fra, hvilken valuta den bruger, hvilket produkt- eller ordre-id den sender, og hvem der har ansvaret for, at den er korrekt.
For et køb kontrollerer jeg især:
- at det kun udløses, efter ordren er gennemført korrekt;
- at værdien følger virksomhedens aftalte definition og ikke et tilfældigt totalbeløb fra skærmen;
- at valutaen bruger det korrekte format;
- at ordre- eller hændelses-id'et er unikt;
- at produkt-id'er stemmer overens med kataloget, når der bruges produktannoncer;
- at en genindlæsning af siden ikke kan udløse det gentagne gange.
Beslutningen om, hvorvidt omsætning skal rapporteres med skat, fragt eller rabatter, skal være ensartet på tværs af Meta, analyseværktøjer og økonomirapportering. Ellers viser to velfungerende platforme forskellige værdier, blot fordi de modtog forskellige instruktioner.
Pixel- og serverhændelser skal deduplikeres
Når det samme køb sendes både fra browseren og serveren, skal Meta vide, at det er én handling. Implementeringen bruger derfor samme hændelsesnavn og hændelses-id på begge veje. Hvis id'et genereres forskelligt hver gang eller mangler, kan rapporten tælle ét køb to gange.
Jeg tester ikke deduplikering ved at kigge på kildekoden. Jeg gennemfører en testordre og ser, om både browser- og serverversionen ankommer i testhændelserne, og om systemet kombinerer dem. Jeg kontrollerer de tekniske parametre mod den aktuelle dokumentation om Meta Conversions API, fordi feltnavne og anbefalinger kan ændre sig.
Vælg implementering ud fra driften, ikke egoet
Meta tilbyder partnerintegrationer, manuel installation og andre forbindelsesmetoder. De aktuelle muligheder er beskrevet i deres vejledning til opsætning af Meta Pixel. På en almindelig e-handelsplatform er en afprøvet partnerintegration som regel sikrere end specialkode uden vedligeholdelse. På et komplekst website eller CRM kan en manuel løsning være mere præcis, men den kræver dokumentation, tests og en ansvarlig ejer.
Jeg tilføjer ikke endnu et plugin, bare fordi det kaldes “avanceret”. To integrationer kan sende den samme hændelse, beregne værdien forskelligt eller overskrive samtykke. Først undersøger jeg, hvad der allerede kører på websitet.
Samtykke og dataminimering er en del af designet
Pixel og Conversions API behandler marketingdata. Virksomheden skal håndtere sine juridiske og informationsmæssige forpligtelser for den konkrete drift og det konkrete marked. Denne artikel er ikke juridisk rådgivning. Teknisk insisterer jeg dog på, at målesystemet respekterer samtykkeindstillinger og ikke sender data, som det ikke behøver til det angivne formål.
Hashing er hverken anonymisering eller et automatisk juridisk grundlag. Serverbaseret afsendelse er ikke en måde at sende det samme i hemmelighed på. Teknologien skal implementere virksomhedens beslutninger og juridiske rammer, ikke omgå dem.
Funktionskontroller skal dække hele kunderejsen
Efter lanceringen er en grøn indikator ikke nok. Jeg gennemgår websitet som kunde og kontrollerer ved hvert trin:
- Indlæses det korrekte datasæt eller den korrekte Pixel, og kun hvor den skal?
- Udløses den korrekte hændelse på det korrekte tidspunkt?
- Indeholder den den aftalte værdi, valuta, id og øvrige parametre?
- Bliver den samme hændelse oprettet to gange?
- Ankommer serverhændelsen og deduplikeres den med browserhændelsen?
- Stemmer produkt-id'erne overens med kataloget?
- Følger adfærden efter afvist samtykke den valgte tilstand?
- Vises resultatet også i webshoppen eller CRM-systemet?
Jeg bruger testhændelser i Events Manager, diagnosticering, udvidelsen Meta Pixel Helper samt en rigtig testordre eller formular. Derefter sammenligner jeg tallene med det interne system. Forskelle mellem platforme kan skyldes attribuering og tekniske begrænsninger; en markant forskel eller en præcis fordobling er et signal om, at implementeringen skal rettes.
En målgruppe er resultatet af kvalitetshændelser
Pixel gør det muligt at arbejde med mennesker ud fra besøg og handlinger på websitet. Først kontrollerer jeg dog den juridiske tilladelse, størrelsen og forretningsrelevansen. En målgruppe med alle besøgende over en lang periode kan blande kunder, jobansøgere, bots og personer, der leder efter et helt andet emne.
En bedre kilde kommer fra en klar hændelse og relation: et set produkt, en forladt kurv, en faktisk kunde eller et relevant lead. Selv da kontrollerer jeg udelukkelser for personer, der allerede har gennemført det ønskede trin, samt annoncefrekvensen.
En Metarapport er ikke virksomhedens regnskab
Platformen bruger sine egne attribueringsregler. Google Analytics 4 følger kunderejsen anderledes, mens CRM-systemet først kender leadkvaliteten efter salgsarbejdet. Tallene behøver ikke matche. Jeg skal vide hvorfor, og hvilket system der understøtter hvilken beslutning.
Jeg mærker kampagner med UTM-parametre og forbinder dem med det kommercielle resultat. Jeg gennemgår annonceringsøkonomi og målretning i artiklen om Facebook-annoncering. Til regelmæssig kontrol af alle målesystemer kan du bruge online marketing-tjeklisten.
Korrekt måling betyder ikke, at man sender så mange hændelser som muligt. Det betyder, at man sender de rigtige oplysninger på det rigtige tidspunkt, præcis én gang og af en klar grund.