Skip to main content
This guide covers the most common WordPress integration: browser tracking via the theme <head> or Google Tag Manager, plus server events fired from WooCommerce’s order completion hooks. For the full server-event field reference, deduplication behaviour, and error codes, see Server-Side Events.

Browser tracking

Method 1 — Paste the snippet in your theme

Add the tracking snippet to the <head> of every page. The safest place is your child theme’s functions.php via wp_head:
Replace acct_a1b2c3d4 with your workspace ID — copy it from the Site ID card under Settings → Workspace → Settings & Integrations, or from the full snippet on the Tracking tab. Always copy the ID from the dashboard rather than retyping it. Use a child theme so the snippet survives parent-theme updates. Alternatively, use a plugin that injects code into <head> (e.g. WPCode).

Method 2 — Google Tag Manager Custom HTML tag

If your site is managed through GTM:
  1. Create a new Custom HTML tag in GTM.
  2. Paste the snippet into the HTML field.
  3. Set the trigger to All Pages.
  4. Publish the container.
GTM can strip data-* attributes. If the Support document.write option is disabled on your Custom HTML tag (the default), GTM may remove the data-site attribute before injecting the script. Without data-site, the snippet does not know which workspace to report to and sends no data.Fix: Open the Custom HTML tag settings and enable Support document.write — this preserves the full script tag including data-site.

Server events

WooCommerce order completion hook

Send a conversion event when WooCommerce confirms payment. Add this to your child theme’s functions.php or to a site-specific plugin:
At least one of anonymous_id, contact_id, or hashed_email is required. For guest checkouts, contact_id may be empty — hashed_email alone is sufficient. Include both when available for stronger identity matching.
subdomain is required when calling api-v2.davazmysel.com directly. If you have configured a custom domain in Dáva (your own hostname registered in Domain Settings), omit subdomain. See Sending a single event for details.
event_id and transaction_id are dedup keys — see Deduplication for the full priority chain. Use properties for any additional domain-specific facts (e.g. properties.sku, properties.plan). woocommerce_payment_complete fires once payment is confirmed by the payment gateway. If you also need to fire on manual order status changes, use woocommerce_order_status_completed:
A hybrid setup links the server conversion event to the visitor’s browser journey, attributing the purchase to the campaign that brought them in rather than storing it as an unmatched server event. The flow:
  1. Your checkout page loads the Dáva snippet, which creates a browser session.
  2. Your checkout page JavaScript reads the session ID: window.dava.sessionId
  3. JavaScript writes the value into a hidden form field that posts with the checkout form.
  4. PHP reads the value from $_POST and saves it to the WooCommerce order as custom meta.
  5. The woocommerce_payment_complete hook reads the meta and includes it as dava_session_id in the server event.
Step 1 — Inject the session ID into the checkout form (JavaScript):
Step 2 — Add the hidden field to the WooCommerce checkout form (PHP):
Step 3 — Save the value to order meta when the order is created (PHP):
The woocommerce_payment_complete hook then reads _dava_session_id from the order meta (as shown in the Server events section above) and passes it as dava_session_id in the event payload.
PHP cannot read window.dava.sessionId directly — that is a browser object. Your frontend JavaScript must collect it and pass it to PHP explicitly via a form field, cookie, or AJAX request. The PHP hook reads it from wherever the frontend placed it.
For more on journey joining and what happens when the session ID does not match, see Joining the visitor’s journey.

Next steps