We’re now 3 weeks into a 5-week series on Configurable Reconciliation. We looked at Lookback Windows in week #1 and Probabilistic Attribution in week #2 (see iOS 14+ restrictions). This week, we’re going to dig into the bread-and-butter of attribution—Device Reconciliation.
Device reconciliation is the highest-integrity match type available. Device reconciliation happens when the device ID received on click or impression matches the device ID on install. This level of match integrity is attained in 3 ways—raw device matching, progressive reconciliation and Self-Attributing Network claims.
Raw Device Match
A raw device match happens when the device ID collected on install, which is always raw, matches with a raw device ID received on click or impression. This is the simplest scenario and is possible if a raw device ID is received on the click or impression. But what happens if the device ID received on click or impression is hashed unexpectedly through traffic rebrokering, or gets mangled in some way? For these cases, Kochava developed Progressive Reconciliation.
Progressive Reconciliation
Progressive Reconciliation is a process by which Kochava takes the raw device ID collected on install and creates over 20 variations of that device ID, based on typical alterations made by networks and publishers. The methods by which the variations are created include hashing and double hashing (SHA1 and MD5) adding and removing punctuation (dashes, colons, etc. depending on ID type), making the ID uppercase or lowercase, and creating combinations of all of these. These permutations ensure that all variations of a device ID—intended or unintended—are available for matching. This combination of raw device matching and Progressive Reconciliation allows Kochava to attribute every available install on device ID.
SAN Claims
The final method for device reconciliation is via Self-Attributing Networks or SANs. Self-Attributing Networks are large networks with high-value traffic, which have unique integrations with Kochava. Each SAN receives a postback feed of all installs for apps running traffic on the network. If the SAN has a click that is eligible for attribution, the SAN responds with a claim and a click time. Kochava reports these installs as well as putting them into the larger context of all live campaigns. Self-Attributing Networks include Facebook, Twitter, Google and iAd.
The full attribution waterfall is based on match integrity, with device reconciliation at the top. The waterfall is as follows:
- Device Reconciliation
- Raw device ID
- Progressive reconciliation
- SAN claims
- Probabilistic (see iOS 14+ restrictions)
- IP address plus User Agent
- Device ID not present on click/impression
- Device ID present on click/impressions
- IP Only (see iOS 14+ restrictions)
- Device ID not present on click/impression
- Device ID present on click/impressions
- IP Range Only (see iOS 14+ restrictions)
- Device ID not present on click/impression
- Device ID present on click/impressions
- IP address plus User Agent
In previous installments of the Configurable Attribution story, different configurations have been tied to specific goals. This Device Reconciliation story is more about exposing the inner-workings of the Attribution Engine than highlighting configurable options. Over the next 2 weeks we’re going to discuss how to digest reporting and the ins-and-outs of View-Through Attribution. Stay tuned.
