--- title: "Settings and delivery — Egenverk Conversion Relay" description: "What each Conversion Relay setting does, how the validation test works and how to read the delivery status of purchases." canonical: https://egenverk.se/en/plugins/conversion-relay/docs/settings lang: en updated: 2026-10-14 alternate: https://egenverk.se/plugins/conversion-relay/docs/installningar.md --- # Settings and delivery Egenverk Conversion Relay · v1.7.0 · WordPress 6.5+, WooCommerce 8.2+, PHP 7.4+ · Updated 2026-10-14 Everything is under WooCommerce → Settings → Conversion Relay, in three tabs: **Settings**, **Validation & log** and **Delivery status**. The page requires permission to manage WooCommerce. The chip in the page header shows the current mode, **Validation** or **Production**. ## Settings The tab has its own **Save settings** button at the bottom. An invalid Pixel ID or API key does not stop the rest: that field keeps its old value, the other fields are saved and a message says what was not saved. ### Measurement | Setting | Default | What it does | | --- | --- | --- | | **Enable measurement (master switch)** | Off | Switches the whole plugin on. While it is off, no script is loaded in the store and no new purchases are captured or sent. | | **Mode** | **Validation** | In **Validation**, purchases are sent to the API, which checks them without recording them, and the browser pixel is off. In **Production**, they are recorded in Ads Manager. | | **Enable browser pixel** | Off | Loads OpenAI's pixel. Used in **Production** only. | | **Enable Conversions API** | Off | Sends purchases from the server. | Measurement only runs when the master switch is on, a Pixel ID is saved and a consent adapter is selected. Purchases also need **Enable Conversions API**. The purchase is never sent from the browser, only from the server. Purchases already in the queue wait while the master switch or the Conversions API is off, and are sent once you switch it back on if they are still less than seven days old. If you change **Mode** or **Pixel ID** after purchases were queued, those purchases are paused. They are never sent with the new settings. ### Connection & consent - You get the **Pixel ID** in Ads Manager. It may contain only letters, digits, hyphens and underscores, at most 128 characters. - You also get the **API key** in Ads Manager. A saved key is shown masked. Leave the field blank to keep it. The **Show API key** button reveals it to administrators only, and a key from `wp-config.php` or an environment variable is never shown. The key must not contain spaces or control characters. It is stored encrypted with AES-256-GCM, and if the server has no encryption it is not saved at all: set it on the server instead. - **Consent adapter** is **Not configured** by default. Choose **Cookiebot** or **WP Consent API**. While the WP Consent API plugin is inactive, the option reads **WP Consent API (plugin not active)** and cannot be selected, unless it is already the saved choice. With Cookiebot, the visitor must have answered and accepted marketing. With the WP Consent API, the marketing category is used, and the banner must declare its consent type (opt-in or opt-out). If no banner has, consent counts as unknown. Unknown or denied consent stops measurement. When a visitor withdraws consent, the pixel is switched off at once and purchases from that session that have not been sent yet are stopped. If the master switch is on but no consent adapter is selected, the Plugins screen and the plugin's own tab show the notice **Conversion Relay is not measuring. Choose a consent integration under WooCommerce → Settings → Conversion Relay.** ### Optional matching signals Three switches, all off by default. They help Ads Manager match a purchase to an ad click when the click identifier did not survive the whole journey, and are sent only with marketing consent. - **Include SHA-256 email for server matching**: the billing email, trimmed, lowercased and hashed. The raw email is never sent. - **Include IP address and user agent for server matching**. - **Include billing country, city, region and postal code for server matching**. The IP address, user agent and location are sent as raw values, as the API documents them. Cover them in your privacy policy before switching them on. A value that does not have the right shape is left out. The signals are read from the order when the purchase is queued and stored encrypted with the event. The pixel's own automatic advanced matching is controlled in Ads Manager, not here. ### Browser events Four switches, all on by default. They apply only while the browser pixel is on. | Switch | Event | | --- | --- | | **Page views** | `page_viewed` | | **Product views** | `contents_viewed` | | **Add to cart** | `items_added` | | **Checkout started** | `checkout_started` | ### Logging **Log level** is **Errors + warnings** by default. The other choices are **Errors only (always enabled)**, **Info + warnings + errors** and **Debug + all other levels**. Info adds event activity and purchase state changes, debug also consent steps and API requests. The log goes to the WooCommerce log, see [Troubleshooting](troubleshooting). ### Advanced settings - **Delete saved API key (server configuration still takes precedence)** removes the saved key when you save. A key on the server is not affected. - **Delete plugin tables and settings on uninstall** is off by default. See [Data and privacy](data-and-privacy). ### Configuration status The panel next to the form shows the state of **Measurement**, **Pixel ID**, **API key**, **Consent adapter**, Action Scheduler and **Database locks**. It is based on the saved settings and does not verify the connection. **Database locks** must be **Available** for purchases to be queued. ### Page cache Pages carry the settings they were rendered with. Purge the page cache after changing anything, or cached pages keep the old settings. ## Validation & log - **Test your connection**: **Validate synthetic API event** sends one invented test purchase in validation mode, with no customer data at all. The button cannot be pressed until a Pixel ID and API key are configured. The test works even while measurement is off and never changes an order's delivery status. - The result is **Validation confirmed**, **API responded · validation unconfirmed** or **Validation could not be completed**. Unconfirmed means the API answered without an acknowledgement that could be verified. None of them proves that purchases are attributed to ads. - **Before production** reminds you to place a test order with each payment method before switching to **Production**. - **Event log** has the **Open the log** button, which opens the WooCommerce log with the source `egenverk-conversion-relay`. - **Validation log** lists the latest 100 tests with time (UTC), status and error code, without keys and without contents. If the latest attempt to queue a purchase failed, a warning appears here. It clears when the next purchase is queued. ## Delivery status The tab shows the number of purchases per status and the latest 50 purchases with **Order**, **Mode**, **Status**, **Attempts** and **Error code**. The queue is also listed under WooCommerce → Status → Scheduled Actions, group `egenverk-conversion-relay`. ### Statuses | Status | Meaning | | --- | --- | | **Pending** | Queued, not sent yet. | | **Sending** | An attempt is in progress. | | **Retrying** | An attempt failed temporarily and a new one is scheduled. | | `validated` | The API acknowledged the purchase in Validation mode. | | **Accepted** | The API acknowledged the purchase in Production. | | **Unconfirmed** | The API answered without an acknowledgement that could be verified. Not retried automatically. | | **Failed** | An error response that cannot be retried, eight attempts used, the seven-day limit reached or the key missing. | | **Paused** | **Mode** or **Pixel ID** changed after the purchase was queued. | | **Suppressed** | Consent no longer holds, the order is no longer paid (for example cancelled) or it was refunded in full or in part. | | **Expired** | The purchase could not be sent within seven days. | ### When a purchase counts - When the payment is confirmed or the order reaches Processing or Completed, whichever comes first. Cash on delivery, bank transfer and orders marked paid by hand therefore count too. - An order that was only created, is on hold or whose payment is not confirmed does not count. Subscription renewals do not count. - The order must have been placed with marketing consent, and the payment must not happen in a request where consent was refused. Consent given only after payment does not count. - Each order is sent once, even when the payment is reported twice. ### Delivery and retries Purchases are sent in the background with Action Scheduler, so checkout never waits. Network errors, timeouts, rate limits and server errors at the receiving end are retried with increasing delays. Other error responses give **Failed** at once. A purchase gets at most eight attempts and is never sent once it is older than seven days. **Retry** is offered for **Failed**, **Unconfirmed** and **Paused**. It works as long as the purchase has attempts left and is less than seven days old. A retry never changes the mode, Pixel ID, contents, ID, original time or consent requirement. A paused purchase is paused again if the setting still differs, so restore it first. Refunds after the purchase was sent are not reported. Events already sent cannot be recalled. ### Deactivate and reactivate Deactivating the plugin removes its scheduled jobs. Reactivating it resumes purchases that are still eligible, with the same consent, mode and age limit as when they were queued. ## Resources - [Product page](https://egenverk.se/en/plugins/conversion-relay) - [Changelog](https://egenverk.se/en/plugins/conversion-relay/changelog) - [Docs](https://egenverk.se/en/plugins/conversion-relay/docs) - Previous: [Getting started](https://egenverk.se/en/plugins/conversion-relay/docs/getting-started) - Next: [Data and privacy](https://egenverk.se/en/plugins/conversion-relay/docs/data-and-privacy)