Woopra

Datafly Signal delivers events and visitor traits to Woopra server-to-server using the HTTP Tracking API. Events are sent from your own infrastructure, so they are not affected by ad blockers or browser tracking prevention, and your raw event data never leaves your environment except as the call to Woopra.

Prerequisites

Before configuring Woopra in Signal you need an active Woopra account with a configured project.

Step 1: Find your Project Domain

Sign in to Woopra and select your project.
Go to Settings > Configure Tracking.
Note your Project Domain (for example mywebsite.com). This is exactly the value Signal sends as the project parameter.

Woopra’s HTTP Tracking API authenticates by project domain alone. There is no API key or secret to generate — the project domain is the only credential.

Woopra stitches browser and server events together using its visitor cookie (wooTracker, available in the browser as window.woopra.cookie). Signal captures this cookie as vendor_ids.woopra_cookie and forwards it on every server-side call so events land on the same visitor profile. Without it, Signal falls back to identifying visitors by email/name traits.

Configure in Signal

Configuration Fields

Field	Required	Description
`project`	Yes	Your Woopra project domain (e.g. `mywebsite.com`), exactly as shown under Settings > Configure Tracking.
`timeout`	No	Session idle timeout in milliseconds. Defaults to `1800000` (30 minutes) to match Woopra’s browser tracker.

Management UI Setup

Add the integration

Go to Integrations > Add Integration > Woopra.

Enter your project domain

Enter your project domain and, optionally, a custom timeout.

Select the consent categories that should gate analytics delivery (typically analytics).

Save

Click Save. Signal begins delivering events to Woopra on the next matching event.

API Endpoint

GET https://www.woopra.com/track/ce/?project={project}&event={event_name}&cookie={visitor_cookie}&...

Visitor-only trait updates (no event) use the identify variant:

GET https://www.woopra.com/track/identify/?project={project}&cookie={visitor_cookie}&cv_email=...

Woopra responds with a 2xx immediately: 200 (processed) or 202 (queued under load). A 4xx indicates a malformed request or an unknown project.

Identity Signals

Woopra uses these identity signals, sent automatically by Signal where available:

Signal	Parameter	Description
Visitor cookie	`cookie`	The Woopra `wooTracker` cookie, captured as `vendor_ids.woopra_cookie`. The primary key that stitches browser and server events to one profile. Sent unprefixed.
Email	`cv_email`	Visitor email, set from `datafly.identify()` traits. Also a merge key when no cookie is present.
Name	`cv_name`	Visitor display name from identify traits.
User ID	`cv_id`	Your stable user identifier, set on the Woopra profile.
IP address	`ip`	Visitor IP, forwarded from the original request so Woopra resolves geo correctly (not the Signal egress IP).
User-Agent	`User-Agent` header	Visitor User-Agent, forwarded so Woopra attributes device and browser correctly.

Woopra namespaces its parameters by type: custom event properties are prefixed ce_, custom visitor properties are prefixed cv_, and the cookie is sent unprefixed. Signal’s Woopra blueprint already applies these prefixes — you map your normal Signal fields and Signal emits the correct Woopra parameter names.

How to send visitor data

Call datafly.identify() when a visitor logs in, registers, or submits a form:

datafly.identify("user-123", {
  email: "jane.doe@example.com",
  name: "Jane Doe",
  company: "Acme Ltd"
});

Signal forwards these as cv_email, cv_name, and cv_company on subsequent Woopra calls.

Event Mapping

Default preset

Signal event	Woopra event
`page`	`pv`
`Signed Up`	`signup`
`Logged In`	`login`
`Products Searched`	`search`
`Product Viewed`	`product_viewed`
`Plan Viewed`	`plan_viewed`
`Product Added`	`add_to_cart`
`Checkout Started`	`checkout_started`
`Order Completed`	`purchase`
`Subscription Started`	`subscription_started`
`Lead Generated`	`lead`

To customise, edit the integration’s Field Mappings in the Management UI.

Example: Purchase event

Datafly.js call:

datafly.track("Order Completed", {
  order_id: "ORD-001",
  revenue: 149.95,
  currency: "USD",
  coupon: "WELCOME10"
});

Woopra request sent by Signal:

GET https://www.woopra.com/track/ce/
  ?project=mywebsite.com
  &response=json
  &timeout=1800000
  &ce_app=datafly-signal
  &event=purchase
  &cookie=AH47DHS5SF182DIQZJD
  &ip=203.0.113.50
  &cv_email=jane.doe@example.com
  &cv_name=Jane+Doe
  &ce_order_id=ORD-001
  &ce_amount=149.95
  &ce_currency=USD
  &ce_coupon=WELCOME10

(The visitor User-Agent travels on the User-Agent HTTP header.)

Testing

Trigger an event

Trigger a tracked action (e.g. a purchase) on your site, or replay one through Signal’s event debugger.

Check the response

Signal logs Woopra’s response. A 200 (processed) or 202 (queued) means the request was accepted.

Verify in Woopra

In Woopra, open People / Profiles and find the visitor (by cookie or email). The new event appears on their timeline, and any cv_* traits appear on their profile.

Troubleshooting

Problem	Solution
Events not appearing	Confirm the `project` domain matches exactly what Woopra shows under Settings > Configure Tracking. A mismatched domain silently drops events.
Events land on the wrong visitor	Ensure the Woopra cookie is captured (`vendor_ids.woopra_cookie`). Without it, events merge on `cv_email`/`cv_name`, or create a new anonymous profile.
Geo shows your server location	Confirm the `ip` parameter is the visitor IP, not the Signal egress IP. Signal forwards the original request IP automatically.
Custom properties missing	Event properties must be `ce_`-prefixed and visitor properties `cv_`-prefixed. The blueprint applies these; if you added custom mappings, prefix the targets correctly.
`202` responses	This is normal under load — the request was queued and will be processed. No retry needed.

Statsig Kissmetrics