Resource Center

Tracking FAQs : Server to Server (S2S)


This article will review:

  • Frequently asked questions (FAQs) for Server to Server (S2S) integrations


Index


Overview

This guide will cover the most common FAQs for S2S integrations.


Frequently Asked Questions

Below are answers to the most commonly asked questions regarding the implementation of the S2S integrations.

Q1 - Is the clickref value case sensitive?

Yes, the clickref value we pass through at the point of click must be an exact match to the value passed through at the point of sale within the clickref pixel. This can include uppercase and lowercase values so this must be configured to pick up the exact clickref we generate and pass through.

Q - Why is the S2S tracking not firing?

A - There are several technical factors to verify if your server-to-server (S2S) calls are not registering conversions. Follow these troubleshooting steps to ensure your integration is functional:

Verify the trigger point 

The S2S conversion call must be configured to trigger exactly when a user reaches the confirmation or "thank you" page of the brand website. At this point of purchase, the brand server must send all valid transactional data to Partnerize. If the call is set to trigger at an earlier stage of the checkout process, the conversion may not record correctly.

Confirm live production environment integration

During the integration phase, Partnerize provides a test partner tracking link. This link redirects to the destination URL, which is typically the live production site. If tracking is not firing, confirm that the S2S setup has been fully deployed to your live environment.


❗ NOTE : While testing in a staging or sandbox environment is permitted during initial setup, a successful test must be performed on the live production environment before the campaign can be cleared to go live from a technical perspective.


Q3 - Why is the Clickref blank when the S2S is triggered?

The brand campaign must be configured within Partnerize to pass through the clickref value at the point of click. This can be actioned by Partnerize so please reach out if you require this amendment.

All traffic generated by Partnerize publishers will arrive at the brand's site with a unique 'clickref' parameter appended to the URL. The 'clickref' is an alphanumeric value, which identifies a Partnerize click and all information associated with the click. The brand must capture the value of the 'clickref' parameter, and always store the most recent value in a 1st party cookie on the user’s browser. If the S2S is firing but the clickref parameter is coming through blank, ensure that this data parameter is mapped to pull through the clickref value stored from within the 1st party cookie/local storage.

Q4 - Does S2S tracking work with 3rd party containers/systems?

S2S tracking involves a direct, secure HTTP call, via POST or GET, to the Partnerize tracking API, meaning that the S2S tracking must be configured within the brands server to act as a "true" S2S call. We do have a number of brands that use 3rd party systems such as Tealium to manage the S2S tracking, although this is configured slightly different via Postbacks. If unsure, please reach out to your 3rd party provider for further support.

Q5 - I am receiving a 400 server error when triggering the S2S tracking

This can potentially occur when the S2S conversion call is not decoding correctly. We suggest reviewing the S2S data and ensure that each value can decode successfully. If unsure, please reach out to Partnerize and we will assist further.

Q6 - The S2S tracking is firing but not tracking within Partnerize?

The clickref is essential for the conversion to track in Partnerize. The most recent clickref we generate and pass through in the URL must be captured, stored and passed through in the S2S tracking at the point of sale. This clickref value must be an exact match from the POC to the POS for the event to track in Partnerize. As mentioned in Q1, ensure the clickref is case sensitive as the value must be an exact match.

Q7: How does S2S tracking respect user "Opt-Out" or "Do Not Track" (DNT) signals? 

Because S2S happens behind the scenes, the platform cannot "see" the user's browser settings. Developers must capture the user’s consent state (e.g., via a Cookie Consent banner) on the front-end, pass that state to the backend, and only trigger the S2S call if the user has opted in. Many APIs have a limited_data_use or consent parameter that must be toggled based on the user's choice.

Q8: How can a developer troubleshoot an API error stating that an attribute contains additional properties? 

This validation error typically occurs during bulk conversion updates when metadata fields are passed at the incorrect hierarchical level of the JSON payload. Developers must ensure that custom parameters are nested within a defined metadata array rather than passed as root properties of the conversion or conversion item object.

Q9: What causes missing "device" and "context" data in server-to-server reporting? 

S2S calls do not automatically provide User Agent strings because the request is triggered by a server rather than a browser. Consequently, device types such as "desktop" or "tablet" will be absent from reports unless the brand explicitly maps this context from the user's session and includes it as a parameter in the S2S conversion call payload.

Q10: How can developers verify click identifier capture if browser JavaScript cannot access the cookie? 

In secure server-side environments, cookies may be set with httpOnly and Secure flags, preventing visibility in the browser's console. Verification must be performed by inspecting the outgoing server-side API call to ensure the backend is correctly retrieving the identifier from the incoming HTTP request and including it in the outgoing S2S conversion call.

Q11: What should be investigated if the tracking platform receives two conversion calls for a single transaction? 

This "double tag" issue typically occurs when a new S2S implementation is active alongside a legacy client-side pixel or tag manager setup. If the standard pixel fires before the S2S call, the platform may prioritize the pixel data and ignore the S2S request as a duplicate. To resolve this, legacy front-end tracking must be disabled once the S2S solution is verified as stable.


Questions

If you have any technical questions regarding this document, please get in touch with our Integration team at integrations.support@partnerize.com   

 

 

 

 

Was this article helpful?

6 out of 8 found this helpful

Have more questions? Submit a request