Pixel kan lysa på webbplatsen och händelser kan samlas i annonskontot. Det betyder ändå inte att mätningen fungerar. En köphändelse kan utlösas två gånger, värdet kan använda fel valuta och ett lead kan skapas när någon bara öppnar ett formulär. Rapporten ser då exakt ut. Den beskriver helt enkelt något annat än verksamheten.
Den ursprungliga 2022-artikeln granskade dåtidens gränssnitt, händelselista, målgrupper och inställningar. Gränssnitt förändras hela tiden, och Meta grupperar nu webbdata i dataset. En stabil process börjar någon annanstans: designa affärshändelserna först, implementera dem därefter och verifiera slutligen mätningen längs hela den verkliga kundresan.
Meta Pixel mäter i webbläsaren; Conversions API skickar data från systemet
Meta Pixel är webbplatskod som kan registrera besök och åtgärder som utförs i webbläsaren. Conversions API skapar en direkt anslutning mellan företagets data – till exempel från en webbserver, e-handelsplattform eller CRM – och Metas system.
För webbhändelser rekommenderar Meta att man överväger Pixel tillsammans med Conversions API. En serveranslutning kan påverkas mindre av fel vid sidladdning, anslutningsavbrott eller viss blockering i webbläsaren. Det betyder inte fullständiga data och ger naturligtvis inte rätt att kringgå användarnas val. Meta säger uttryckligen att Conversions API inte är ett verktyg för att kringgå integritetsregler; de aktuella principerna beskrivs i den officiella dokumentationen för Conversions API.
Börja med det resultat företaget faktiskt använder
Först skriver jag ner vad annonssystemet ska känna igen och vilket beslut företaget ska fatta utifrån det. För en e-handelswebbplats behöver jag vanligtvis produktvisningar, tillägg i kundvagnen, påbörjade kassor och genomförda köp. För en B2B-webbplats kan ett kvalificerat lead, en mötesbokning eller ett senare CRM-steg vara viktigt.
Alla klick behöver inte en egen händelse. Jag samlar in data med ett tydligt syfte:
- mäta kampanjens faktiska resultat;
- optimera annonseringen för en kommersiellt viktig åtgärd;
- bygga en relevant målgrupp där det är motiverat;
- ta reda på var människor lämnar kundresan;
- koppla beteendet på webben till resultatet i butiken eller CRM-systemet.
En händelse som kallas Lead ska inte skapas bara för att någon öppnar kontaktsektionen. Purchase ska inte utlösas när någon besöker en tack-URL utan en giltig order. Det tekniska namnet måste motsvara verkligheten i verksamheten.
Varje viktig händelse har sitt eget datakontrakt
Inför implementeringen tar jag fram en kort beskrivning: när händelsen utlöses, var värdet kommer ifrån, vilken valuta den använder, vilket produkt- eller order-ID den skickar och vem som ansvarar för att den är korrekt.
För ett köp kontrollerar jag främst att:
- det bara utlöses efter att ordern har slutförts framgångsrikt;
- värdet följer företagets överenskomna definition, inte en oavsiktlig totalsumma från skärmen;
- valutan använder rätt format;
- order- eller händelse-ID:t är unikt;
- produkt-ID:n matchar katalogen när produktannonser används;
- en omladdning av sidan inte kan utlösa det upprepade gånger.
Beslutet om intäkter ska rapporteras inklusive skatt, frakt eller rabatter måste vara konsekvent i Meta, analysverktygen och den ekonomiska rapporteringen. Annars visar två plattformar som fungerar korrekt olika värden helt enkelt för att de fick olika instruktioner.
Pixel- och serverhändelser måste dedupliceras
När samma köp skickas både från webbläsaren och servern måste Meta veta att det är en och samma åtgärd. Implementeringen använder därför samma händelsenamn och händelse-ID i båda flödena. Om ID:t genereras olika varje gång eller saknas kan rapporten räkna samma köp två gånger.
Jag testar inte deduplicering genom att titta på källkoden. Jag lägger en testorder och ser efter om både webbläsar- och serverversionen kommer fram i testhändelserna och om systemet slår ihop dem. Jag kontrollerar de tekniska parametrarna mot den aktuella dokumentationen för Meta Conversions API, eftersom fältnamn och rekommendationer kan förändras.
Välj implementering utifrån driften, inte egot
Meta erbjuder partnerintegrationer, manuell installation och andra anslutningsmetoder. De aktuella alternativen beskrivs i deras guide för att konfigurera Meta Pixel. På en vanlig e-handelsplattform är en testad partnerintegration oftast säkrare än specialkod utan underhåll. På en komplex webbplats eller i ett CRM kan en manuell lösning vara mer exakt, men den behöver dokumentation, tester och en ansvarig ägare.
Jag lägger inte till ännu ett tillägg bara för att det kallas ”avancerat”. Två integrationer kan skicka samma händelse, beräkna värdet på olika sätt eller skriva över samtycket. Först tar jag reda på vad som redan körs på webbplatsen.
Samtycke och dataminimering är en del av designen
Pixel och Conversions API behandlar marknadsföringsdata. Företaget måste hantera sina juridiska skyldigheter och informationsskyldigheter utifrån den specifika verksamheten och marknaden. Den här artikeln är inte juridisk rådgivning. Tekniskt kräver jag däremot att mätsystemet respekterar samtyckesinställningarna och inte skickar data som inte behövs för det angivna syftet.
Hashning är varken anonymisering eller en automatisk rättslig grund. Serverbaserad sändning är inte ett sätt att skicka samma sak i hemlighet. Tekniken ska genomföra företagets beslut och juridiska ramverk, inte kringgå dem.
Funktionskontroller måste omfatta hela kundresan
Efter lanseringen räcker inte en grön indikator. Jag går igenom webbplatsen som kund och kontrollerar vid varje steg:
- Laddas rätt dataset eller Pixel, och bara där det ska?
- Utlöses rätt händelse vid rätt tidpunkt?
- Innehåller den det överenskomna värdet, valutan, ID:t och övriga parametrar?
- Skapas samma händelse två gånger?
- Kommer serverhändelsen fram och dedupliceras med webbläsarhändelsen?
- Matchar produkt-ID:n katalogen?
- Följer beteendet efter nekat samtycke det valda läget?
- Visas resultatet också i butiken eller CRM-systemet?
Jag använder testhändelser i Events Manager, diagnostik, tillägget Meta Pixel Helper och en riktig testorder eller ett testformulär. Därefter jämför jag antalen med det interna systemet. Skillnader mellan plattformar kan bero på attribuering och tekniska begränsningar; en dramatisk skillnad eller en exakt fördubbling är en signal om att implementeringen behöver åtgärdas.
En målgrupp är resultatet av händelser av hög kvalitet
Pixel gör det möjligt att arbeta med människor utifrån besök och åtgärder på webbplatsen. Först kontrollerar jag dock juridiskt tillstånd, storlek och affärsrelevans. En målgrupp med alla besökare under en lång period kan blanda kunder, arbetssökande, botar och personer som letar efter ett helt annat ämne.
En bättre källa bygger på en tydlig händelse och relation: en visad produkt, en övergiven kundvagn, en faktisk kund eller ett relevant lead. Även då kontrollerar jag undantag för personer som redan har genomfört det önskade steget samt annonsfrekvensen.
En Meta-rapport är inte företagets bokföring
Plattformen använder sina egna attribueringsregler. Google Analytics 4 följer kundresan på ett annat sätt, medan CRM-systemet känner till leadkvaliteten först efter säljarbetet. Siffrorna behöver inte stämma överens. Jag behöver veta varför och vilket system som stödjer vilket beslut.
Jag taggar kampanjer med UTM-parametrar och kopplar dem till det kommersiella resultatet. Jag diskuterar annonseringsekonomi och målgruppsinriktning i artikeln om Facebook-annonsering. För regelbundna kontroller av alla mätsystem använder du checklistan för onlinemarknadsföring.
Korrekt mätning betyder inte att man skickar så många händelser som möjligt. Det betyder att man skickar rätt information vid rätt tidpunkt, exakt en gång och av en tydlig anledning.