> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/documentation/documentation-nl/optimaliseer-je-setup/webhook-matching.md).

# Webhook-matching

Zorg ervoor dat de webhookfunctionaliteit van AdPage aankoopgebeurtenissen altijd naar GA4 en marketingplatformen stuurt met de juiste toestemmingssignalen en marketinggegevens

### Wat doet Webhook Matching?

Gebeurtenissen voor aankopen die in de browser afgaan zijn kwetsbaar. Adblockers kunnen ze stoppen, cookiebeperkingen kunnen gegevens wegsnijden, en Safari's ITP kan de data afkappen voordat die je ooit bereikt. Server-side tagging lost deze problemen op, maar er zijn nog steeds drie scenario's waarin browser-side aankooptracking niet werkt.

1. Bezoekers die nooit terugkeren naar je bedankpagina. Ze betalen in hun bank-app, zien daar de bevestiging en sluiten die af. Voor hen is de klus geklaard. Als ze niet op je bedankpagina landen, wordt de browsergebeurtenis nooit afgevuurd.
2. Bezoekers die wel op de bedankpagina landen maar te snel vertrekken. Je trackingscripts hebben even nodig om te laden en te verzenden. Sluit het tabblad daarvoor, en de gebeurtenistracking sterft ermee.
3. Iemand begint zijn traject in een browser in de app, misschien in een LLM-app of een sociale app, en wordt daarna doorgestuurd naar zijn betaal-app. Op de terugweg geeft de betaal-app hem door aan welke browser op zijn telefoon ook maar als standaard is ingesteld. Nu zit hij in een totaal andere browser met een andere sessie en zonder cookies van het oorspronkelijke bezoek, dus zelfs een perfect geladen bedankpagina rapporteert het als iets anders dan wat het is.

Backend-webhooks van je shopplatform (Shopify, WooCommerce, Magento) hebben dat probleem niet omdat ze rechtstreeks vanaf de server worden verzonden. De keerzijde is dat ze zonder browsercontext kunnen binnenkomen, dus geen `gclid`, geen user-agent en geen items-array. AdPage's Webhook Matching koppelt de browserdata en de webhookdata aan elkaar met behulp van een gedeelde matchings-ID, voegt de payloads samen en stuurt één gevalideerde gebeurtenis door. Het resultaat: geen dubbele conversies, en ook geen gemiste.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2F3TFREPT1hh29haoO8acq%2FWebhook%20Notifier%20(7).png?alt=media&amp;token=25d9be4a-5492-427d-bb88-e12ccd8b21d8" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2F4kSU4XBsHmHgBawhABCC%2FWebhook%20Notifier%20(6).png?alt=media&amp;token=3ae3419f-fc23-4bfc-95ac-9c9ccfb3c86e" alt=""><figcaption></figcaption></figure>

### Webhook Matching instellen

Er zijn twee stappen om Webhook Matching in te stellen.

**Stap 1** is het verwerken van de inkomende webhook (Trigger) en een begin\_checkout-gebeurtenis (Prepare) om ervoor te zorgen dat die gematcht kunnen worden.

Nadat de matchingsgraad hoog genoeg is (>90%) kunnen deze gematchte webhooks worden doorgestuurd naar Google Analytics en je marketingplatforms; dat instellen is **Stap 2**.

{% stepper %}
{% step %}

#### Stap 1: de Webhook Matching-graad instellen

1. Open de servercontainer in Google Tag Manager
2. Ga naar Templates → Tag Templates → Nieuw
3. Klik op de drie puntjes rechtsboven → Importeren → selecteer `adpage-event-notifier.tpl`. Je kunt het hier downloaden: <https://adpage.b-cdn.net/GTM-Templates/adpage-event-notifier.tpl>
4. Klik op Opslaan. De template "AdPage Event Notifier" verschijnt nu in de templatelijst
5. Maak twee tags aan met deze template:

**Tag 1 — Prepare (gebeurtenis ontvangen van client-side):**

* Modus: `Prepare`
* Container-ID: te vinden in de URL van je AdPage-servercontainer
* Platformvoorinstelling: kies wat van toepassing is (zie hieronder)
* Gebeurtenisnaam: `purchase`
* Trigger: een browsergebeurtenis net vóór het voltooien van de checkout (bijv. `begin_checkout`)

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FzDelZYkvyynWS7DIIjGV%2Fimage.png?alt=media&amp;token=deb4f40f-4270-4d46-b453-700276884be6" alt=""><figcaption></figcaption></figure>

**Tag 2 — Trigger (server-side webhook):**

* Modus: `trigger`
* Container-ID: te vinden in de URL van je AdPage-servercontainer
* Platformvoorinstelling: hetzelfde als hierboven (zie hieronder)
* Transactie-ID: een Event Data-variabele met `transaction_id` als het Key Path
* Trigger: de webhookgebeurtenis van je commerceplatform (de webhook die wordt verwerkt door [de AdPage Webhook Client](/extensions/extensions-nl/sjablonen-voor-google-tag-manager/adpage-webhookclient.md))

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FrYzzeYqJgg3oxVBb3xk0%2Fimage.png?alt=media&amp;token=b8f963c1-217b-484a-9441-7c209a62a95f" alt=""><figcaption></figcaption></figure>

**Platformvoorinstelling**

De optie voor de platformvoorinstelling is de BasketKey die je wilt gebruiken om de Prepare- en Trigger-zijden aan elkaar te koppelen; beide moeten dezelfde waarde verzenden, anders matchen ze niet.

| Instelling                                                 | Voorinstelling                | BasketKey                                      |
| ---------------------------------------------------------- | ----------------------------- | ---------------------------------------------- |
| Client heeft de AdPage Tagging-plugin/script geïnstalleerd | AdPage Tagging (universeel) ⭐ | `user_id` (uit de `trytagging_user_id` cookie) |
| Native Shopify (geen Tagging-plugin)                       | Shopify                       | `cart_token`                                   |
| Native Magento                                             | Magento                       | `quote_id`                                     |
| Native Lightspeed C-Series                                 | Lightspeed                    | `quote_id`                                     |
| Native Shopware 6                                          | Shopware                      | `cart_token`                                   |
| Iets anders / aangepaste integratie                        | Aangepast                     | definieer je eigen                             |

{% hint style="info" icon="webhook" %}
Voor ongeveer 95% van de klanten, **AdPage Tagging (universeel)** is de juiste keuze; het werkt op elk platform omdat de AdPage-taggingstack overal dezelfde `user_id` UUID gebruikt: in de browser (`trytagging_user_id` cookie) en in de webhook (`marketing.user_id`).
{% endhint %}

{% hint style="danger" %}
**Stuur de BasketKey nooit door `user_id` als GA4's eigen `user_id` parameter.**

De `user_id` die hier wordt gebruikt is AdPage's eigen matchings-ID — deze bestaat alleen om Prepare en Trigger aan elkaar te koppelen en heeft niets te maken met GA4's gereserveerde, op het hoogste niveau aanwezige `user_id` veld uit GA4's User-ID-functie.

Als deze BasketKey-waarde wordt gemapt naar de uitgaande Measurement Protocol-payload als GA4's `user_id` (bijvoorbeeld via een aangepaste field override op de MP-client/tag), gaat GA4 het zien als een persistente, sessie-overstijgende identiteit terwijl dat niet zo is. Onder **Geobserveerd** of **Gemengd** Rapporteringsidentiteit geeft GA4 User-ID voorrang boven Client ID bij het bepalen van wiens traject een hit toebehoort. Omdat de doorgestuurde `user_id` bij een via een webhook gematchte aankoop meestal niet dezelfde `ga_session_id` als de browsersessie van de bezoeker draagt, kan GA4 de webhook-hit niet langer herkennen als dezelfde order als de client-side hit — in plaats van te worden gededupliceerd op `transaction_id` binnen één identiteit, wordt die geteld als een tweede, afzonderlijke aankoop onder een andere "Effective User ID".

\
Stuur alleen `user_id` door naar GA4 als het een echte, stabiele GA4 User-ID is die de client al consequent instelt bij login (client-side, via `gtag('config', ...)`, volgens Google's eigen User-ID-vereisten) — nooit de BasketKey-matchingswaarde.
{% endhint %}

Publiceer de Google Tag Manager-servercontainer met deze 2 nieuwe tags. De inkomende begin\_checkout-gebeurtenissen en webhooks worden automatisch gematcht in je AdPage-servercontainer. Controleer na een paar dagen de Webhook Matching-graad.
{% endstep %}

{% step %}

### Stap 2: de webhook matching-graad valideren

Een paar dagen na het publiceren van stap 1 kun je de webhook matching-graad bekijken binnen je AdPage-servercontainer.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FFve4wkkcN3HQjIHI9tkO%2Fimage.png?alt=media&amp;token=89e74b41-c781-4b96-813c-500db2c648f5" alt=""><figcaption></figcaption></figure>

Als de matchingsgraad boven 90% ligt, kun je hieronder doorgaan met stap 3.

Als de matchingsgraad onder 90% ligt, moet je de webhook-matchingconfiguratie aanpassen. Pas de configuratie aan rechtsboven achter de **Configuratie** knop. Hier vind je de volgende configuratie-instellingen:

**Extra identificatiecode (fallback)**\
Kies een veld dat in zowel prepare als trigger aanwezig is (`user_id`, `cart_token`). Het is de enige deterministische optie, heeft voorrang op de andere en behoudt de normale status Gematcht. Meestal de grootste enkele winst.

**Transactie-ID-prefix**\
Alleen nodig wanneer dezelfde order via twee bronnen met verschillende ID-formaten binnenkomt. Vul de prefix in en vink het selectievakje "negeren" aan zodat de kale duplicaat wordt verwijderd. Laat leeg als er één bron is.

**Probabilistische matching**\
Standaard uitgeschakeld. Koppelt gemiste orders aan een recente prepare op basis van items, waarde, identiteit en timing. Status wordt Probable. Inschakelen wanneer er geen fallbackveld beschikbaar is; wees voorzichtig bij shops met veel bijna-identieke orders met lage waarde.

**Alleen Trigger**\
Standaard uitgeschakeld. Stuurt de order op de `_ga` client\_id alleen, zonder een prepare. Herstelt orders waarbij de prepare nooit is afgevuurd. Zwakkere attributie, maar de conversie blijft behouden. Status: Alleen Trigger.

**Conversies zonder toestemming**\
Standaard aan, laat het aan. Stuurt een cookieloos ping zonder PII voor orders zonder toestemming zodat GA4 ze kan modelleren. Alleen uitschakelen nadat je het privacybeleid van de klant hebt gecontroleerd.
{% endstep %}

{% step %}

#### Stap 3: de gematchte webhooks benutten

Om de gematchte webhooks te kunnen benutten, moet je een GA4 Measurement Protocol-client aanmaken. De Webhook Matching-callback komt binnen op je sGTM `/mp` eindpunt. Daar moet een client aanwezig zijn om het binnenkomende Measurement Protocol-verzoek op te vangen en er een gebeurtenis van te maken die je downstream-tags (GA4, Google Ads, Meta CAPI, enz.) kunnen oppikken.

1. Maak de client aan: ga in je servercontainer naar **Clients → Nieuw**, kies clienttype **Measurement Protocol (GA4)**, en geef het een herkenbare naam zoals "AdPage MP". Stel **Pad / Activatie** in op je callback-URL, `/mp`.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2Ftn1AU94XTkykQUEgCtcT%2Fimage.png?alt=media&amp;token=c1d683c7-8868-4e34-84b5-9b56de6ab9f4" alt=""><figcaption></figcaption></figure>

2. Blokkeer de aankoopgebeurtenissen in je normale GA4-trigger: voeg de voorwaarde toe aan je normale GA4-trigger dat 'Event Name' niet gelijk is aan 'purchase'.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FsMHv1jOOQqyXpbhan7El%2Fimage.png?alt=media&amp;token=23ed5e72-c417-4b6f-8266-3c8feeefdb81" alt=""><figcaption></figcaption></figure>

3. Voeg een nieuwe Measurement Protocol Client-trigger toe: maak een nieuwe trigger aan die afgaat op alle inkomende verzoeken in je Measurement Protocol-client. Voeg deze trigger na het aanmaken toe aan je Google Analytics 4-tag.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FVALr883pzWJhvOyvBrU9%2Fimage.png?alt=media&amp;token=b8fd9b75-f6c1-402c-bbaa-325aedccff6e" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FinkOI4Qvfvni7WVFgrqu%2Fimage.png?alt=media&amp;token=f3eb56ba-90e4-4bce-acfb-fe9efe0b6891" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### Testen en debuggen

Voordat je de wijzigingen publiceert die zijn gemaakt voor **Stap 2**, bevestig je dat Prepare en Trigger daadwerkelijk matchen.

{% stepper %}
{% step %}

#### Gebruik de Webhook Replay-functionaliteit om de gematchte webhooks te testen

Om de gematchte webhook te testen zonder een nieuwe bestelling te plaatsen,

1. Ga naar de **Webhooklogs**
2. Zoek een gematchte webhook en open deze door erop te klikken
3. Zoek de **Opnieuw afspelen** knop onderaan

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FdzhKmFGiC8jw81vO7GoI%2Fimage.png?alt=media&amp;token=699f0716-6b8c-4ffc-b5ad-1501b630bd4e" alt=""><figcaption></figcaption></figure>

4. Ga naar je Google Tag Manager-servercontainer en start de previewmodus
5. Klik op de 3 puntjes rechtsboven en selecteer de optie **Verzoeken handmatig versturen**, kopieer de HTTP-header X-Gtm-Server-Preview.
6. Plak de HTTP-header X-Gtm-Server-Preview in het invoerveld voor Matched Webhook Replay
7. De webhook wordt opnieuw afgespeeld in de previewmodus van Google Tag Manager, zodat je precies kunt zien welke tags afgaan en wat de uitgaande payloads van die tags zijn.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FAd2oSHV7tCPYiDAD5GRN%2Fimage.png?alt=media&amp;token=7117972d-a068-4e10-a63b-7b4827331743" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### Het Webhook Matching-dashboard lezen

Onder **Webhook Matching → Matchgezondheid**, kun je in één oogopslag zien hoe goed Prepare en Trigger hebben gematcht over de geselecteerde periode (standaard 7 dagen), en waar things misgaan.

Het percentage bovenaan is het aandeel van succesvol verwerkte orders — gematcht, afgehandeld via in-app browsers of cookieloos — ten opzichte van het totale aantal inkomende orders.

* **Gematcht** — Prepare en Trigger zijn gekoppeld op de Basket ID. Dit is het gezonde pad.
* **In-app browsers** — orders uit in-app browsers (Instagram/Facebook-app, enz.) waarbij cookies maar beperkt werken.
* **Cookieloos** — orders zonder traceerbare cookie (zie 'Conversies zonder toestemming versturen' onder Geavanceerde opties hieronder).
* **Niet bereikt** — orders die niet gematcht zijn. Beweeg over dit segment voor een uitsplitsing per oorzaak: **verouderde cookies** (de Prepare-cookie was al verlopen tegen de tijd dat de Trigger arriveerde — te veel tijd tussen checkoutstart en orderbevestiging), of **overig/onduidelijk** (een restcategorie, meestal incidenteel).

Onder de balk zie je het aantal orders zonder toestemming — orders die (deels) niet worden gevolgd in GA4 omdat de bezoeker tracking heeft geweigerd.

Gebruik **Gemiste analyseren** om een analyse uit te voeren op orders die 'niet bereikt' zijn en te zien of probabilistische matching of doorsturen via alleen Trigger (zie Geavanceerde opties) ze had kunnen herstellen.

* Klik op **Details** bij elke rij onder Recente gebeurtenissen om een individuele gebeurtenis te bekijken: bovenaan verschijnen status, bron (transactie-ID) en callbacktijd.
* De **payloadcontrole** markeert datamismatches, zoals "value ≠ som van items" wanneer het ordertotaal niet overeenkomt met de som van de regelitems binnen de tolerantie voor belasting/verzending — dit is een waarschuwing, geen blokkade; de gebeurtenis gaat nog steeds door, maar het is de moeite waard om te controleren of de integratie van de klant de juiste velden verstuurt.
* **Trackingtoestemming** laat zien of toestemming is verleend of geweigerd, samen met de onderliggende Consent Mode-vlaggen (`analytics_storage`, `ad_storage`, `gcs`).
* **Browser** toont de user-agent, handig om patronen te herkennen (bijv. veel 'niet bereikt'-gebeurtenissen vanuit één browser/OS-combinatie).
* **Prepare gebufferd** en **Trigger verwerkt** tonen de exacte tijdstempels van beide gebeurtenissen — de kloof ertussen is van belang bij problemen met verouderde cookies. Verderop vind je vier tabbladen — uitgaande payload, Prepare-data, ordergegevens en raw Trigger-body — handig om precies te zien wat er vóór de verwerking binnenkwam, plus opties om de payload te kopiëren of de gebeurtenis opnieuw af te spelen.

<figure><img src="https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FRAu5x6WmZPeQMJjga7pu%2Fimage.png?alt=media&amp;token=ec3702df-3e82-44df-a399-922b175df4ea" alt=""><figcaption></figcaption></figure>

### Wat zit er in de uitgaande payload

De callback van de Event Notifier naar sGTM bevat een complete payload, klaar voor gebruik over alle grote advertentieplatforms heen. De template stuurt automatisch door:

**GA4 (Measurement Protocol)**

```
event_name:           "purchase"
client_id:            (uit browser of webhook marketing.ga4_client_id)
transaction_id:       (uit order)
value, tax, shipping: (uit order)
currency:             EUR / USD / meer.
items[]:              (complete array met item_id, item_name, price, quantity, item_brand, item_category, enz.)
engagement_time_msec: 100 (standaard)
page_location:        echte bedank-URL (Shopify Web Pixel sandbox-URL's worden automatisch opgeschoond)
gcs, gcd:             Toestemmingsstatus
ip_override:          server-side geocoding
```

**Meta CAPI (Facebook + Instagram)**

{% hint style="warning" %}

### Hoe deduplicatie werkt

Meta dedupliceert de browser Pixel-gebeurtenis en de server-side CAPI-gebeurtenis voor dezelfde aankoop wanneer beide de **zelfde** `event_id` en **zelfde** `event_name` (`Aankoop`). Meta bewaart één gebeurtenis binnen een venster van ongeveer 48 uur en negeert de andere.

De `event_id` is daarom de sleutel. Het moet aan twee vereisten voldoen:

1. **Identiek** in de browser Pixel- en CAPI-gebeurtenis voor dezelfde aankoop.
2. **Uniek per aankoop** — anders kunnen aparte orders onterecht worden samengevoegd.

De enige waarde die aan beide vereisten voldoet is de `transaction_id` **(order-ID)**. Gebruik:

> ⚠️ Gebruik **niet** niet `user_id` als de `event_id`. Die blijft stabiel per klant, niet per order. Een tweede aankoop door dezelfde klant binnen 48 uur zou onterecht als duplicaat worden weggegooid. Gebruik `user_id` als de BasketKey en `external_id`, niet als de deduplicatiesleutel.

> ⚠️ De `event_id` moet **exact dezelfde string zijn** in beide gebeurtenissen. Let op prefixes of verschillen in opmaak. Als de browser `12345` verzendt en de server `order_12345`verzendt, ziet Meta twee afzonderlijke gebeurtenissen en dedupliceert die niet.

> 💡 Zorg ervoor dat de CAPI `event_id` komt uit de **Trigger/order-zijde** (`transaction_id`). Gebruik geen willekeurig `event_id` gegenereerd tijdens de Prepare/`begin_checkout` stap. Het komt nooit overeen met de browser `Aankoop` gebeurtenis.
> {% endhint %}

|              | **Bron**                                                       | `event_id`                   |
| ------------ | -------------------------------------------------------------- | ---------------------------- |
| Browser-side | Meta Pixel `Aankoop` bedankpagina                              | `transaction_id`             |
| Server-side  | AdPage - Meta Conversion API op de Measurement Protocol Client | `transaction_id` uit payload |

```
bp:                  _fbp-cookie (Facebook-browser-ID)
fbc:                  _fbc-cookie (Facebook-click-ID)
em:                   e-mail (SHA256 via FB CAPI-tag)
fn, ln, ph:           voornaam, achternaam, telefoon (ook SHA256)
zp, ct, st, country:  postcode, stad, staat, land
external_id:          customer.id (stabiel over meerdere orders)
client_ip_address:    IP voor IP-matching
client_user_agent:    UA voor browser fingerprinting
event_id:             voor deduplicatie van browserpixel
```

**Google Ads (conversie + remarketing)**

```
_gcl_aw, _gcl_dc, _gcl_gb:  gclid-cookies (ingesteld door Conversion Linker)
FPGCLAW, FPGCLDC:            first-party gclid-varianten
gclid, gbraid, wbraid:        URL-parameters (iOS-appcampagnes)
client_id, ga_session_id:     voor koppeling met page_view-gebeurtenissen
value, currency:              conversiewaarde
```

**TikTok Events API**

```
_ttp, ttp:            TikTok-pixelcookie
ttclid:               TikTok-click-ID (uit URL ?ttclid=)
email, phone_number:  (TikTok gebruikt volledige velden in plaats van FB's afkortingen)
first_name, last_name, city, state, zip_code, country_code: idem
external_id:          customer.id
ip, user_agent:       voor matching
```

**Pinterest Conversions API**

```
_epik, epik:          Pinterest click-ID-cookie + URL-parameter
em, fn, ln, ph, zp:   (dezelfde conversie als FB CAPI)
ct, st, country:      adresvelden
external_id:          customer.id
client_ip_address:    IP
client_user_agent:    UA
```

**Toestemming, over elk platform heen**

```
ad_storage, ad_user_data, ad_personalization, analytics_storage: "granted"/"denied"
consent.ad_storage, consent.ad_user_data, …: eveneens (genest object)
gcs, gcd: Google Consent strings (voor GA4 / Google Ads)
```

### Probleemoplossing

* **"Match identifier value could not be resolved"** — De BasketKey is niet gevonden in de gebeurtenisdata. Controleer de foutlog in de sGTM-console, zoek waar de UUID daadwerkelijk zit in de EventDataSnapshot en stel dat pad in via **Identifier value override** in de tagconfiguratie.<br>
* **Trigger geeft een 308-redirect terug** — De URL eindigt op `/trigger/` en geen waarde. Zelfde hoofdoorzaak als hierboven — controleer de BasketKey-resolutie opnieuw.<br>
* **Trigger geeft een 400 terug** — Bodyvalidatie is mislukt, meestal omdat `transaction_id` of `waarde` leeg is. Bij de AdPage Tagging-plugin (WooCommerce/PrestaShop) staat dit op `ecommerce.transaction_id` — bevestig dat de webhook dit verstuurt.<br>
* **`gemist` status in Event Notifier-logs** — Er kwam een Trigger binnen zonder bijbehorende Prepare. De Prepare aan browserzijde is waarschijnlijk mislukt (adblocker, ITP, of geen browsergebeurtenis vlak voor checkout) — controleer de sGTM-preview op de webshop.<br>
* **`callback_mislukt`** — sGTM ontvangt de callback van de Event Notifier niet. Controleer de callback-URL in AdPage's tenantconfiguratie — meestal een ontbrekende `/data` suffix of het verkeerde subdomein.

### Geavanceerde opties

* **Multi-market-opstellingen** (Shopify Markets of shops met meerdere talen/locaties) — voer alle GA4-property-ID's komma-gescheiden in het veld GA4 Measurement IDs in (bijv. `G-NL123, G-BE456, G-DE789`). Event Notifier stuurt vervolgens de bijbehorende `_ga_<MID>` cookie per property door, zodat sGTM downstream kan routeren.
* **WooCommerce zonder de Tagging-plugin** — voer de exacte `wp_woocommerce_session_<hash>` cookienaam in het WooCommerce-sessiecookieveld in.
* **Aangepaste gebeurtenis-ID's** — kies de Custom-voorinstelling en definieer je eigen identiteitsnaam en variabeleverwijzing.
* **Voorkomen van dubbele identifier** — als een order binnenkomt met zowel een canonieke identifier (bijv. `vtnl-...`) als een kale variant (bijv. alleen het ordernummer), wordt de kale variant genegeerd en gaat alleen de canonieke door.
* **Probabilistische matching** — probeert een anders gemiste order te koppelen aan een recent Prepare-event op basis van items, bedrag, klantidentiteit en timing. Wanneer het vertrouwen hoog genoeg is, wordt de gebeurtenis naar GA4 verzonden met status **Probable** in plaats van **Gematcht**. Standaard uitgeschakeld — alleen inschakelen als je dit vertrouwt voor een bepaalde klant.
* **Doorsturen via alleen Trigger** — stuurt een anders gemiste order (geen Prepare, zelfs niet via probabilistische matching) toch naar GA4, met gebruik van de GA4 `client_id` uit de eigen `ga` cookie van Trigger. Werkt alleen als die client-ID aanwezig is; anders blijft de order gemist. Status wordt **Alleen Trigger**. Standaard uitgeschakeld.
* **Conversies zonder toestemming versturen** — stuurt een order waarbij trackingtoestemming is geweigerd (dus geen GA4 client-ID) als een privacyveilige, cookieloze ping: een wegwerp-client-ID met "denied"-toestemmingsvlaggen en geen PII, zodat GA4 de conversie toch kan modelleren. Status wordt **Zonder toestemming**. Standaard uitgeschakeld — alleen inschakelen nadat je de toestemmingseffecten met de klant hebt besproken, aangezien het data doorstuurt zelfs zonder trackingtoestemming.

### Hulp nodig?

Als de setup van een klant niet past bij iets wat hier wordt behandeld, neem dan contact op met onze support via <support@adpage.io> met de container-ID en een screenshot van de sGTM-consolelog.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.adpage.io/documentation/documentation-nl/optimaliseer-je-setup/webhook-matching.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.