> 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-installatie/webhook-matching.md). # Webhook-matching Zorg ervoor dat de webhook-functionaliteit van AdPage altijd aankoopgebeurtenissen verstuurt naar GA4 en marketingplatforms met de juiste toestemmingssignalen en marketinggegevens ### Wat doet Webhook Matching? Aankoopgebeurtenissen die in de browser afgaan zijn kwetsbaar. Adblockers kunnen ze stoppen, cookiebeperkingen kunnen ze beperken en Safari's ITP kan de gegevens voortijdig afkappen voordat ze je ooit bereiken. 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 terugkomen op je bedankpagina. Ze betalen in hun bankapp, 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 geactiveerd. 2. Bezoekers die wel op de bedankpagina landen, maar te snel weggaan. Je trackingscripts hebben even tijd nodig om te laden en te verzenden. Sluit je tabblad daarvoor, dan sterft de gebeurtenistracking met het tabblad mee. 3. Iemand begint zijn traject in een in-app browser, bijvoorbeeld binnen een LLM-app of een sociale app, en wordt daarna doorgestuurd naar zijn betaalapp. Op de terugweg geeft de betaalapp hem door aan de browser die op zijn telefoon als standaard is ingesteld. Nu zit hij in een totaal andere browser met een andere sessie en geen 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. Het nadeel is dat ze kunnen binnenkomen zonder browsercontext, dus geen `gclid`, geen user-agent en geen items-array. AdPage's Webhook Matching koppelt de browsergegevens en de webhookgegevens met elkaar via een gedeelde matchings-id, voegt de payloads samen en stuurt één gevalideerde gebeurtenis verder stroomafwaarts. Het resultaat: geen dubbele conversies, en ook geen gemiste.
### Webhook Matching instellen Er zijn twee stappen om Webhook Matching in te stellen. **Stap 1** verwerkt de binnenkomende webhook (Trigger) en een begin\_checkout-gebeurtenis (Prepare) om ervoor te zorgen dat die gematcht kunnen worden. Nadat de matchrate hoog genoeg is (>90%) kunnen deze gematchte webhooks worden verzonden naar Google Analytics en je marketingplatforms; dat instellen is **Stap 2**. {% stepper %} {% step %} #### Stap 1: De Webhook Matching-rate 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: 4. Klik op Opslaan. De sjabloon "AdPage Event Notifier" verschijnt nu in de sjablonenlijst 5. Maak twee tags aan met deze sjabloon: **Tag 1 — Prepare (gebeurtenis ontvangen vanaf client-side):** * Modus: `Prepare` * Container-ID: te vinden in de URL van je AdPage-servercontainer\ \ ![](https://2136026570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA65KwL1NwewlJbtCXsXd%2Fuploads%2FyXQZwDv6XjwyRSFU2uoD%2Fimage.png?alt=media\&token=fbb5ae48-6167-4976-b3fb-49b778752b9f)
* Platformvoorinstelling: kies wat van toepassing is (zie hieronder) * Gebeurtenisnaam: `purchase` * Trigger: een browsergebeurtenis vlak voor het voltooien van de checkout (bijv. `begin_checkout`) * Geef het een correcte naam: "AdPage Event Notifier - Prepare"
**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 sleutelpad * 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)) * Geef het een "AdPage Event Notifier - trigger"
**Platformvoorinstelling** De optie voor de platformvoorinstelling is de BasketKey die je wilt gebruiken om de kanten Prepare en Trigger aan elkaar te koppelen; beide moeten dezelfde waarde verzenden, anders matchen ze niet. | Instelling | Voorinstelling | BasketKey | | -------------------------------------------------------------- | ----------------------------- | ---------------------------------------------- | | De client heeft de AdPage Tagging-plug-in/script geïnstalleerd | AdPage Tagging (universeel) ⭐ | `user_id` (van de `trytagging_user_id` cookie) | | Native Shopify (geen Tagging-plug-in) | 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 — die bestaat alleen om Prepare en Trigger aan elkaar te koppelen en heeft niets te maken met GA4's gereserveerde, top-level `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 veld-overschrijving op de MP-client/tag), gaat GA4 het behandelen als een persistente, sessieoverstijgende identiteit, ook al is het dat niet. Onder **Geobserveerd** of **Gemengd** Reporting Identity geeft GA4 User-ID prioriteit boven Client ID bij het bepalen van wiens traject een hit toebehoort. Omdat de doorgestuurde `user_id` bij een webhook-gematchte aankoop meestal niet dezelfde `ga_session_id` heeft als de browsersessie van de bezoeker, kan GA4 de webhook-hit niet langer herkennen als dezelfde bestelling als de client-side hit — in plaats van te worden gededupliceerd op `transaction_id` binnen één identiteit, wordt het geteld als een tweede, afzonderlijke aankoop onder een andere "Effective User ID". \ Stuur alleen `user_id` naar GA4 door als het een echte, stabiele GA4 User-ID is die de client al consistent instelt bij login (client-side, via `gtag('config', ...)`, volgens Google's eigen User-ID-vereisten) — nooit de BasketKey-matchwaarde. {% endhint %} Het resultaat van stap 1 zou zijn:
\ \ \ Publiceer de Google Tag Manager-servercontainer met deze 2 nieuwe tags. De binnenkomende begin\_checkout-gebeurtenissen en webhooks worden automatisch gematcht in je AdPage-servercontainer. Kom na een paar dagen terug om de Webhook Matching-rate te controleren. {% endstep %} {% step %} ### Stap 2: De webhook matching-rate valideren Een paar dagen nadat je stap 1 hebt gepubliceerd, kun je de webhook matching-rate controleren binnen je AdPage-servercontainer.
Als de matchrate boven 90% ligt, kun je doorgaan met stap 3 hieronder. Als de matchrate 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 identifier (fallback)**\ Kies een veld dat in zowel prepare als trigger aanwezig is (`user_id`, `cart_token`). Het is de enige deterministische optie, krijgt voorrang boven de andere en behoudt de normale status Gematcht. Meestal de grootste winst in één keer. **Transactie-ID-prefix**\ Alleen nodig wanneer dezelfde bestelling via twee bronnen met verschillende ID-formaten binnenkomt. Vul de prefix in en vink het selectievakje "negeren" aan zodat het kale duplicaat wordt weggegooid. Laat leeg als er maar één bron is. **Probabilistische matching**\ Standaard uitgeschakeld. Koppelt gemiste bestellingen aan een recente prepare op basis van items, waarde, identiteit en timing. Status wordt Probable. Schakel dit in wanneer er geen fallbackveld beschikbaar is; wees voorzichtig bij shops met veel bijna identieke bestellingen met lage waarde. **Trigger-only**\ Standaard uitgeschakeld. Verstuurt de bestelling op de `_ga` client\_id alleen, zonder een prepare. Herstelt bestellingen waarbij de prepare nooit is afgevuurd. Zwakkere attributie, maar de conversie blijft behouden. Status: Trigger-only. **Conversies zonder toestemming**\ Standaard ingeschakeld, laat het aan. Stuurt een cookieloze, PII-vrije ping voor bestellingen zonder toestemming zodat GA4 ze kan modelleren. Schakel dit alleen uit nadat je het privacybeleid van de klant hebt gecontroleerd. {% endstep %} {% step %} #### Stap 3: De gematchte webhooks gebruiken Om de gematchte webhooks te kunnen gebruiken, moet je een GA4 Measurement Protocol-client aanmaken. De Webhook Matching-callback komt binnen op je sGTM `/mp` endpoint. Daar moet een client aanwezig zijn om het binnenkomende Measurement Protocol-verzoek op te vangen en om te zetten in een gebeurtenis 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 het clienttype **Measurement Protocol (GA4)**, en geef het een herkenbare naam zoals "AdPage MP". Stel **Pad / activering** in op je callback-URL, `/mp`.
2. Blokkeer de aankoopgebeurtenissen in je reguliere GA4-trigger: voeg aan je reguliere GA4-trigger de voorwaarde toe dat 'Event Name' niet gelijk is aan 'purchase'.
3. Voeg een nieuwe Measurement Protocol Client-trigger toe: maak een nieuwe trigger die afgaat op alle binnenkomende verzoeken in je Measurement Protocol Client. Voeg deze trigger na het aanmaken toe aan je Google Analytics 4-tag.
{% endstep %} {% endstepper %} ### Testen en debuggen Voordat je de wijzigingen publiceert die zijn gemaakt voor **Stap 2**, bevestig 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 **Webhook Logs** 2. Zoek een gematchte webhook en open deze door erop te klikken 3. Zoek de **Replay** knop onderaan
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 verzenden**, kopieer de HTTP-header X-Gtm-Server-Preview. 6. Plak de HTTP-header X-Gtm-Server-Preview in het invoerveld voor het opnieuw afspelen van de gematchte webhook 7. De webhook speelt opnieuw af in de previewmodus van Google Tag Manager, zodat je exact kunt zien welke tags afgaan en wat de uitgaande payloads van deze tags zijn.
{% endstep %} {% endstepper %} ### Het Webhook Matching-dashboard lezen Onder **Webhook Matching → Match health**, kun je in één oogopslag zien hoe goed Prepare en Trigger in de geselecteerde periode hebben gematcht (standaard 7 dagen), en waar het misgaat. Het percentage bovenaan is het aandeel van bestellingen dat succesvol is verwerkt — gematcht, afgehandeld via in-app browsers of cookieless — ten opzichte van het totale aantal binnenkomende bestellingen. * **Gematcht** — Prepare en Trigger zijn gekoppeld op de Basket ID. Dit is het gezonde pad. * **In-app browsers** — bestellingen vanuit in-app browsers (Instagram/Facebook-app, enz.) waarbij cookies beperkt werken. * **Cookieless** — bestellingen zonder traceerbare cookie (zie "Conversies zonder toestemming verzenden" onder Geavanceerde opties hieronder). * **Niet bereikt** — bestellingen 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 binnenkwam — te veel tijd tussen het starten van de checkout en de orderbevestiging), of **anders/onduidelijk** (een restcategorie, meestal incidenteel). Onder de balk zie je het aantal bestellingen zonder toestemming — bestellingen die (gedeeltelijk) niet in GA4 worden gevolgd omdat de bezoeker tracking heeft geweigerd. Gebruik **Analyseer gemiste** om een analyse uit te voeren op bestellingen die "niet bereikt" zijn en te zien of probabilistische matching of trigger-only doorsturen (zie Geavanceerde opties) ze had kunnen herstellen. * Klik op **Details** op elke rij onder Recente gebeurtenissen om een individuele gebeurtenis te inspecteren: bovenaan verschijnen de status, bron (transactie-ID) en callbacktijd. * De **payloadcontrole** markeert gegevensverschillen, 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 verzendt. * **Trackingtoestemming** laat zien of toestemming is gegeven of geweigerd, samen met de onderliggende Consent Mode-vlaggen (`analytics_storage`, `ad_storage`, `gcs`). * **Browser** laat de user-agent zien, handig om patronen te ontdekken (bijv. veel "niet bereikt"-gebeurtenissen vanuit één browser/OS-combinatie). * **Prepare gebufferd** en **Trigger verwerkt** laten de exacte tijdstempels van beide gebeurtenissen zien — de kloof ertussen is belangrijk bij problemen met verouderde cookies. Verder naar beneden vind je vier tabbladen — uitgaande payload, Prepare-gegevens, ordergegevens en ruwe Trigger-body — handig om exact te zien wat er binnenkwam vóór verwerking, plus opties om de payload te kopiëren of de gebeurtenis opnieuw af te spelen.
### Wat zit er in de uitgaande payload De callback van Event Notifier naar sGTM bevat een complete payload, klaar voor gebruik op alle grote advertentieplatforms. De sjabloon stuurt automatisch door: **GA4 (Measurement Protocol)** ``` event_name: "purchase" client_id: (van browser of webhook marketing.ga4_client_id) transaction_id: (van bestelling) value, tax, shipping: (van bestelling) 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 geocodering ``` **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 hetzelfde **zelfde** `event_id` en **zelfde** `event_name` (`Purchase`). Meta bewaart één gebeurtenis binnen een venster van ongeveer 48 uur en negeert de andere. De `event_id` is daarom de sleutel. Die moet aan twee eisen voldoen: 1. **Identiek** in de browser Pixel- en CAPI-gebeurtenis voor dezelfde aankoop. 2. **Uniek per aankoop** — anders kunnen afzonderlijke bestellingen onjuist worden samengevoegd. De enige waarde die aan beide eisen voldoet, is de `transaction_id` **(bestellings-ID)**. Gebruik: > ⚠️ Doe **niet** gebruik `user_id` als de `event_id`. Het blijft stabiel per klant, niet per bestelling. Een tweede aankoop van 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 tekenreeks** in beide gebeurtenissen zijn. Let op voor voorvoegsels of opmaakverschillen. Als de browser `12345` en de server verstuurt `order_12345`, ziet Meta twee afzonderlijke gebeurtenissen en dedupliceert die niet. > 💡 Zorg ervoor dat de CAPI `event_id` komt uit de **Trigger-/bestellingszijde** (`transaction_id`). Gebruik geen willekeurig `event_id` gegenereerd tijdens de Prepare/`begin_checkout` stap. Het matcht nooit met de browser `Purchase` gebeurtenis. > {% endhint %} | | **Bron** | `event_id` | | ------------ | -------------------------------------------------------------- | ---------------------------- | | Browser-side | Meta Pixel `Purchase` 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: first_name, last_name, phone (ook SHA256) zp, ct, st, country: postcode, stad, staat, land external_id: customer.id (stabiel over meerdere bestellingen) client_ip_address: IP voor IP-matching client_user_agent: UA voor browserfingerprinting event_id: voor deduplicatie van browser-pixels ``` **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 het koppelen met page_view-gebeurtenissen value, currency: conversiewaarde ``` **TikTok Events API** ``` _ttp, ttp: TikTok pixel-cookie ttclid: TikTok click-ID (van 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: (zelfde conversie als FB CAPI) ct, st, country: adresvelden external_id: customer.id client_ip_address: IP client_user_agent: UA ``` **Toestemming, op elk platform** ``` ad_storage, ad_user_data, ad_personalization, analytics_storage: "granted"/"denied" consent.ad_storage, consent.ad_user_data, …: ook (genest object) gcs, gcd: Google-toestemmingsstrings (voor GA4 / Google Ads) ``` ### Problemen oplossen * **"Match identifier value could not be resolved"** — De BasketKey werd niet gevonden in de gebeurtenisgegevens. Controleer het foutenlogboek 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.
* **Trigger geeft een 308-redirect terug** — De URL eindigt op `/trigger/` en geen waarde. Zelfde hoofdoorzaak als hierboven — controleer de BasketKey-resolutie opnieuw.
* **Trigger geeft een 400 terug** — Validering van de body mislukt, meestal omdat `transaction_id` of `value` leeg is. Met de AdPage Tagging-plug-in (WooCommerce/PrestaShop) staat dit op `ecommerce.transaction_id` — bevestig dat de webhook dit verstuurt.
* **`gemist` status in Event Notifier-logboeken** — Er is een Trigger binnengekomen zonder bijbehorende Prepare. De browser-side Prepare is waarschijnlijk mislukt (adblocker, ITP of geen browsergebeurtenis vlak voor checkout) — controleer de sGTM-preview op de storefront.
* **`callback_failed`** — sGTM ontvangt de callback van Event Notifier niet. Controleer de callback-URL in de tenantconfiguratie van AdPage — meestal een ontbrekende `/data` suffix of het verkeerde subdomein. ### Geavanceerde opties * **Instellingen met meerdere markten** (Shopify Markets of shops met meerdere talen) — voer alle GA4 property-ID's gescheiden door komma's in het veld GA4 Measurement IDs in (bijv. `G-NL123, G-BE456, G-DE789`). De Event Notifier stuurt vervolgens de bijbehorende `_ga_` cookie per property door, zodat sGTM verder kan routeren. * **WooCommerce zonder de Tagging-plug-in** — voer de exacte `wp_woocommerce_session_` cookienaam in het WooCommerce-sessiecookieveld in. * **Aangepaste gebeurtenis-id's** — kies de aangepaste voorinstelling en definieer je eigen identificatienaam en variabeleverwijzing. * **Voorkomen van dubbele identificatoren** — als een bestelling binnenkomt met zowel een canonieke identificator (bijv. `vtnl-...`) en een kale variant (bijv. alleen het bestelnummer), wordt de kale variant genegeerd en gaat alleen de canonieke door. * **Probabilistische matching** — probeert een anders gemiste bestelling te koppelen aan een recent Prepare-gebeuren op basis van items, bedrag, klantidentiteit en timing. Wanneer het vertrouwen hoog genoeg is, wordt het evenement met status naar GA4 verzonden **Waarschijnlijk** in plaats van **Gematcht**. Standaard uitgeschakeld — schakel dit alleen in als je erop vertrouwt voor een bepaalde klant. * **Alleen trigger-doorsturen** — stuurt een anders gemiste bestelling (geen Prepare, zelfs niet via probabilistische matching) toch naar GA4, waarbij de GA4 `client_id` van de eigen `ga` cookie van de Trigger wordt gebruikt. Werkt alleen als die client-ID aanwezig is; anders blijft de bestelling gemist. Status wordt **Trigger-only**. Standaard uitgeschakeld. * **Verzenden van conversies zonder toestemming** — stuurt een bestelling waarbij trackingtoestemming is geweigerd (dus geen GA4 client-ID) door als een privacyveilige, cookieloze ping: een wegwerp-client-ID met toestemmingsvlaggen "geweigerd" en zonder PII, zodat GA4 de conversie toch kan modelleren. Status wordt **Zonder toestemming**. Standaard uitgeschakeld — schakel dit alleen in nadat je de implicaties voor toestemming met de klant hebt besproken, omdat het gegevens doorstuurt zelfs zonder trackingtoestemming. ### Hulp nodig? Als de configuratie van een klant niet past bij iets dat hier wordt behandeld, neem dan contact op met onze support via 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.adpage.io/documentation/documentation-nl/optimaliseer-je-installatie/webhook-matching.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.