Support Home > Reference Information > Common Causes of Discrepancies

Common Causes of Discrepancies


Kochava has the unique ability to process all data associated to a marketer’s app and their user acquisition or user engagement efforts. With our position in this space, there are opportunities for common discrepancies that occur among Kochava, App Store metrics and also with Self-Attributing Networks (SANs).

 

Kochava vs. App Store

 

Google Play Store:

Discrepancy Common Cause
Download vs. Launch The Google Play Store has insight into downloads of an App from the App Store while Kochava sees first launches of the app. This can lead to discrepancies as not all users who download launch the app.
Users vs. Devices The Google Play Store counts downloads based on a Google Play Store ID. Kochava counts individual devices. In the case a user with a single Google Play Store ID, downloads and launches an App on two separate Android devices, the Google Play Store counts a single download, but Kochava counts two.

 

Apple App Store:

Discrepancy Common Cause
Download vs. Launch iTunes Connect has insight into downloads of the app from the app store while Kochava will see first launches of the app. This can lead to discrepancies as not all users who download launch the app.
Users vs. Devices By default, iTunes Connect counts downloads based on Apple App Store IDs. Kochava counts individual devices. In the case a user with a single Apple App Store ID, downloads and launches an App on both an iPad and an iPhone, iTunes Connect counts a single download, and Kochava counts two downloads.

Facebook

Discrepancy Common Cause
Claims Kochava has insight into all campaigns currently being run through Kochava, whereas individual networks have insight into only the campaigns they run. When a SAN claims an install, Kochava compares that to all other campaigns for the App. If there is an eligible click or impression from a different network that is more recent than the click/impression reported by the SAN, Kochava awards attribution to the true winner. This causes an install to surface in the SAN partner but a claim to surface in Kochava. This also impacts all subsequent post-install events, as Kochava will surface them under the true winner, while Facebook will report these as Facebook-driven events.
Events Kochava has the ability to set a minimum time to reengagement window for events. If the event postback is set to send all we will only record the claims from Facebook for events that passed the minimum time threshold set for that event. The default setting for events is 24 hours from the last attribution that has occurred for a device. This has the potential to show a higher number of events in Facebooks dashboard when compared to Kochava.
Install Time vs. Click Time Facebook reports the install data as the time of the click, whereas Kochava reports the install date as the time of the install. For example, if a user clicks an ad on July 4th, then launches the App for the first time July 5th, the install will surface in Facebook as occurred on July 4th and in Kochava on July 5th.
Facebook SDK If an App is tracking events using the Facebook SDK, any event postbacks from Kochava can cause a discrepancy in the event counts because the Facebook system receives events from both Kochava and the Facebook SDK. Using both Kochava and the Facebook SDK can also cause a discrepancy in the install count in cases of latent data.

NOTE: For more information about integrating with Facebook, refer to our Create a Facebook Campaign support documentation.


Google

Discrepancy Common Cause
Claims Kochava has insight into all campaigns currently being run through Kochava, whereas individual networks have insight into only the campaigns they run. When a SAN claims an install, Kochava compares that to all other campaigns for the App. If there is an eligible click or impression from a different network that is more recent than the click/impression reported by the SAN, Kochava awards attribution to the true winner. This causes an install to surface in the SAN partner but a claim to surface in Kochava. This also impacts all subsequent post-install events, as Kochava will surface them under the true winner, while Google will report these as Google-driven events.
Install Time vs. Click Time Google reports the install data as the time of the click, whereas Kochava reports the install date as the time of the install. For example, if a user clicks an ad on July 4th, then launches the App for the first time July 5th, the install will surface in Google as occurred on July 4th and in Kochava on July 5th.
Events Kochava has the ability to set a minimum time to reengagement window for events. If the event postback is set to send all we will only record the claims from Google for events that passed the minimum time threshold set for that event. The default setting for events is 24 hours from the last attribution that has occurred for a device. This has the potential to show a higher number of events in Google’s dashboard when compared to Kochava.
Google Search iOS Google Search iOS operates differently from all other Google properties. Google does not report installs from Google Search-specific campaigns on iOS. This leads to discrepancies as the installs will surface in Kochava but not in Google.

NOTE: For more information about integrating with Google, refer to our Google Integration support documentation.


Twitter

Discrepancy Common Cause
Claims Kochava has insight into all campaigns currently being run through Kochava, whereas individual networks have insight into only the campaigns they run. When a SAN claims an install, Kochava compares that to all other campaigns for the App. If there is an eligible click or impression from a different network that is more recent than the click/impression reported by the SAN, Kochava awards attribution to the true winner. This causes an install to surface in the SAN partner but a claim to surface in Kochava. This also impacts all subsequent post-install events, as Kochava will surface them under the true winner, while Twitter will report these as Twitter-driven events.
Install Time vs. Click Time Twitter reports the install data as the time of the click, whereas Kochava reports the install date as the time of the install. For example, if a user clicks an ad on July 4th, then launches the App for the first time July 5th, the install will surface in Twitter as occurred on July 4th and in Kochava on July 5th.
Lookback Windows When Twitter trackers are created in the Kochava dashboard, lookback windows are set within Kochava and the Twitter dashboard. These lookback windows should align or Twitter can surface installs in their platform but not report those installs to Kochava based off the lookback windows set in Kochava.

NOTE: For more information about integrating with Twitter, refer to our Create a Twitter Campaign support documentation.


Apple Search Ads

Discrepancy Common Cause
Claims Kochava has insight into all campaigns currently being run through Kochava, whereas individual networks have insight into only the campaigns they run. When a SAN claims an install, Kochava compares that to all other campaigns for the App. If there is an eligible click or impression from a different network that is more recent than the click/impression reported by the SAN, Kochava awards attribution to the true winner. This causes an install to surface in the SAN partner but a claim to surface in Kochava. This also impacts all subsequent post-install events, as Kochava will surface them under the true winner, while Apple Search Ads will report these as Apple -driven events.
Download vs. Launch Apple considers a conversion when someone downloads the App, while Kochava defines a conversion when a user downloads the app AND opens/launches it. Thus, there are instances where a user has downloaded the app but has yet to launch it; Apple would surface this as a conversion, but Kochava would not.
Deduplication Kochava de-duplicates installs; therefore, if a user had ever downloaded the App organically and then clicked on the Apple Search Ad, Apple would log this as a conversion in their system while Kochava would not. Also, even if the user had deleted the App, clicked the ad and then reinstalled the App again, Kochava would de-duplicate this install and that device ID would remain tied to the organic install in our system.

NOTE: For more information about integrating with Apple Search Ads, refer to our Create an Apple Search Ads Campaign support documentation.


DoubleClick

Discrepancy Common Cause
DoubleClick Search DoubleClick does not claim installs from Search campaigns. This will lead to discrepancies as the installs will surface in DoubleClick but not in Kochava.

NOTE: For more information about integrating with Google DoubleClick, refer to our Google DoubleClick Integration support documentation.


Oath Ad Platforms

Discrepancy Common Cause
Claims Kochava has insight into all campaigns currently being run through Kochava, whereas individual networks have insight into only the campaigns they run. When a SAN claims an install, Kochava compares that to all other campaigns for the App. If there is an eligible click or impression from a different network that is more recent than the click/impression reported by the SAN, Kochava awards attribution to the true winner. This causes an install to surface in the SAN partner but a claim to surface in Kochava. This also impacts all subsequent post-install events, as Kochava will surface them under the true winner, while Oath Ad Platforms will report these as Oath Ad Palforms-driven events.
Install Time vs. Click Time Oath Ad Platforms reports the install data as the time of the click, whereas Kochava reports the install date as the time of the install. For example, if a user clicks an ad on July 4th, then launches the App for the first time July 5th, the install will surface in Oath Ad Platforms as occurred on July 4th and in Kochava on July 5th.
Lookback Windows When Oath Ad Platforms trackers are created in the Kochava dashboard, lookback windows are set within Kochava; lookback windows are also set within the Oath Ad Platforms dashboard. These lookback windows should align or Oath Ad Platforms can surface installs in their platform, but not report those installs to Kochava based off the lookback windows set in Kochava.

NOTE: For more information about integrating with Oath Ad Platforms, refer to our Create a Oath Ad Platforms Campaign support documentation.


Snapchat

Discrepancy Common Cause
Claims Kochava has insight into all campaigns currently being run through Kochava, whereas individual networks have insight into only the campaigns they run. When a SAN claims an install, Kochava compares that to all other campaigns for the App. If there is an eligible click or impression from a different network that is more recent than the click/impression reported by the SAN, Kochava awards attribution to the true winner. This causes an install to surface in the SAN partner but a claim to surface in Kochava. This also impacts all subsequent post-install events, as Kochava will surface them under the true winner, while Snapchat will report these as Snapchat-driven events.
Install Time vs. Click Time Snapchat reports the install data as the time of the click, whereas Kochava reports the install date as the time of the install. For example, if a user clicks an ad on July 4th, then launches the App for the first time July 5th, the install will surface in Snapchat as occurred on July 4th and in Kochava on July 5th.
Lookback Windows Snapchats default lookback logic will display conversions based on a 28 day click 1 day view lookback window. Snapchat will claim conversions to Kochava using 28 day click and 28 day view lookbook windows. This can lead to Kochava showing a greater amount of conversions than the default view within the Snapchat platform depending on the lookback windows chosen in Kochava.

NOTE: For more information about integrating with Oath Ad Platforms, refer to our Create an Oath Ad Platforms Campaign support documentation.

 
 

Last Modified: Oct 30, 2018 at 1:08 pm