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. |
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.
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 Ads support documentation.
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.
Yahoo!
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 Yahoo! will report these as Yahoo! -driven events. |
Install Time vs. Click Time | Yahoo! 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 Yahoo! as occurred on July 4th and in Kochava on July 5th. |
Lookback Windows | When Yahoo! Media trackers are created in the Kochava dashboard, lookback windows are set within Kochava; lookback windows are also set within the Yahoo! dashboard. These lookback windows should align or Yahoo! 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 Yahoo! Media, refer to our Create a Yahoo! 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.
Huawei
Discrepancy | Common Cause |
---|---|
Installs | A Kochava Install is analogous to the Activation event. There can be instances where Huawei will show an install but Kochava will have awarded the attribution to another source with a closer to install click or impression. |
Lookback Window | Depending on the settings within Kochava, events may be shown as organic if the claim falls outside the set lookback window. |