BROWSER PATH
META PIXEL→BROWSER PURCHASE EVENT
META ADS TRACKING GUIDE
Meta Conversions API (CAPI): Sådan fungerer server-side events
Conversions API gør det muligt at sende marketing-events til Meta fra en server, webshop-platform, CRM eller anden serverstyret datakilde — i stedet for kun at være afhængig af JavaScript i brugerens browser. Men et godt CAPI-setup handler ikke bare om at “få events ind”. Event-navne, timing, matching-data, event IDs, deduplication og data freshness skal hænge sammen, hvis signalerne skal være brugbare.
Senest opdateret: 19 september 2026
CUSTOMER ↓ WEBSITE
SERVER PATH
STORE / BACKEND→CAPI PURCHASE EVENT
META DATASET / EVENTS MANAGER
MATCHINGDEDUPLICATIONOPTIMISATION SIGNAL
event: Purchase source: browser eventID: ORDER-DEMO-001 value: 799 DKK
Forenklet, illustrativ arkitektur. Ingen data sendes.
01 — FOUNDATION
Hvad er Meta Conversions API?
CAPI giver virksomheder en direkte forbindelse mellem deres marketingdata og Meta. Events kan komme fra en e-commerce-backend, server, CRM, partnerintegration, server-side tag-infrastruktur eller understøttet commerce-platform.
Event origin er det system, hvor den virkelige handling bliver kendt. Event transport er vejen fra det system til Meta. Et Purchase kan eksempelvis opstå, når backenden bekræfter ordren, og derefter transporteres gennem CAPI. CAPI erstatter ikke automatisk Pixel; ved webmåling kan forbindelserne være redundante og komplementære.
ORIGIN
Ordren bekræftes i webshop-backenden.
TRANSPORT
Integration eller serverlag bygger requesten.
DESTINATION
Meta dataset / Events Manager
02 — EVENT ANATOMYVALUE
Hvad indeholder et CAPI-event?
Et serverevent består af information om selve handlingen, dens tidspunkt og kilde samt data, der kan hjælpe med matching og beskrive den kommercielle handling. Krav afhænger af eventtype og kilde; website-events kræver blandt andet action_source, event_source_url og client_user_agent, og user_data skal indeholde mindst ét kundeinformationsparameter.
Purchase
HVAD DET BETYDERBeskriver hvilken standard- eller custom handling der skete.
HVORFOR DET BETYDER NOGETFeltet fortæller Meta, hvilken type handling payloaden repræsenterer.
TYPISK IMPLEMENTERINGSFEJLEventnavne afviger mellem browser og server.
Meta: Parameters · Server Event Parameters
03 — STANDARD EVENTS
event_name: Hvad fortæller eventet Meta?
event_name er påkrævet og beskriver handlingstypen. Standardevents giver en fælles semantik for velkendte handlinger; custom events bruges til andre forretningsspecifikke handlinger. Brug kun et standardnavn, når den virkelige handling svarer til definitionen.
PageView: Page loaded
Klik på et trin for et forenklet eksempel. Purchase bør repræsentere en reelt bekræftet ordre.
04 — TIMING
event_time og data freshness
event_time er et påkrævet Unix-timestamp i GMT og skal repræsentere tidspunktet, hvor forretningshandlingen faktisk skete — ikke blot hvornår en kø blev behandlet. Metas aktuelle dokumentation accepterer event_time op til syv dage tilbage; ældre requests afvises. Det er en teknisk grænse, ikke et mål for god levering.
Data freshness handler om, hvor hurtigt et event bliver tilgængeligt efter handlingen. Større forsinkelse kan reducere signalets aktualitet. Meta beskriver, at afsendte events bør kunne verificeres i Events Manager inden for 20 minutter, men det er ikke et løfte om attribution eller performance.
Event Delivery Timeline
PURCHASE
T+0BROWSER
T+0.2SERVER
T+1.0META
T+0BROWSER
T+0.2SERVER
T+1.0META
All default times are illustrative. No performance penalty is calculated.
05 — MATCHING INPUTSEmail
user_data: Hvordan hjælper matching-data Meta?
user_data indeholder kundeinformation, der kan hjælpe Meta med at associere et event med en konto. Aktuelle webrelevante felter kan blandt andet omfatte e-mail, telefon, external_id, client_ip_address, client_user_agent, fbc og fbp, når de er tilgængelige, relevante og lovligt behandlet.
Meta kræver normalisering og SHA-256-hashing af e-mail, telefon, navn, køn, fødselsdato, by, region, postnummer og land. external_id anbefales hashed. IP, user agent, fbc og fbp må ikke hashes. Brug Metas SDK eller dokumenterede metode — ikke hjemmeskrevet kryptografi.
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
Phone
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
External ID
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
Browser ID (_fbp)
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
Click ID (_fbc)
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
IP address
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
User agent
Potentielt matching-input; kun hvor relevant, tilladt og korrekt formateret.
06 — EVENT MATCH QUALITY
Event Match Quality: Hvad måler Meta egentlig?
Event Match Quality relaterer sig til, hvor effektivt kundeinformationen på website-events sendt via CAPI kan bruges til at matche eventet til Meta-konti. Den faktiske vurdering beregnes af Meta.
Det er ikke ROAS, attribution accuracy, konverteringskvalitet, creative quality eller en profitscore. En høj vurdering garanterer ikke annonceperformance.
Matching Input Explorer
Begrænsede matching-inputs
Faktisk Event Match Quality: Beregnes af Meta
Faktisk Event Match Quality: Beregnes af Meta
Ingen score genereres, og ingen data indsamles eller sendes.
Meta: Event Match Quality
07 — COMMERCE CONTEXT
WHAT → custom_data
custom_data: Værdi, valuta og produktdata
custom_data beskriver, hvad den kommercielle handling indeholdt: eksempelvis value, currency, content_ids, content_type og quantity/order information, hvor eventet og integrationen understøtter det. user_data hjælper med spørgsmålet hvem; custom_data beskriver hvad.
FICTIONAL PURCHASE
WHO → user_dataPurchase
- Value
- 799 DKK
- Product
- SKU-123
- Quantity
- 1
WHAT → custom_data
08 — IDENTIFIERBrowser Purchase
ORDER-DEMO-001 +Server Purchase
ORDER-DEMO-001
event_id: Nøglen til browser/server deduplication
Når samme forretningshændelse sendes gennem Pixel og CAPI, anbefaler Meta samme eventnavn og event-ID. Pixel bruger browserparameteren eventID; CAPI bruger event_id. For et køb bør identifieren være stabil for den konkrete ordreforekomst og ikke indeholde rå personoplysninger.
Event ID Generator Demo
ORDER-DEMO-001
ORDER-DEMO-001
MATCHED PAIR
Educational only. Fictional IDs; no customer or order data is used.
Meta: Deduplicate Pixel and server events · Server Event Parameters
09 — ONE BUSINESS EVENTPIXEL = 1
RECOGNISED OVERLAP
Sådan fungerer deduplication mellem Pixel og CAPI
To tekniske beskeder kan beskrive én virkelig forretningshændelse. Målet er derfor to leveringsveje, men ét logisk event. Diagrammet illustrerer det primære princip og reproducerer ikke alle Metas interne regler.
REAL PURCHASE = 1
PIXEL = 1
CAPI = 1
RECOGNISED OVERLAP
LOGICAL PURCHASE = 1
Deduplication Debugger
Browser
Server
PRIMARY DEDUPLICATION KEYS ALIGN
Simplified educational check. No values leave this page.
Meta: Deduplication guidance
10 — EVENT COUNTS
Event coverage: Modtager Meta de events, du forventer?
Event coverage er forskellig fra Event Match Quality. Coverage sammenligner eventantal med den forretningskilde, du forventer; matching handler om kundeinformationens anvendelighed. Ingen af delene er det samme som attribution accuracy.
Event Coverage Calculator
Browser coverage
Server coverage
Unikt repræsenteret
Repræsenteret coverage
Kun matematisk sammenligning af eventantal. Alle tal er illustrative/brugerindtastede — ikke benchmarks eller attribution accuracy.
11 — PURCHASE PIPELINE
Fra webshopordre til Meta-event
Et pålideligt Meta CAPI Purchase-event begynder med den rigtige forretningshændelse. Klik gennem den forenklede arkitektur. Den præcise rækkefølge afhænger af commerce-platform og implementering.
The customer submits checkout.
12 — EVENTS MANAGER
Sådan tester du CAPI før og efter launch
Start med en kontrolleret testhandling og kontrollér, at det forventede eventnavn, forbindelsesmetode og de relevante parametre vises. Se efter browser- og serverkilden, deduplication, event freshness og Diagnostics. Metas testfunktion bruger en test_event_code i requestens hovedpayload; den er ikke en permanent produktionsindstilling.
Efter launch bør QA fortsætte. Website-, checkout-, consent-, app- og integrationsændringer kan ændre eventflowet. Afstem derfor Purchase mod backend, gennemgå advarsler og verificér timing med faste intervaller.
- Test events
- Expected event names
- Connection method
- Parameter validation
- Diagnostics
- Browser/server source
- Deduplication
- Event freshness
Meta: Verifying your setup · Using the API
13 — MONITORING
Events Manager QA-dashboard
Et godt dashboard hjælper dig med at spørge: ankommer eventet fra de forventede kilder, aligner de redundante kopier, er matching-inputs tilgængelige, er leveringen aktuel, og viser Diagnostics noget, der kræver handling?
| Event | Browser received | Server received | Deduplication | Matching inputs | Freshness | Diagnostics |
|---|---|---|---|---|---|---|
| Purchase | OK | OK | OK | CHECK | OK | CHECK |
| AddToCart | OK | OK | OK | CHECK | CHECK | OK |
| InitiateCheckout | OK | MISSING | CHECK | CHECK | OK | CHECK |
| ViewContent | OK | CHECK | CHECK | OK | OK | OK |
Educational mockup — not the real Meta interface. Tilstandene er fiktive og viser kun en QA-tankegang.
14 — DIAGNOSTICS
10 fejl der kan ødelægge et CAPI-setup
Åbn kortene for en praktisk fejlsøgningsramme.
SYMPTOM: Forskellige event-ID’er på browser og server
HVORFOR DET BETYDER NOGET: Kopierne kan ikke alignes via den primære nøgle.
KONTROLLÉR: Sammenlign Pixel eventID og CAPI event_id.
SYMPTOM: Eventnavnene matcher ikke
HVORFOR DET BETYDER NOGET: Samme ID er ikke tilstrækkeligt, hvis navnene afviger.
KONTROLLÉR: Kontrollér event_name og casing på begge veje.
SYMPTOM: Purchase sendes før ordren er bekræftet
HVORFOR DET BETYDER NOGET: Et forsøg kan blive repræsenteret som et gennemført køb.
KONTROLLÉR: Bind servereventet til den rigtige ordre- og betalingsstatus.
SYMPTOM: Purchase affyres mere end én gang
HVORFOR DET BETYDER NOGET: Reloads, retries eller flere hooks kan skabe dubletter.
KONTROLLÉR: Gennemgå triggers, idempotens og order ID.
SYMPTOM: Forkert valuta eller værdi
HVORFOR DET BETYDER NOGET: Den kommercielle værdi af eventet bliver misvisende.
KONTROLLÉR: Sammenhold custom_data med ordren.
SYMPTOM: Produkt-ID’er matcher ikke commerce-setuppet
HVORFOR DET BETYDER NOGET: Produkter og events kan ikke kobles som tiltænkt.
KONTROLLÉR: Afstem content_ids med katalogets ID-struktur.
SYMPTOM: Matching-parametre er fejlformaterede
HVORFOR DET BETYDER NOGET: Meta kan ikke bruge informationen som forventet.
KONTROLLÉR: Kontrollér normalisering, hashing og ikke-hashede felter.
SYMPTOM: Events ankommer unødigt sent
HVORFOR DET BETYDER NOGET: Signalets data freshness bliver svagere.
KONTROLLÉR: Gennemgå køer, retries og event_time.
SYMPTOM: Consent-logikken afviger mellem browser og server
HVORFOR DET BETYDER NOGET: De to stier respekterer ikke samme brugerbeslutning.
KONTROLLÉR: Spor consent-state gennem hele dataflowet.
SYMPTOM: Ingen overvåger Events Manager efter launch
HVORFOR DET BETYDER NOGET: Nye fejl og datadrift opdages sent.
KONTROLLÉR: Planlæg faste checks af Diagnostics, freshness og events.
15 — LIMITS
Hvad CAPI ikke løser
CAPI kan give Meta stærkere measurement-inputs, men det er ikke en vækststrategi i sig selv. Det løser ikke automatisk:
svagt creative
dårlige landingssider
et dårligt tilbud
lav konverteringsrate
ulønsom unit economics
svag kampagnestruktur
forkert optimeringsmål
Stærk tracking giver stærkere information. Den kan ikke reparere et svagt tilbud eller dårlig økonomi.
16 — ARCHITECTURE
Hvordan kan Conversions API implementeres?
Der er ingen universel vinder. Vælg ud fra eventkilde, commerce-platform, tekniske ressourcer, consent, destinationer og vedligeholdelse. Se den bredere guide til server-side vs. browser-side tracking for ProfitMetrics og Reaktion.
Direct integration
Maximum architectural control; requires engineering ownership and maintenance.
Partner/platform integration
Faster implementation; capability and control depend on the partner.
Server-side GTM / middleware
Flexible routing and governance; adds infrastructure and specialist maintenance.
Ecommerce tracking platform
Commerce-focused workflows; evaluate platform fit, destinations, costs and reporting.
17 — READINESS
Er fundamentet klar til et CAPI-review?
Implementation Readiness Check
Virker Meta Pixel?
Bruges det korrekte dataset?
Bekræftes Purchase i backenden?
Kan ét stabilt event-ID genereres?
Kan samme ID nå browser og server?
Er consent-logikken defineret?
Er matching-felter tilgængelige?
Overvåges Events Manager?
TRACKING-FUNDAMENTET SKAL ARBEJDES IGENNEM
Kun en lokal, uddannelsesmæssig selvvurdering. Ingen svar sendes.
FAQ
Ofte stillede spørgsmål om Meta Conversions API
Meta Conversions API er en forbindelse, der gør det muligt at sende marketing-events fra virksomhedskontrollerede datakilder som en server, commerce-platform, CRM eller partnerintegration til Meta.
CAPI er den almindelige forkortelse for Conversions API.
Ja. CAPI er en server-side forbindelse til Meta, men den konkrete eventkilde kan være en backend, platform, CRM, partner eller server-side tag-infrastruktur.
Nej. Pixel sender web-events fra browseren, mens CAPI sender fra en serverstyret kilde. Ved webmåling kan de være komplementære forbindelser.
Ikke som en universel regel. Meta anbefaler redundante forbindelser, hvor de passer til setup’et; samme event skal da alignes og deduplikeres korrekt.
event_id er en identifier for en konkret eventforekomst og anbefales til deduplication. Pixel kalder browserparameteren eventID, mens servereventet bruger event_id.
Browser- og serverkopier af samme handling kan genkendes via samme eventnavn og samme event-ID, så to tekniske beskeder kan repræsentere ét logisk event.
Event Match Quality beskriver, hvor effektivt kundeinformationen på website-events via CAPI kan hjælpe Meta med at matche eventet til Meta-konti. Det er ikke en performance- eller ROAS-score.
Event coverage sammenligner her forventede forretningsevents med modtagne events. Det er ikke det samme som Event Match Quality eller attribution accuracy.
Et serverevent kan blandt andet indeholde event_name, event_time, action_source, event_source_url, user_data, custom_data og event_id, afhængigt af event og use case.
Ja. Meta kræver hashing af email og telefon samt flere andre kontaktfelter. De skal normaliseres efter Metas specifikationer og SHA-256-hashes; SDK’er kan håndtere hashing.
Serverleveringen afhænger ikke af browser-JavaScript eller browsercookies, men tilladte browser- og click-identifiers kan stadig indgå. Kvalitet og funktion afhænger af de tilgængelige signaler.
Nej. CAPI fjerner ikke krav om samtykke, lovligt behandlingsgrundlag, dataminimering, Metas vilkår eller respekt for brugerens privacyvalg.
Brug en kontrolleret testordre og Metas testfunktioner i Events Manager til at kontrollere eventnavn, forbindelsesmetode, parametre, kilder, deduplication og timing.
Events Manager viser modtagne events, forbindelsesmetode, Diagnostics og relevante kvalitetsindikatorer. Afstem også Purchase-events med backenddata.
META ADS TRACKING
Et godt CAPI-setup handler om mere end at få et grønt flueben
Browser-events, server-events, matching, deduplication og kampagneoptimering skal hænge sammen. JLDigital hjælper e-commerce brands med at se tracking og Meta Ads som ét samlet system.
Se hvordan vi arbejder med Meta Ads