Troubleshooting Data and Postbacks Using the Raw User-Level Logs

Learn how to use the Export Logs page to solve various issues you may run into.

For the basics of downloading logs, see the Export Logs FAQ.


Cross-Checking the Aggregate Data in Singular Reports

You may run into some strange data in your Singular reports - for example, a sudden, significant change in your installs/conversions or in-app events count. 

To make sure the reporting data is accurate, use the Export Logs page to download user-level data for the same day, app, etc. If the user-level data matches the reports closely, the reports are accurate.


  • If there is a mismatch, the data in the reports may be delayed. Some delay is expected because the data in Reports is updated less often during the day.
  • Singular Reports don’t show the data for ACTUAL cohort for a unique event. You can download the event logs for the required date range to get ACTUAL data and de-duplicate the device IDs to see the unique users for whom the event was recorded.

Example: Compare user-level installs data with aggregate installs data by source and campaign

  1. Run a report in the Reports page (or the Reporting API) showing installs by source and campaign.
  2. In the Export Logs page, choose the Conversions log type and pull the following fields for the same date range:


Troubleshooting Missing/Incorrect Data in Your BI Platform

If you have set up Singular to send postbacks to your internal BI, but there is data missing in your BI or data that seems incorrect, you can compare it to user-level data from Singular.

I. Check if postbacks were sent successfully

  1. In Singular, go to Attribution > Export Logs, select the relevant date range for which you suspect you didn't receive postbacks, select the Postbacks log type, and include the Response HTTP Code and Response HTTP Body fields. 
  2. In the download file, check if the postbacks were sent, and if not, see if you can identify why. The Response HTTP Code field tells you if the postback was delivered successfully. A 200 code means success; other values mean there was an error. When there's an error in sending, Singular retries the postback 5 more times, in intervals of 1, 5, 15, 30, and 60 minutes. The Response HTTP Body field may include additional details about the error.

Note: Singular doesn’t control how the data is processed in your platform. The data you see in the logs is the same data that Singular sent as postbacks to your BI.

II. Compare user-level installs data with internally recorded installs

  1. Gather the installs numbers as recorded in your internal BI.
  2. In Singular, go to Attribution > Export Logs, select the Conversions log type, and pull the following fields:


III. Compare user-level event data with internally recorded events

  1. Gather the events stats as recorded in your internal BI.
  2. In Singular, go to Attribution > Export Logs, select the Events log type, and pull the following fields. "App version" and "custom User ID" are helpful to pinpoint the source of discrepancies.


Troubleshooting Why Postbacks Aren't Being Sent to a Partner

If a partner network says they are not receiving postbacks for installs/conversions or in-app events:

  1. Download the postback logs for the partner.
    • 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. 
  2. 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.

Troubleshooting Missing Event Attributes in Partner Postbacks 

When a partner network complains that it is not receiving any event attribute, download postback logs for the partner and check the postback HTTP Body or Target URL fields to see if they include the attributes. 

Also check the postback template in the Partner Configuration page to confirm that the attribute is configured for them.

Validating Postback Data for Affiliate Invoicing

If your billing with a network is based on the number of install/event postbacks that Singular has sent to them during the period, we recommend pulling the data for the following fields:



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 to 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).

Was this article helpful?