Feature Summary: The following document defines the process for setting up Traffic Verifier for a tracker within Kochava. Traffic Verifier is a real-time fraud mitigation tool for ensuring that only qualified traffic is eligible for attribution, based on your preferred criteria.

 

NOTE: When creating a new Traffic Verification configuration or updating/editing an existing one, a device OS must be selected to be able to save.

 

Traffic Verifier Enables Kochava Users To:

• Establish rules to verify traffic in real-time.
• Receive postbacks with violations of traffic rules.
• If traffic violates rules, determine the actions taken with the invalid traffic.

---

Create a Traffic Verifier Configuration

 

4. Locate the desired Campaign and click the Campaign expand button.
5. Locate the desired Tracker and select Tracker Tools (⋮) > Traffic Verification.

 



A. Indicates that Traffic Verification has been set up on the Tracker.

6. Click Status > ON.
7. Copy the rules from an existing Tracker. (optional)

NOTE: Once the settings from an Existing Tracker have been imported, the settings can be updated.

8. Click Validate Dates > On. (optional)
9. Enter the desired date range.

 

WARNING: Ensure that the end dates are not in the past as that will cause all received click and impression traffic to be invalid.

 



A. Type Tracker name to search.

---

Determine Traffic Definitions

Filters:

• Device > OS (Required)
• Device > OS Version
• Device > Type
• Geo > Country
• Geo > State
• Geo > City
• Geo > Postal
• Geo > DMA

 

BEST PRACTICES: It is recommended that you ONLY use Device Type filtering for trackers you know will be targeting in-app inventory.

 

NOTE: Filters are not active until a condition and value have been created.

 

Condition:

• In
• Not In
• Greater Than or Equal
• Less Than or Equal

 

Values:

• Specific Device Platform
• Specific OS Version
• Specific Device Type
• Specific Country
• Specific State
• Specific City
• Specific Postal Code
• Specific Designated Marketing Area (DMA)

 

NOTE: The Values are dependent upon the filters selected. The list of values will update as different filters are selected.

 

BEST PRACTICES: It is recommended that a similar approach be used as the targeting criteria with Ad Network and Publishers. (i.e., using the “Matches” condition to identify the audience you are targeting)

 

---

Traffic Rules: Install:

An additional section is provided for further defining the rules associated with installs.

 

Filters —

• Device > Language

 

Condition —

• In
• Not In

 

Values —

• Specific Language (ISO 639-2 Language Abbreviation e.g., en (English))

 

---

Minimum Time-to-Install:

The Minimum Time-to-Install provides the ability to determine the acceptable length of time from click to install.

NOTE: Values entered into the Minimum Time-to-Install field are the minimum acceptable length from click (e.g., 15 seconds entered into the field will set a rule that any click occurring from 0 to 15 seconds will be invalid and 15 seconds and longer will be determined as valid.)

 

BEST PRACTICES: Minimum Time to Install should not be used for Web SDK when Kochava is doing the redirect because the Click and Install are always very close together.

BEST PRACTICES: Minimum Time to Install should not be utilized with Google Referrer Install Time (GRIT)

 

1. Enter a Time in seconds.

 

A. Installs will only be valid if they occur after the minimum time in seconds set in the Minimum Time-to-Install field.

---

iOS Install Receipts:

The iOS Install Receipts section provides the opportunity to determine which type of install receipt is acceptable, any other install without the selected install receipts will be determined to be invalid.

Select the iOS Install Receipt type:

• Verified
• Not Verified(Apple did not verify the receipt)
• Unable to Verify
• No Receipt

 

---

Google Play Settings:

The Google Play Settings section provides the opportunity to determine which Google specific settings to require or prevented.

Select the Google Play Settings:

• Require Referrer Click Time:

Enabling this option will require the presence of the Google Play timestamp of when the user clicked the download button in the play store. If the Referrer Click Time is not present, the install will be determined to be invalid.

• Require UTM_Source Match:

Enabling this option will require the UTM_Source which identifies the site that sent the user to the play store. The UTM_Source is passed to the Google Play Store and then passed from the play store to Kochava. The UTM_Source is used for install verification purposes. If the UTM_Source is not present, the install will determined to be invalid.

 

BEST PRACTICES: Generally, Require UTM_Source Match should only be considered for web inventory campaigns.

 

• Prevent UTM_Source Match:

Enabling this option will prevent Kochava from matching the UTM_Source for install verification.

 

---

Frequency Capping

Frequency Capping for traffic provides the tools for advertisers to balance reach vs. frequency. The frequency that Impressions and Clicks are verified may be capped by IP address, Site, Device ID or User Agent.

NOTE: Frequency Capping definitions use “AND” logic within the rule and “OR” logic between multiple rules. Cap numbers will be applied to all Impression or Click definitions (e.g., IP AND Site AND Device ID).

 

1. Click Add Rule.

NOTE: A Frequency Cap rule may be removed by clicking the “X”.

 

Traffic:

• Impression
• Click

 

Definition:

• IP
• Site
• Device ID
• User Agent

 

Cap:

1. Enter a number to Cap the number of Impressions and/or Clicks.

 

Duration:

1. Select a Duration:

• 1 min
• 2 min
• 3 min
• 4 min
• 5 min
• 6 min
• 7 min
• 8 min
• 9 min
• 10 min
• 15 min
• 20 min
• 25 min
• 30 min
• 35 min
• 40 min
• 45 min
• 50 min
• 55 min
• 1 hr
• 2 hr
• 3 hr
• 4 hr
• 5 hr
• 6 hr
• 7 hr
• 8 hr
• 9 hr
• 10 hr
• 11 hr
• 12 hr
• 13 hr
• 14 hr
• 15 hr
• 16 hr
• 17 hr
• 18 hr
• 19 hr
• 20 hr
• 21 hr
• 22 hr
• 23 hr
• 24 hr

---

Fraud Blocklist

Kochava provides access to our real-time Global Fraud Blocklist. Within Traffic Verifier, data associated with fraud may be filtered to provide the highest quality data possible.

 

IP:

ON — All IP addresses associated with fraud will be filtered from the Traffic Verifier data.
OFF — All IP addresses will be included within the Traffic Verifier data.

 

Site:

ON — All sites that are associated with fraud will be filtered from the Traffic Verifier data.
OFF — All site data will be included within the Traffic Verifier data.

 

Device ID:

ON — All device IDs that are associated with fraud will be filtered from the Traffic Verifier data.
OFF — All Device IDs will be included within the Traffic Verifier data.

 

A. Select “ON” or “OFF”

---

Action for Invalid Traffic Actions

Invalid Traffic Metadata:

• traffic_validated = false
• invalid_traffic = click
• traffic_rule = see below

{
                    "status": "failure",
                    "rule": "os_version_in",
                    "description": {
                        "value": "5.0",
                        "list": [
                            "8.0"
                        ]
                    }
                }

 

Attribute:

ON — Will allow the invalid impression/click to be considered for install reconciliation matching and potentially be awarded attribution.

OFF — Will allow the invalid impression/click to be considered for install reconciliation matching but will NOT allow it to be awarded attribution.   It still can be identified as an influencer.

 

Deliver Network Postback:

ON — Will allow the delivery of the Postback to the Network awarded install attribution for the invalid traffic.

OFF — Will not allow the delivery of the Postback to the Network awarded install attribution for the invalid traffic.

NOTE: If you have custom postbacks configured, the postback still will be sent regardless of this ON/OFF.

9. Click Save.

 

A. Select “ON” or “OFF”

---

Custom Advertiser Postback

NOTE: In order to add custom parameters to a Custom Advertiser Postback, contact your Client Success Managers.

 

---

Reporting

Reporting of Verification Traffic associated with Clicks and Impressions is available. For more information, refer to our Reports Overview or Pulling Reports support documentation.

---

Analytics

Traffic Verifier data is also ingested and may be displayed within Kochava Analytics. Analytics provides the ability to perform a split by either “Traffic Verified” or “Traffic Verification Fail Reason”.

 

Reason Codes Returned:

Traffic Verified —

• Unknown
• 1 (true)
• 0 (false)

 

Traffic Verification Fail Reason —

• Unknown
• Null (a zero)
• blacklist_site (Instance belongs to an identified fraudulent site)
• blacklist_device (Instance belongs to an identified fraudulent device)