Troubleshooting Discrepancies in Singular Attribution Data

If you're a customer of Singular's attribution service, use this article to troubleshoot some common issues/questions related to your data.

 

Events count doesn't match the postbacks

Occasionally, the event postback logs or the number of events your partner network received via postbacks may not match the event statistics you see in Singular.

Here are some possible reasons:

Postback Lookback Window

One or more events may have a different lookback window configured for postbacks. Check the settings in the Partner Configuration page.

Technical Issues Receiving the Postback

The partner may have not received one or more postbacks due to technical issues on the partner's end. To check, you can include the Response HTTP Code and Response HTTP Body fields when you export the postbacks log.

  • If the Response HTTP Code is "200", it means that the partner confirmed that they received the postback.
  • Any other value reflects a problem. Look at the Response HTTP Body for additional information about the issue. If there is a persistent issue with postbacks to a certain partner,

Conversion/event logs don't match Singular reporting

If you export Install or Event logs (in the Export Logs page), and the counts don't match what you see in Singular's reporting (the Reports page or API reporting), check the following:

The report may be using cohort analysis

Your report may be displaying events by cohort, meaning that for every day in the date range, the report counts the events that were created by users who installed the app on that day (see What are cohort metrics and cohort periods?). In contrast, events in exported logs are always associated with the actual date and time in which they occurred.

Check the report settings to make sure your cohort period is set to actual so that it shows the events that occurred on the actual date.

Server time vs. adjusted time

The Singular database has two distinct time values associated with each event:

  • The Server Timestamp reflects the time in which the event was received by the Singular servers. This may be significantly different from the original time in which the event occurred if there was a technical delay in sending the event data.
  • The Adjusted Timestamp reflects the original time in which the event occurred.

The date range in the Export Logs page is based on the server timestamp.

The date ranges in the Reports page and other Singular reporting tools (e.g. the Singular API) are based on the adjusted timestamp.

This may cause discrepancies in event counts if, for example, an event that occurred on June 1 was delayed such that it arrived at the Singular servers on June 2. 

Sudden rise/drop in the number of events

If your reports show a significant increase or drop in the number of events after a certain date (with cohort period set to "actual"), check the following possible explanations:

  • Did you release a new version of the app on the day that the event count started to drop? Try exporting event logs to check that events are being sent to Singular properly from the new version of the app.
  • Did the number of installs change in the same date range? This would explain the change in the number of events.
  • Generally, does the event count in the logs reflect the same change? Use the Export Logs page to download a log of events and see if it reflects the same change as the reports do. If not, open a ticket for Singular support to investigate the issue.

Reports show some new users (installs) for re-engagement campaigns

While it's true that re-engagement (retargeting) campaigns are aimed at existing users of your product, your reports may show that the campaigns resulted in some installs (i.e., new users) as well.

This is due to the technical definition of "re-engagement event" vs. "install" in Singular. When Singular receives a first user session from a device - i.e. a session from a device is not listed in the Singular database as having the app installed on it - it is counted as an install, even if the campaign type is re-engagement/retargeting. 

For more information, see Singular's Re-engagement FAQ.

Attribution logs do not include Facebook data

If the logs you download from the Export Logs page to not include user data from Facebook, make sure you agreed to Facebook's Terms of Service (TOS) for all of your tracker apps. Without this confirmation, Singular is not allowed to display Facebook's user-level data.

Note that following recent updates to Facebook's TOS, view-through attributions (attributions to impression-based campaigns) cannot be included in user-level data.

Logs/postbacks show fewer Facebook events/installs than Singular reporting

Facebook's new Terms of Service (TOS) do not allow MMPs such as Singular to display user-level information about VT attributions. Therefore, the logs in the Export Logs page and postbacks that you send to your internal BI do not include information about VT installs and events. The terms don't apply to aggregated data, so Singular does show information about VT installs and events in aggregated reports (i.e. the Reports page, Singular API, etc.).

Cohort data in Singular doesn't match my internal BI or a third-party service I use

We don't recommend comparing cohort analysis between different sources unless you can confirm that all the sources are using both the same attribution method and the same method for calculating cohorts. Any slight differences can cause the numbers to look different.

Note the following points in particular:

  • Singular groups users into cohorts based on the install time (not the time they clicked on the ad).
  • In Singular, once a device is attributed, all the events from the device are attributed to the same source. There is no expiration date for the attribution decision - it changes only if the device is re-attributed (see the Re-engagement FAQ for more information).

Do the numbers for the actual date match?

If you are comparing global cohort data (not broken down by attributed source), you may want to check the actual numbers for the event, i.e. how many times the event happened on the actual date.

In Singular, you can get these numbers by choosing "actual" for your cohort period in reporting, or by downloading event logs in the Export Logs page.

If there is a significant difference between Singular's numbers and your platform's numbers, this indicates an issue beyond cohort calculations.

 

Was this article helpful?