The Partner Configuration page is where you configure the Singular tracker to work with your various ad networks and other partners. If you're just getting started, see How to Configure Partner Settings and Postbacks.
Note: This guide is for Singular customers. If you are a Singular partner or want to become one, see Information for Partners instead.
Troubleshooting
If a partner network says they are not receiving postbacks for installs/conversions or in-app events:
- Go to Attribution > Export Logs and download the postbacks logs for the partner. For help downloading logs, see the Export Logs and User-Level Data FAQ.
- Make sure to filter the postbacks with Response HTTP Code = 200. If the Response HTTP Code is "200", it means that the partner confirmed that they received the postback.
- Also select the field Response HTTP Body as it may help pinpoint a tech issue at the partner's end.
- Share the log with the partner to validate the data internally. If there are many postbacks with other response codes, inform them that there might be a technical issue with them receiving postbacks from Singular.
- Note: in the Partner Configuration page, under Advanced Settings, it's possible to restrict the data sent to the partner and not send postbacks if the Limit Data Sharing (LDS) value is true. In this case, any install or event will not be sent to the partner if LDS = true in the device's first session.
- On Singular's UI page, partners do not have access to postbacks from installs and events that have Limit Data Sharing (LDS) set to true in the device's first session/attribution, even if there are no restrictions in the Partner Configuration. In this case, the postbacks for devices with LDS = true will be sent to the partner, but any partner with access to the client data will not have access to these specific postbacks on Singular's Export Logs page, as they will be disregarded in the query. In such scenario, the real number of postbacks sent to the partner needs to be checked in the customer account.
If the ad network partner is setup to receive all instances of install or in-app events, and you have selected to "send all" events to the partner, the postback configuration will continue to send postbacks to them. You will have to delete the postback or uncheck the "send all" boxes within the Partner Configuration in order to stop sending this data. See Receiving all Installs definition within Singular's Glossary.
Some possible reasons are:
- Lookback windows: One or more events may have a different lookback window configured for postbacks. Check the settings in the Partner Configuration page.
- Technical issues: The partner may not have received one or more postbacks due to technical issues on the partner's end. To check, see Why is my network partner not receiving postbacks?
- Duplicate events: The Singular SDK in your app auto-generates an event called __REVENUE__, which is triggered on any in-app purchase. In addition, you can also create your own SDK revenue events for different types of in-app purchases. When you configure event postbacks, make sure to send postbacks either for __REVENUE__ or for your custom-named revenue event(s) - but not both. Otherwise, Singular will send two postbacks for each in-app purchase.
If a network partner says they are receiving postbacks without event attributes:
- Go to Attribution > Export Logs and download the postbacks logs for the partner. Check the postback HTTP Body or Target URL fields to see if they include event attributes. For help downloading logs, see the Export Logs and User-Level Data FAQ.
- If the logs show that postbacks are indeed being sent without event attributes, double-check the postback settings in the Partner Configuration page. If you have not configured added attributes to be sent along with events, change the settings now.
- If the settings are correct and postbacks are still being sent with missing attributes, contact Singular support.
If your billing with a network is based on the number of install/event postbacks that Singular has sent to them during the period, you can double-check what postbacks were sent to a partner by downloading raw postback logs at Attribution > Export Logs.
For general help with the Export Logs page, see the Export Logs and User-Level Data FAQ.
For postback validation, we recommend downloading a log with the following settings:
Be sure to filter for the value "200" in Response HTTP Code to see the postbacks successfully received by the Postback Recipient.
Don't get confused between the Partner and Postback Recipient fields:
- Partner is the network to which the event was attributed.
- Postback Recipient is the partner that received the postback for the event. The event is not necessarily attributed to that partner (remember, some partners ask to receive postbacks on all of your events, whether they are attributed to that partner or another network, and you can enable that option in the Partner Configuration page).
An additional field, Is Attributed, further clarifies whether the postback recipient is the network to which the event was attributed ("Y" means it's the same network, "N" means the event was attributed to another partner which you can see in the Partner field).
Note: The Partners filter will filter the postbacks by the name of the partner who received the postbacks - whether it was a partner network, your internal BI, third-party analytics tools, etc.
For other log types, the Partners filter means the partner to whom a conversion or an event was attributed (ad networks).
FAQ
Partner Configuration FAQ
Singular sends every partner network a postback when an app install is attributed to that network. You cannot disable these postbacks.
Other types of postbacks are optional and depend on the preferences of the partner network:
- Re-engagement postbacks
- In-app event postbacks
- Postbacks about conversions (installs/re-engagements) and events that are not attributed to the partner
- Singular retries sending a postback if we receive an HTTPS response code between 500 and 559.
- The mechanism has a maximum of 5 retries.
- Retries are in intervals of 1, 5, 15, 30, and 60 minutes from the original attempt.
You can track configuration modifications through a UI Export or via our API.
Note: Tracking began on February 4th, 2026. Data prior to this date is unavailable.
How to Export via the UI:
Access the change history directly from the Partner Configuration screen:
- Go to Attribution Setup Partner Configuration.
- Locate the relevant partner row in the summary table.
- Hover over the row to reveal the action icons on the right.
- Click the "Export Changes History" icon to download a CSV file.
Understanding the Export :
Columns The CSV export includes these specific data points:
-
Partner Identifiers:
Details identifying the setup, including Partner, App, Bundle ID, Site Public ID, Platform, and Agency. -
Date:
The exact timestamp of the update. -
Category + Field Name:
The specific setting group and parameter modified -
Old Value:
The setting before the update ("N/A" for new entries). -
New Value:
The value of the setting after the change was applied. -
Performer:
The email address of the user who made the change. Updates by Singular are marked as "Singular". -
Operation:
Describes the action taken on the partner configuration, such as "Update", "Delete" or "Create".
Accessing History via API:
For automated auditing or internal tool integration, use our Changes Log API to fetch history programmatically.
You can generate this report directly from the Partner Configuration page of your dashboard.
- To export a single partner: Navigate to that partner's page and click the Export Configuration button.
- To export everything: Use the Export All Configurations option to receive a full list of all active partner setups.
This downloads a CSV file with information about each postback that has been configured.
Notes:
- Each row in the CSV file represents one postback configured for the partner.
- New fields are available in the exported file as of Jan 2026.
| Column | Description |
| Partner | The name of the partner |
| App | The display name of the app |
| bundle ID | The long name or bundle ID of the app |
| Site Public ID | The app's ID in the Apple App Store or Google Play, or the website URL for websites. |
| Platform | The Platform of the app (iOS/Android/web/PC/Nintendo etc) |
| Agency | The name of the configuring agency (if relevant) |
| Install Click Window Deterministic | [FIELD NAME CHANGED: FORMERLY "Click-through attribution lookback window"] The install attribution window for clicks with a strong device/user identifier. |
| Install Click Window Probabilistic | [NEW FIELD] The install attribution window for clicks without a strong device/user identifier. |
| Install View Window Deterministic | [NEW FIELD] The install attribution window for impressions with a strong device/user identifier. |
| Install View Window Probabilistic | [NEW FIELD] The install attribution window for impressions without a strong device/user identifier. |
| Reeng Click Window Deterministic | [NEW FIELD] The reengagment attribution window for clicks with a strong device/user identifier. |
| Reeng Click Window Probabilistic | [NEW FIELD] The reengagment attribution window for clicks without a strong device/user identifier. |
| Reeng View Window Deterministic | [NEW FIELD] The reengagment attribution window for impressions with a strong device/user identifier. |
| Reeng View Window Probabilistic | [NEW FIELD] The reengagment attribution window for impressions without a strong device/user identifier. |
| Reeng Inactivity Window | [NEW FIELD] Required period of user inactivity to allow re-engagement attribution. |
| Ctv View Probabilistic Window | [NEW FIELD] The install & reengagment attribution window for CTV impressions. |
| Ctv Prioritization Window | [NEW FIELD] time from CTV touchpoint to prioritize the CTV touchpoint as deterministic click. |
| Limited Data Sharing restriction Type | [FIELD NAME CHANGED: FORMERLY "Limited Data Sharing Restriction"] True/False (this field is only available if the limited data sharing feature has been enabled for this Singular customer). |
| Limited Data Sharing Default Value | [FIELD NAME CHANGED: FORMERLY "Limited Data Sharing Default"] True/False (this field is only available if the limited data sharing feature has been enabled for this Singular customer). |
| Country Limitation Values | [FIELD NAME CHANGED: FORMERLY "Country Limitation"] Comma-separated list of country names (full names, not country codes) (this field is only available if the relevant feature has been enabled for this Singular customer). |
| Country Limitation Type | "Include" or "Exclude" (this field is only available if the relevant feature has been enabled for this Singular customer). |
|
Event Name |
[FIELD NAME CHANGED: FORMERLY "Event SDK Name"] If the postback described in this row is for an event: the Singular SDK name of the event, if it is for an install or reengagment: Install or Reengagement. |
| Event Type | [FIELD NAME CHANGED: FORMERLY "Postback Type"] Whether the specific postback described in this row is for an install, reengagment, revenue event or an event (custom). |
| Send All | [FORMERLY "Attributed Only"] True if the postback was configured to be sent regardless of attributed source, False if it was configured to be send only if it is attributed to the partner. |
| Send View Through | [NEW FIELD] True if the postbacks was configured to be sent for view though attribution. |
| Postback URI | [FIELD NAME CHANGED: FORMERLY "Postback URL"] The full URi of the postback, including Singular macros. |
| URI Manually Customized | [FIELD NAME CHANGED: FORMERLY "Is Postback URL customized"] TRUE if the user toggled to manually edit the postback URI. FALSE if the postback remain as default Singular-partner postback URI |
| Send Revenue | [NEW FIELD] True means Singular will share the event revenue details with the partner (only relevant for revenue events). |
| Event Lookback Type | Lookback window options: • Touchpoint: Time frame starts from the ad click/view to which the install was attributed. • Install: Time frame starts from the install. • None: No time limit on event postbacks. |
| Event Lookback Window | A lookback window to limit the event postbacks to a specified time frame according to the event lookback type, in days. |
| Send Fraud | [NEW FIELD] True means Singular will send postbacks to the partner for rejected touchpoints. |
| Postback Filters | [NEW FIELD] Specific filters applied to the postback trigger (this field is only available if the relevant feature has been enabled for this Singular customer). |
|
Tracker Name Filter |
The filter name or "None" |
| Updated | [FIELD NAME CHANGED: FORMERLY "Last Update Date"] Last update date for the configuration |
| Performer | [NEW FIELD] The user or system that performed the last update. |
| Accounts | [NEW FIELD] The OAuth accounts associated with this partner (only relevant to partners that require oAuth). |
| Event Parameter 1 Name | [NEW FIELD] partner specific event parameter name (for Example "Facebook event name") |
| Event Parameter 1 Value | [FIELD NAME CHANGED: FORMERLY "Event Partner Name"] partner specific event parameter value (for example "add to cart") |
| Partner Parameter 1 Name | [NEW FIELD] partner specific app level parameter name. |
| Partner Parameter 1 Value | [NEW FIELD] partner specific app level parameter value. |
Understanding "N/A" vs. "None"
To ensure data accuracy, we distinguish between configurations that are missing and those that are not applicable:
None: The configuration is available for this event type, but it has not been set up (it is empty in the UI).
N/A: The configuration is not applicable to this specific line item. For example, Event Lookback Window will show as N/A for "Install" postbacks.
Windows exception: attribution windows will show the default windows values even when they are not relevant.
Partner Types and Terminology
The partners in the Partner Configuration page are all the networks and services you configure to work with Singular's attribution service.
Note: This is not where you tell Singular which sources to pull campaign data from to present the data in Singular reports. For that, you need to set up ad networks and other media sources separately in the Data Connectors page (see the Data Connectors FAQ).
The Partner Configuration page lets you configure the following things per partner and site:
- The lookback window for click-through attribution
- Which postbacks to send to the partner
- This is also where you enter your login credentials to the partner's platform, if Singular needs them to connect to the partner. This varies from partner to partner.
For more details, see Configuring Settings and Postbacks below.
- Some partners are ad networks, ad agencies, etc. You configure attribution settings for these partners, and then you create tracking links that incorporate the partners' custom macros. You can also have Singular send these partners information about attributed installs, fraud decisions, etc. in the form of automated postbacks.
- Other partners are third-party BI systems, fraud analyzing services, etc. If you work with such services, you can set them up in the Partner Configuration page so they can receive postbacks.
"Internal BI" is a special type of partner that you can configure if you want your own internal platform to receive postbacks about attribution decisions, fraud decisions, etc. See Configuring Internal BI Postbacks for more information.
A site (or an app site) is a version of your app developed for a specific platform. You configure partner settings for each app site separately.
For example, if you have an app that runs on Android and on iOS, you have two app sites, and you can configure the partner settings for each one.
See also: App Configuration FAQ.
As part of the process of developing integrations with an attribution partner, Singular creates a postback template that contains all the fields supported by the partner. When you save a new partner configuration, Singular starts creating postbacks based on that template.
Settings and Postbacks
Partner settings are configured for each app site separately.
Singular usually requires certain credentials to send postbacks to the partner. Ask the partner for the appropriate credentials.
These are postbacks that notify the partner about a successful re-engagement. The option to enable these postbacks is only available for partners that support re-engagement campaigns (retargeting campaigns).
View-through attributions are attributions determined based on an ad view rather than an ad click. If you run any view-through campaigns, select Include View-Through Attributions to have Singular send postbacks to the partner about these attributions as well (otherwise, Singular will only send postbacks about click-through attributions).
Enabling the Include View-Through Attributions checkbox enables view-through attribution for both deterministic and probabilistic attribution models.
If you would like to disable probabilistic view-through attribution, you can do so by setting the probabilistic view-through lookback window to 0 (zero).
Note - view-through attributions for in app events will be determined by the install or re-engagement attribution setting. This means that view-through will only be applied to in-app events if it is enabled for either install or re-engagement.
Fraud postbacks include information about decisions made by Singular's fraud detection system. To learn more, see Fraud Postbacks. Also, see Singular Fraud Prevention for an introduction to Singular's advanced fraud detection methods.
This is a lookback window to limit the event postbacks to a specified time frame, e.g., 5 days after the install. If the event occurs after the specified number of days has passed, no postback will be sent. The default when sending attributed post-install events is 7 days from the attributed touchpoint (see "Touchpoint" definition below).
In-app events are any user events that happen in your app post-conversion. For example, a user who installs your app may then log in or register to your platform, watch the tutorial, or level up if it's a gaming app. Some partners want to receive postbacks about these events from Singular's attribution service.
First, choose which postbacks you want to send:
| Option | Meaning |
| All | Send this partner postbacks about all in-app events |
| Only if the install was attributed to X | Only send this partner postbacks about in-app events if the app install was attributed to this partner. |
| Off | Never send this partner postbacks about in-app events. |
Next, add your in-app events as follows:
In the In-App (SDK) Events dropdown, you will see several different revenue-related events, some of which are overlapping.
To prevent duplicate postbacks being sent for the same in-app event follow the instructions below.
|
Revenue Event Name |
Description |
| __IAP__ | An event triggered by any in-app purchases that have not been given a custom name in the SDK/S2S implementation. |
| (Custom revenue events) | In-app purchase events that have been given custom names in the SDK/S2S implementation also appear in the list. |
| __ADMON_ USER_LEVEL_REVENUE__ | An event triggered by revenue gained from ad monetization (if you have set up ad revenue attribution using the method of sending SDK events). |
| __REVENUE__ | An event triggered by any revenue coming into the app (including __IAP__, purchase events with custom names, and ad revenue events). See warning below. |
What to do if you have only in-app purchase revenue:
- Set up mappings for __IAP__ and any custom purchase events.
- Or, alternatively, use __REVENUE__, which encompasses all your in-app purchase events.
What do do if you have both in-app purchase revenue and ad revenue:
- Set up mappings for __IAP__, any custom purchase events, and __ADMON_USER_LEVEL_REVENUE__.
- We don't recommend using the general event __REVENUE__ in this case, as it includes both purchases and ad revenue events, and mapping both types of revenue to the same revenue event on the network side may cause problems.
- Instead, map in-app purchase events to the network's purchase event, and the __ADMON_USER_LEVEL_REVENUE__ event to the network's admon or ad revenue event.
- If you're not sure what events to use on the network's side, contact the network for details.
Warning: If your existing configuration for a partner is sending __REVENUE__ postbacks, and you are starting to have ad revenue events in addition to in-app purchase events, this may cause problems if the partner network is not set up to receive ad revenue events or needs them to be mapped to a separate event. Check with the network to see if and how you should send ad revenue postbacks.
Singular's integration team is in constant contact with partners to ensure we have the best integration possible. Occasionally a partner may ask you to update the integration, for example, due to changes to how the partner wants to receive postbacks from Singular.
In most cases, you can update the integration by logging into Singular, going to the Partner Configuration page, opening the integration, and re-saving it.
In some rare cases, an update may require more steps, such as providing a new field or setting that didn't exist before. In such cases, the parter or Singular will contact you to provide instructions.
No. Although partner configuration settings may appear similar, each configuration is uniquely integrated within Singular. It is not possible at this time to update multiple configurations at the same time.