|
This article covers the following: |
Overview
Wingify's pre-built integrations connect directly with many of the most common analytics, Content Management System (CMS), and Customer Data Platform (CDP) tools, so most teams can set those up without writing any code. If you use a tool that isn't on the pre-built integrations list, or want to send experiment data to your own internal server, you can do this using the onVariationApplied callback function. This is a small piece of code that Wingify automatically runs on the page each time a campaign is applied to a visitor.
When the callback function executes, it receives an object containing contextual data for the triggering event, including:
- Visitor ID: identifies the visitor
- Campaign details: the applied campaign and its name
- Campaign type: the type of campaign executed
- Variation: the specific variation shown to the visitor
Your team then decides what to do with this data, such as sending it to your server, CRM, or analytics platform in the format that the tool expects.
Note:
- Adding the callback function requires adding a short script to your website, so you may want to involve a developer for this part.
- Occasionally, a campaign may get applied to a visitor before your callback has finished loading on the page. Wingify accounts for this. Rather than missing that event, it holds onto the details and delivers them to your callback as soon as it's ready, so all visitor activity is tracked regardless of page load timing.
Common Use Cases
-
Combining data with an internal data warehouse: Your team may maintain an internal data warehouse and needs to combine experiment data with existing visitor or order records. Sending the data directly to your own server lets you structure it according to your system's requirements, independent of the field mappings or data formats a pre-built integration would otherwise impose.
-
Adding context to customer support tickets: Your team may run a customer support platform and want incoming tickets tagged with the experiment and variation a visitor was exposed to. Sending the data directly to your support tool lets agents see this context without switching to Wingify to look it up.
-
Reporting in a business intelligence tool: Your team may use a business intelligence tool without a pre-built Wingify integration. Sending the data directly to that tool lets you build experiment reports alongside your other business metrics, without exporting data manually.
- Triggering a downstream workflow: Your team may want to trigger a downstream workflow, such as adding a visitor to a specific email or retargeting segment based on the variation they viewed. Sending the data to your own server lets you run that logic immediately, rather than waiting for a batch export.
This article covers the callback function's data structure and how you can add it to your website or campaign.
Prerequisites
- Access to add custom JS to your website.
- A server-side or third-party endpoint ready to receive the data.
Add the Callback to Your Website
Add the callback once at the website level as explained in the following steps, so it automatically captures data for every campaign that runs on your site. This is the recommended approach. With this setup configured, you do not have to remember to add the script separately each time you launch a new campaign, and you get a single, consistent source of experiment data across your site.
The following steps outline how you can add the callback to your website.
Step 1: Open Your Website's Custom JS Section
- Log in to your Wingify account.
- From the left navigation panel, go to Configurations > Websites and Apps > Your Website > Sitewide JS.
Step 2: Add the 'onVariationApplied' Callback
- To implement the JS script sitewide on your website, add the following code, replacing the commented line with the logic to send data to your server. This runs on every page alongside your Wingify SmartCode, independent of any single campaign.
window.VWO = window.VWO || [];
window.VWO.push(['onVariationApplied', function (data) {
if (!data || !data.campId) return;
var payload = {
visitorId: data.visId,
campaignType: data.campType,
campaignId: data.campId,
campaignName: data.campName,
variationId: data.varId,
variationName: data.varName,
targetId: data.targetId,
targetName: data.targetName
};
// Send this payload to your server or tool
fetch('https://your-server.example.com/vwo-events', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payload)
});
}]);window.Wingify = window.Wingify || [];
window.Wingify.push(['onVariationApplied', function (data) {
if (!data || !data.campId) return;
var payload = {
visitorId: data.visId,
campaignType: data.campType,
campaignId: data.campId,
campaignName: data.campName,
variationId: data.varId,
variationName: data.varName,
targetId: data.targetId,
targetName: data.targetName
};
// Send this payload to your server or tool
fetch('https://your-server.example.com/vwo-events', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payload)
});
}]);For the full list of fields available in the callback data object, including field types and behavior notes on consent-gating and event replay, see Variation Applied in our Developer Documentation.
Step 3: Publish and Test
Publish the change, then visit any page where a campaign is running, in preview or as a live visitor, to trigger the callback.
Troubleshooting
| Issue | Possible Cause | Recommended Solution |
| The callback function never fires. | Code was added outside the campaign's Custom JS, or added to a page where the campaign is not running | Confirm the code is in the correct campaign's Custom JS and that the campaign is live on the page you're testing. |
| No network call is visible. | Callback fires, but the fetch/XHR call fails silently | Check the browser console for CORS or network errors, and confirm your server endpoint accepts POST requests from the browser. |
| Data is delayed on the first page load. | Consent gating is enabled on the account. | This is expected. The callback is deferred until the visitor grants consent. |
| Duplicate events on your server. | Callback registered more than once, or added both globally and at the campaign level | Add the callback in a single location and confirm it is not duplicated across SmartCode and campaign-level Custom JS. |
FAQs
-
Will the callback fire more than once per visitor?
The callback function fires once per campaign application per page load. If your account has consent gating enabled, it fires once consent is granted.
-
Does adding the callback slow down my page?
The callback itself is lightweight and runs asynchronously, so it does not block page rendering. Any delay would come from your own code inside the callback, for example, a slow server response, so keep the outgoing request efficient and avoid blocking operations.
-
Can I send data to more than one destination from the same callback?
Yes. Inside the same callback function, you can add multiple fetch or XHR calls, one for each destination, such as your internal server and a third-party analytics tool.
-
What happens if my server endpoint is unavailable when the callback fires?
The request to your server will fail, but this does not affect the visitor's experience or the campaign running on the page. You will simply not receive that particular event, so monitor your endpoint's uptime.
-
Is any personally identifiable information included in the callback data?
No. The callback returns the visitor's Wingify-assigned ID and campaign and variation details, not personal information such as name, email, or contact details.
-
Do I need to remove the callback if I pause or stop a campaign?
No. The callback code can remain on your website even when no campaigns are running. It simply will not fire until a campaign is next applied to a visitor.
Need more help?
For more information or further assistance, contact Wingify Support.