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 date 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 Google but not in Kochava.

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


Twitter

CAUTION: With a recent Twitter update, a key/value pair was added called is_granular_data_sharing_allowed. When the value for this key is set to false the end user has requested that their data not be shared with the advertiser and Kochava will reject the claim and move to the next best attribution fit. Kochava HIGHLY recommends that advertisers join the Twitter Advanced Mobile Measurement Program (AMMP). Once the advertiser has joined AMMP, Twitter can provide the data needed for accurate measurement and you may receive expanded device-level data after granting Twitter the right to perform an audit to ensure that Twitter data is being used exclusively for measurement purposes. This is consistent with common practices throughout the industry. By joining Twitter’s AMM Program, you’ll receive more complete device-level data, which will in turn reduce the discrepancy between our report and Twitter’s dashboard. If AMMP is not joined, discrepancies between Kochava and Twitter reporting will exist.

 

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.

When a Twitter user has opted out of sharing their data and targeted advertising, Twitter will make those claims on their end, but not share them with their MACT partners (Kochava). As a result, this will contribute to higher numbers in the Twitter platform than in Kochava.

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: DoubleClick integration uses the install received time (not the install occurred time) for attribution purposes. The result may look like the Click or Impression that won attribution occurred AFTER the point the user package install began. This is more likely to occur on Android when GRIT is enabled.

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


Verizon Media

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 Verizon Media will report these as Verizon Media-driven events.
Install Time vs. Click Time Verizon Media 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 Verizon Media as occurred on July 4th and in Kochava on July 5th.
Lookback Windows When Verizon Media trackers are created in the Kochava dashboard, lookback windows are set within Kochava; lookback windows are also set within the Verizon Media dashboard. These lookback windows should align or Verizon Media 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 Verizon Media, refer to our Create a Verizon Media 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.
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 Verizon Media, refer to our Create a Snapchat Campaign support documentation.