Archives: Glossary Terms

How Detection Sensitivity Works

Incoming Traffic  →  [Data Collection]  →  [Rule Engine]  →  (Sensitivity Level)  →  [Classification]  ┬─ Legitimate Traffic
(Clicks/Impressions)     (IP, UA, Time)      (Filters apply)      (Low/Medium/High)       (Block/Allow)      └─ Fraudulent Traffic

🧠 Core Detection Logic

Example 1: Click Frequency Capping

This logic prevents a single user (identified by IP address or device fingerprint) from clicking an ad an excessive number of times in a short period. It’s a fundamental defense against simple bots and manual click farms trying to exhaust an ad budget.

// Define sensitivity thresholds
thresholds = {
  "low": 20,
  "medium": 10,
  "high": 3
}
sensitivity = "high"
max_clicks = thresholds[sensitivity]

// Analyze incoming click
function check_click_frequency(click_event):
  user_id = click_event.ip_address
  time_window = 60 // seconds
  
  click_count = count_clicks_from(user_id, within=time_window)
  
  if click_count > max_clicks:
    return "FRAUDULENT"
  else:
    return "LEGITIMATE"

Example 2: User Agent Validation

This logic checks the user agent string of a browser or device to see if it matches known patterns of bots or outdated software. Headless browsers or non-standard user agents are often used by bots to scrape content or perform ad fraud.

// Define known bot signatures
bot_signatures = ["HeadlessChrome", "PhantomJS", "Scrapy", "dataprovider"]

// Analyze incoming request
function validate_user_agent(request):
  user_agent = request.headers['User-Agent']
  
  for signature in bot_signatures:
    if signature in user_agent:
      return "FRAUDULENT"
      
  if user_agent is None or user_agent == "":
    return "SUSPICIOUS"
    
  return "LEGITIMATE"

Example 3: Geographic Mismatch

This logic verifies if the IP address location of a click aligns with the campaign’s targeting settings. A click from a country not targeted in the campaign is a strong indicator of fraud, often originating from a proxy server or VPN.

// Define campaign target regions
campaign_geo_targets = ["USA", "CAN", "GBR"]

// Analyze incoming click
function check_geo_mismatch(click_event):
  ip_address = click_event.ip_address
  click_country = get_country_from_ip(ip_address)
  
  if click_country not in campaign_geo_targets:
    return "FRAUDULENT"
  else:
    return "LEGITIMATE"

📈 Practical Use Cases for Businesses

• Campaign Shielding – Automatically block clicks from known data centers, VPNs, and proxies to prevent bots from draining PPC budgets on platforms like Google and Meta Ads.
• Lead Quality Improvement – Filter out fake form submissions and sign-ups generated by fraudulent traffic, ensuring that sales teams receive leads from genuine human users.
• Analytics Integrity – Ensure marketing analytics reflect real user engagement by excluding bot activity, leading to more accurate data for strategic decision-making and performance reviews.
• ROAS Optimization – By preventing wasted ad spend on invalid clicks, businesses can improve their Return On Ad Spend (ROAS) and allocate budget to channels that drive real results.

Example 1: Geofencing Rule

A business running a local promotion can use geofencing to automatically block any clicks originating from outside its specified service area, protecting its ad spend from irrelevant global traffic.

// Set campaign parameters
target_city = "New York"
target_radius_km = 50

// Process click
function enforce_geofence(click):
  click_location = get_location_from_ip(click.ip)
  distance = calculate_distance(click_location, target_city)
  
  if distance > target_radius_km:
    block_click(click)
    log_event("Blocked: Out of geo-fence")
  else:
    allow_click(click)

Example 2: Session Scoring Logic

To ensure it pays for high-quality leads, a B2B company can implement session scoring. This logic analyzes post-click behavior, such as time on page or pages visited. Clicks from sessions with near-zero engagement are flagged as low-quality or fraudulent.

// Score session after a 60-second delay
function score_session(session_id):
  session = get_session_data(session_id)
  
  score = 0
  if session.time_on_page > 10: score += 1
  if session.pages_visited > 1: score += 1
  if session.scrolled_past_fold: score += 1
  
  // High sensitivity: requires more engagement
  if score < 2:
    mark_as_invalid(session.click_id)
    log_event("Blocked: Low session score")

🐍 Python Code Examples

This code demonstrates a simple way to detect abnormal click frequency from a single IP address. If an IP makes more than a set number of clicks within a minute, it is flagged as suspicious, a common sign of bot activity.

from collections import defaultdict
import time

clicks = defaultdict(list)
# High sensitivity: only 5 clicks allowed per minute
SENSITIVITY_THRESHOLD = 5 

def is_fraudulent_click(ip_address):
    current_time = time.time()
    # Filter out clicks older than 60 seconds
    clicks[ip_address] = [t for t in clicks[ip_address] if current_time - t < 60]
    
    clicks[ip_address].append(current_time)
    
    if len(clicks[ip_address]) > SENSITIVITY_THRESHOLD:
        print(f"Fraud Alert: IP {ip_address} exceeded click threshold.")
        return True
    return False

# Simulate clicks
is_fraudulent_click("192.168.1.100") # False
is_fraudulent_click("192.168.1.100") # False
is_fraudulent_click("192.168.1.100") # False
is_fraudulent_click("192.168.1.100") # False
is_fraudulent_click("192.168.1.100") # False
is_fraudulent_click("192.168.1.100") # True

This example shows how to filter traffic based on a blocklist of known malicious user agents. Requests from user agents associated with scraping tools or bots are immediately identified and can be blocked.

# List of user agents known for bot-like behavior
BOT_AGENTS = [
    "Scrapy/1.0", 
    "PhantomJS/2.1.1",
    "Googlebot-Image/1.0" # Example of a good bot to allow
]
MALICIOUS_AGENTS_BLOCKLIST = ["Scrapy", "PhantomJS"]

def check_user_agent(user_agent_string):
    if any(malicious in user_agent_string for malicious in MALICIOUS_AGENTS_BLOCKLIST):
        print(f"Blocking request from malicious user agent: {user_agent_string}")
        return False
    print(f"Allowing request from user agent: {user_agent_string}")
    return True

# Simulate requests
check_user_agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64)") # Allowed
check_user_agent("Scrapy/1.0 (+http://scrapy.org)") # Blocked

Types of Detection Sensitivity

• Rule-Based Sensitivity
  This type relies on a static set of "if-then" rules. For example, "if a user clicks an ad more than 10 times in one minute, block them." The sensitivity is adjusted by making these numerical thresholds stricter or more lenient.
• Behavioral Sensitivity
  This approach analyzes patterns of user interaction, such as mouse movements, typing speed, and page scroll depth, to create a baseline of normal human behavior. Sensitivity is determined by how much a user's actions can deviate from this baseline before being flagged as bot-like.
• Heuristic Sensitivity
  This method uses problem-solving techniques and algorithmic shortcuts to identify likely fraud. For instance, it might flag traffic with inconsistent data, like a modern browser version reported on an obsolete operating system. Sensitivity is set by how many of these heuristic "red flags" are required to trigger a block.
• Machine Learning Sensitivity
  AI-powered models analyze vast datasets to identify complex and evolving fraud patterns that rules cannot catch. Sensitivity can be tuned to prioritize either minimizing false positives (blocking real users) or false negatives (letting fraud through), allowing for a dynamic risk assessment based on campaign goals.

How Device farm Works

+---------------------+      +----------------------+      +---------------------+
|   Fraud Operator    | →    |   Device Farm        | →    |    Ad Campaign      |
| (Sets Instructions) |      | (Multiple Devices)   |      |  (Targeted by Fraud)|
+---------------------+      +----------------------+      +---------------------+
           │                             │                             │
           │                             │                             └─ Legitimate Ads
           │                             │
           └─ Script/Manual Actions     ├─ 1. Clicks Ad
                                         ├─ 2. Installs App
                                         ├─ 3. Mimics User Behavior
                                         └─ 4. Resets Device ID/IP

🧠 Core Detection Logic

Example 1: IP and Device ID Anomaly Detection

This logic identifies fraud by detecting a high concentration of clicks or installs originating from a single IP address or a suspiciously high number of device IDs from the same IP block. It’s a foundational layer in traffic protection, flagging traffic that exhibits unnatural uniformity typical of device farms.

FUNCTION check_ip_device_anomaly(traffic_data):
  ip_to_device_map = {}
  FOR each event IN traffic_data:
    ip = event.ip_address
    device_id = event.device_id
    IF ip NOT IN ip_to_device_map:
      ip_to_device_map[ip] = set()
    ip_to_device_map[ip].add(device_id)

  FOR ip, device_ids IN ip_to_device_map:
    IF count(device_ids) > THRESHOLD_DEVICES_PER_IP:
      FLAG_AS_FRAUD(ip)
    // Also check for multiple installs from the same device
    IF count_installs_for(device_id) > 1:
      FLAG_AS_FRAUD(device_id)

Example 2: Behavioral Heuristics and Session Analysis

This logic analyzes user behavior patterns within a session to distinguish between human and automated interactions. It looks for non-human-like activity, such as unnaturally fast clicks, no mouse movement, or identical interaction times across multiple sessions, which are common indicators of scripted behavior from a device farm.

FUNCTION analyze_session_behavior(session_data):
  time_to_click = session_data.click_timestamp - session_data.page_load_timestamp
  mouse_movements = session_data.mouse_event_count

  // Rule 1: Click happened too fast
  IF time_to_click < MIN_TIME_THRESHOLD:
    RETURN "FRAUDULENT"

  // Rule 2: No mouse movement before click
  IF mouse_movements == 0:
    RETURN "FRAUDULENT"

  // Rule 3: Repetitive, identical time-between-events
  IF is_repetitive_timing(session_data.event_timestamps):
    RETURN "FRAUDULENT"

  RETURN "LEGITIMATE"

Example 3: Geo-Mismatch and Proxy Detection

This logic flags traffic where the device's reported location (e.g., from GPS) does not match the location derived from its IP address. Device farms often use proxies or VPNs to mask their true location, leading to such discrepancies. This technique helps uncover attempts to circumvent geo-targeted campaigns.

FUNCTION check_geo_mismatch(traffic_event):
  ip_location = get_location_from_ip(traffic_event.ip_address)
  reported_location = traffic_event.reported_geo

  // Check for use of known proxies/VPNs
  IF is_proxy_ip(traffic_event.ip_address):
    FLAG_AS_SUSPICIOUS(traffic_event)
    RETURN

  // Check for significant distance mismatch
  IF reported_location AND ip_location:
    distance = calculate_distance(ip_location, reported_location)
    IF distance > GEO_DISTANCE_THRESHOLD:
      FLAG_AS_FRAUD(traffic_event)

📈 Practical Use Cases for Businesses

• Campaign Shielding: Prevents ad budgets from being wasted on fraudulent clicks and installs generated by device farms, ensuring that marketing spend is directed towards genuine potential customers.
• Data Integrity for Analytics: By filtering out fraudulent traffic, businesses can maintain clean data, leading to more accurate campaign performance analysis and better-informed strategic decisions.
• Improved Return on Ad Spend (ROAS): Blocking device farm activity increases the proportion of ad spend that reaches real users, directly improving the efficiency and profitability of advertising campaigns.
• Protecting Brand Reputation: Preventing association with fraudulent traffic sources helps maintain a brand's credibility and avoids being flagged by ad networks for suspicious activity.

Example 1: Geofencing and Location-Based Filtering

This rule blocks traffic originating from locations outside a campaign's target geography or from IP addresses known to be associated with data centers or proxies, which are commonly used by device farms.

FUNCTION apply_geo_filter(user_session):
  ip_info = get_ip_details(user_session.ip)
  
  IF ip_info.country NOT IN ALLOWED_COUNTRIES:
    BLOCK_TRAFFIC(reason="Geo-fencing violation")
  
  IF ip_info.is_datacenter OR ip_info.is_proxy:
    BLOCK_TRAFFIC(reason="Proxy/Datacenter IP detected")

Example 2: Session Scoring Based on Engagement

This logic assigns a trust score to each user session based on the quality of engagement. Sessions with low scores, indicating non-human-like behavior such as zero scroll activity or instant clicks, are flagged as fraudulent.

FUNCTION calculate_session_score(session):
  score = 100
  
  // Penalize for no scrolling
  IF session.scroll_depth < 5:
    score -= 40
    
  // Penalize for unnaturally fast interaction
  IF session.time_on_page < 2_SECONDS:
    score -= 50
    
  // Penalize for generic user agent
  IF is_generic_user_agent(session.user_agent):
    score -= 20
    
  IF score < TRUST_THRESHOLD:
    FLAG_AS_FRAUD(session)

🐍 Python Code Examples

This Python function simulates the detection of high-frequency clicks from a single IP address within a short time window. This is a common pattern for device farms attempting to quickly exhaust an ad budget.

from collections import defaultdict
import time

CLICK_LOGS = defaultdict(list)
TIME_WINDOW = 60  # seconds
FREQUENCY_THRESHOLD = 10  # max clicks per window

def is_frequent_click(ip_address):
    current_time = time.time()
    
    # Filter out clicks older than the time window
    CLICK_LOGS[ip_address] = [t for t in CLICK_LOGS[ip_address] if current_time - t < TIME_WINDOW]
    
    # Add current click timestamp
    CLICK_LOGS[ip_address].append(current_time)
    
    # Check if frequency exceeds threshold
    if len(CLICK_LOGS[ip_address]) > FREQUENCY_THRESHOLD:
        print(f"Fraudulent activity detected from IP: {ip_address}")
        return True
        
    return False

# Example usage:
is_frequent_click("192.168.1.100")

This code filters incoming traffic by checking the User-Agent string against a list of known suspicious or outdated agents often used by bots and simple device farm scripts. This helps to block low-sophistication fraud attempts.

SUSPICIOUS_USER_AGENTS = [
    "bot", "crawler", "spider", "headless"
]

def filter_by_user_agent(request):
    user_agent = request.headers.get("User-Agent", "").lower()
    
    for suspicious_ua in SUSPICIOUS_USER_AGENTS:
        if suspicious_ua in user_agent:
            print(f"Blocking request with suspicious User-Agent: {user_agent}")
            return False # Block request
            
    return True # Allow request

# Example with a mock request object
class MockRequest:
    headers = {"User-Agent": "A-Generic-Bot/1.0"}

filter_by_user_agent(MockRequest())

Types of Device farm

• Manual Device Farms: These farms employ low-paid human workers to manually click on ads, install apps, and perform in-app actions. Because real humans are involved, their behavior can appear more legitimate, making this type of fraud harder to detect than fully automated methods.
• Automated Device Farms: These use scripts and software to automate fraudulent actions across a large number of devices simultaneously. This type is highly scalable and can generate a massive volume of fake traffic quickly, though the scripted behavior can sometimes be identified by sophisticated detection systems.
• Intelligent Device Farms: A more advanced variant that uses pre-programmed scripts to mimic complex user behaviors, such as completing specific in-app events or tutorials. These farms are more difficult to detect because their actions closely resemble those of real, engaged users.
• Device Emulator Farms: Instead of physical devices, these farms use software emulators to simulate hundreds or thousands of mobile devices on a smaller number of computers. This approach is cost-effective for fraudsters but can often be identified by checking device hardware parameters and sensor data.
• Hybrid Farms: This type combines physical hardware with automation, sometimes using only the motherboards of devices to reduce space and energy consumption. They blend manual and automated techniques to optimize the balance between the appearance of legitimacy and the scale of the fraudulent operation.

How Device Fingerprinting Works

Visitor Click ───> +--------------------------+ ───> +---------------------+ ───> +-------------------+ ───> Decision
                    │ Data Collection          │     │ Fingerprint         │     │ Analysis &        │     (Allow/Block)
                    │ (IP, User Agent, etc.)   │     │ Generation (Hash)   │     │ Comparison        │
                    └──────────────────────────┘     └─────────────────────┘     └───────────────────┘
                                                                                      │
                                                                                      │
                                                                                      ▼
                                                                                +-------------------+
                                                                                │ Fingerprint DB    │
                                                                                │ (Known Good/Bad)  │
                                                                                └───────────────────┘

🧠 Core Detection Logic

Example 1: High-Frequency Clicks from a Single Fingerprint

This logic is designed to catch bots that generate a large volume of clicks in a short period. It fits within the real-time analysis component of a traffic protection system. By monitoring the rate of events from a single device fingerprint, the system can identify non-human behavior characteristic of automated click fraud.

// Define thresholds
max_clicks = 5
time_window_seconds = 60

// On each ad click event
function checkClickFrequency(fingerprint_id, timestamp):
  // Get historical click data for this fingerprint
  clicks = getClicksForFingerprint(fingerprint_id, time_window_seconds)

  // Check if click count exceeds the limit
  if length(clicks) > max_clicks:
    // Flag as fraudulent and block
    blockRequest("High-frequency clicks detected from fingerprint: " + fingerprint_id)
    return "FRAUD"
  else:
    // Record the new click
    recordClick(fingerprint_id, timestamp)
    return "VALID"

Example 2: IP and Fingerprint Mismatch

This rule targets fraud where multiple, distinct device fingerprints originate from a single IP address, suggesting a bot farm or proxy server. It helps detect sophisticated fraud operations that attempt to mimic a large number of unique users from a concentrated source.

// Define thresholds
max_fingerprints_per_ip = 10
time_window_hours = 24

// On each ad click event
function checkIpFingerprintRatio(ip_address, new_fingerprint_id):
  // Get unique fingerprints seen from this IP in the time window
  fingerprints = getFingerprintsForIP(ip_address, time_window_hours)

  // Add the new fingerprint if it's not already in the list
  if new_fingerprint_id not in fingerprints:
    add(new_fingerprint_id, to=fingerprints)

  // Check if the number of unique fingerprints exceeds the threshold
  if length(fingerprints) > max_fingerprints_per_ip:
    // Flag IP as suspicious and potentially block
    flagIpForReview("Suspicious activity: too many fingerprints from " + ip_address)
    return "SUSPICIOUS"
  else:
    return "VALID"

Example 3: Geolocation and Timezone Anomaly

This logic identifies fraudulent traffic by spotting inconsistencies between a device’s reported timezone and its IP-based geolocation. For example, a click from an IP address in New York with a device timezone set to Moscow is highly suspicious. This is effective against bots that fail to properly spoof all location-related attributes.

// On each ad click event
function checkGeoTimezoneConsistency(ip_address, device_timezone):
  // Get expected timezone from IP address geolocation
  expected_timezone = getTimezoneFromIP(ip_address)

  // Compare device timezone with expected timezone
  if device_timezone != expected_timezone:
    // Flag as a geographical anomaly
    blockRequest("Geo-timezone mismatch detected for IP: " + ip_address)
    return "FRAUD"
  else:
    return "VALID"

📈 Practical Use Cases for Businesses

• Campaign Shielding: Device fingerprinting actively blocks clicks from known fraudulent devices or suspicious patterns, directly protecting advertising budgets from being wasted on invalid traffic.
• Data Integrity: By filtering out bot and fraudulent interactions, it ensures that campaign analytics (like click-through rates and conversion metrics) reflect genuine user engagement, leading to more accurate decision-making.
• ROI Improvement: It improves return on ad spend (ROAS) by ensuring that advertisements are shown to real potential customers, not bots, thus increasing the likelihood of legitimate conversions.
• Bonus Abuse Prevention: It prevents users from creating multiple accounts with the same device to exploit promotional offers or sign-up bonuses, protecting marketing funds.

Example 1: Blocking Known Fraudulent Devices

// This logic checks an incoming click against a blacklist of known fraudulent device fingerprints.

// On each ad click
function checkForBlacklistedDevice(fingerprint_id):
  // Lookup the fingerprint in the fraud database
  is_blacklisted = database.lookup("blacklist", fingerprint_id)

  if is_blacklisted:
    // Reject the click and do not charge the advertiser
    return "BLOCK"
  else:
    // Accept the click
    return "ALLOW"

Example 2: Geofencing Ad Campaigns

// This rule ensures ad clicks only come from devices located within the targeted geographical region.

// On each ad click
function enforceGeofence(ip_address, campaign_target_regions):
  // Get the location of the device from its IP address
  device_location = getLocationFromIP(ip_address)

  // Check if the device's location is within the allowed regions
  if device_location in campaign_target_regions:
    // Valid click within geofence
    return "ALLOW"
  else:
    // Invalid click outside the target area
    return "BLOCK"

Example 3: Session Scoring Based on Behavior

// This logic scores a session based on behavior tied to its fingerprint to identify non-human patterns.

// Initialize session score
session_score = 0

// Analyze behavioral events
function scoreSession(fingerprint_id, event_type):
  if event_type == "immediate_click_after_load":
    session_score += 40  // High indicator of bot activity

  if event_type == "no_mouse_movement":
    session_score += 30  // Suspicious, could be a bot

  if event_type == "unusual_scrolling_pattern":
    session_score += 20

  // Check final score against a threshold
  if session_score > 50:
    flagForReview(fingerprint_id, session_score)
    return "SUSPICIOUS"
  else:
    return "VALID"

🐍 Python Code Examples

This function simulates creating a basic device fingerprint by hashing a dictionary of request attributes. This is the first step in identifying a device to track its activity for fraud analysis.

import hashlib

def create_fingerprint(request_data):
    """
    Creates a simple device fingerprint from request attributes.
    """
    fingerprint_string = (
        f"{request_data.get('user_agent', '')}"
        f"{request_data.get('accept_language', '')}"
        f"{request_data.get('screen_resolution', '')}"
        f"{request_data.get('timezone', '')}"
    )
    
    # Use SHA256 to create a consistent hash
    return hashlib.sha256(fingerprint_string.encode('utf-8')).hexdigest()

# Example usage:
request = {
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "accept_language": "en-US,en;q=0.9",
    "screen_resolution": "1920x1080",
    "timezone": "America/New_York"
}
device_id = create_fingerprint(request)
print(f"Generated Fingerprint: {device_id}")

This code analyzes a stream of clicks to detect abnormally high frequencies from a single device fingerprint. It’s a common technique to identify automated bots that generate invalid clicks.

from collections import defaultdict
from datetime import datetime, timedelta

# Store click timestamps for each fingerprint
clicks_db = defaultdict(list)

def detect_click_fraud(fingerprint_id, max_clicks=10, window_seconds=60):
    """
    Detects high-frequency clicks from a single fingerprint.
    """
    now = datetime.now()
    time_window = now - timedelta(seconds=window_seconds)
    
    # Filter out old clicks
    valid_clicks = [t for t in clicks_db[fingerprint_id] if t > time_window]
    
    # Add the current click
    valid_clicks.append(now)
    clicks_db[fingerprint_id] = valid_clicks
    
    if len(valid_clicks) > max_clicks:
        print(f"Fraud Alert: High frequency clicks from {fingerprint_id}")
        return True
    
    return False

# Simulate clicks
for _ in range(15):
    detect_click_fraud("fingerprint_abc123")

Types of Device Fingerprinting

• Passive Fingerprinting: This type collects information that is automatically transmitted by a device during an online interaction, such as HTTP headers, IP address, and user-agent strings. It is non-intrusive but may provide less specific data than active methods.
• Active Fingerprinting: This method uses JavaScript or other scripts to actively query the browser for a wider range of attributes. This includes details like screen resolution, installed fonts, canvas rendering, and system hardware, creating a more unique and accurate fingerprint.
• Canvas Fingerprinting: A specific active technique where a hidden HTML5 canvas element is rendered in the browser. Because different devices render the image with minute variations due to hardware and software differences, the resulting image data can be used as a highly unique identifier.
• Mobile Fingerprinting: Specifically for mobile devices, this technique collects attributes unique to smartphones and tablets. It includes device model, manufacturer, mobile carrier, operating system version, and data from hardware sensors, which are useful for securing mobile-specific channels.
• Behavioral Fingerprinting: This type analyzes patterns of user interaction, such as typing speed, mouse movements, and scrolling behavior. It helps distinguish between humans and bots, as automated scripts often exhibit unnatural or robotic interaction patterns that are inconsistent with human behavior.

How Device ID Works

User Interaction (e.g., Ad Click)
       │
       ▼
┌───────────────────────┐
│  Data Collection      │
│ (JS Script/SDK)       │
└──────────┬────────────┘
           │
           ▼
┌───────────────────────┐
│ Generate Fingerprint  │
│ (Browser, OS, IP etc.)│
└──────────┬────────────┘
           │
           ▼
┌───────────────────────┐
│ Create Hash (Device ID)│
└──────────┬────────────┘
           │
           ▼
┌───────────────────────┐
│   Traffic Security    │
│       Gateway         │
└──────────┬────────────┘
           │
           ├─-→ [Rules Engine Analysis] -→ Block/Flag (Fraudulent)
           │
           └─-→ [Allow] (Legitimate)

🧠 Core Detection Logic

Example 1: High-Frequency Click Blocking

This logic prevents a single device from clicking an ad an excessive number of times in a short period. It is a fundamental rule in click fraud protection to stop bots designed for rapid, repeated clicks that drain ad budgets.

FUNCTION check_click_frequency(device_id, click_timestamp):
  // Define time window and click limit
  TIME_WINDOW = 60 // seconds
  CLICK_LIMIT = 5

  // Get recent clicks for the given device_id
  recent_clicks = get_clicks_for_device(device_id, since=click_timestamp - TIME_WINDOW)

  // Check if click count exceeds the limit
  IF count(recent_clicks) > CLICK_LIMIT:
    RETURN "BLOCK" // Fraudulent activity detected
  ELSE:
    RETURN "ALLOW" // Traffic appears normal

Example 2: Geographic Mismatch Detection

This rule flags traffic as suspicious if the device’s IP address location is significantly different from other location data points available (e.g., timezone settings). This helps detect users hiding their true location with VPNs or proxies, a common tactic in ad fraud.

FUNCTION check_geo_mismatch(device_id, ip_address):
  // Get location data from IP and device settings
  ip_location = get_location_from_ip(ip_address)
  device_timezone = get_timezone_from_fingerprint(device_id)
  device_country = get_country_from_timezone(device_timezone)

  // Compare the two locations
  IF ip_location.country != device_country:
    RETURN "FLAG_FOR_REVIEW" // Potential VPN or proxy usage
  ELSE:
    RETURN "ALLOW" // Locations are consistent

Example 3: Bot Signature Matching

This logic checks device attributes against a known database of bot characteristics. For instance, many headless browsers (used by bots) have a specific and unusual combination of user agent and screen resolution. This helps identify automated traffic that isn’t from a genuine user.

FUNCTION check_bot_signature(device_id):
  // Retrieve device attributes from its fingerprint
  user_agent = get_user_agent(device_id)
  screen_resolution = get_screen_resolution(device_id)

  // Check against known bot signatures
  is_known_bot = is_in_bot_signature_database(user_agent, screen_resolution)

  IF is_known_bot:
    RETURN "BLOCK" // Device matches a known bot profile
  ELSE:
    RETURN "ALLOW" // No bot signature matched

📈 Practical Use Cases for Businesses

• Campaign Shielding – Prevents bots and competitors from clicking on ads, protecting pay-per-click (PPC) budgets from being wasted on fraudulent traffic and ensuring ads are seen by genuine potential customers.
• Data Integrity – Ensures that marketing analytics are clean and accurate by filtering out non-human interactions. This leads to more reliable data for making strategic business decisions.
• Lead Quality Improvement – Blocks fraudulent form submissions and sign-ups from automated scripts. This ensures that sales and marketing teams are working with leads from real users, not bots.
• ROAS Optimization – Improves Return On Ad Spend by ensuring that advertising budgets are spent on reaching real users who have the potential to convert, rather than being drained by invalid clicks.

Example 1: Conversion Funnel Protection Rule

This logic protects against bots that try to mimic conversions at an inhuman speed. By setting a minimum time-to-conversion, businesses can filter out automated scripts that fill out forms or complete checkouts instantly.

FUNCTION check_conversion_speed(device_id, start_time, end_time):
  MIN_TIME_SECONDS = 10
  time_diff = end_time - start_time

  IF time_diff < MIN_TIME_SECONDS:
    // Block Device ID from future ads and void conversion
    block_device(device_id)
    RETURN "FRAUDULENT_CONVERSION"
  ELSE:
    RETURN "VALID_CONVERSION"

Example 2: Geofencing Enforcement Logic

This rule ensures that ad impressions and clicks originate from the geographic locations targeted by the campaign. It prevents budget waste on out-of-area traffic, often generated by VPNs or proxies to commit click fraud.

FUNCTION enforce_geofencing(device_id, campaign_target_region):
  // Get device location from its fingerprint and IP
  device_location = get_device_location(device_id)

  IF device_location NOT IN campaign_target_region:
    // Ignore click and do not charge advertiser
    log_event("GEO_MISMATCH", device_id)
    RETURN "BLOCK_CLICK"
  ELSE:
    RETURN "ALLOW_CLICK"

🐍 Python Code Examples

This code simulates detecting abnormally frequent clicks from the same device. It maintains a simple in-memory log of click timestamps for each Device ID and flags any ID that exceeds a defined click threshold within a short time window.

from collections import defaultdict
import time

CLICK_LOGS = defaultdict(list)
TIME_WINDOW_SECONDS = 60
MAX_CLICKS_PER_WINDOW = 5

def record_and_check_click(device_id):
    current_time = time.time()
    
    # Remove old timestamps outside the time window
    CLICK_LOGS[device_id] = [t for t in CLICK_LOGS[device_id] if current_time - t < TIME_WINDOW_SECONDS]
    
    # Add the new click timestamp
    CLICK_LOGS[device_id].append(current_time)
    
    # Check if the click count exceeds the limit
    if len(CLICK_LOGS[device_id]) > MAX_CLICKS_PER_WINDOW:
        print(f"Fraud Alert: Device ID {device_id} has exceeded the click limit.")
        return False
        
    print(f"Click from Device ID {device_id} recorded successfully.")
    return True

This example demonstrates filtering traffic based on a blocklist of suspicious user agents. It checks the User-Agent string from an incoming request's Device ID against a predefined set of signatures known to be associated with bots or non-standard browsers.

# A predefined set of user agents known to be used by bots
BOT_USER_AGENTS = {
    "PhantomJS/2.1.1",
    "Selenium/3.141.0",
    "GoogleBot/2.1" # Example, might be legitimate depending on context
}

def filter_suspicious_user_agent(device_fingerprint):
    user_agent = device_fingerprint.get("user_agent", "")
    
    if user_agent in BOT_USER_AGENTS:
        print(f"Blocked request from a known bot user agent: {user_agent}")
        return False
        
    print("User agent is not on the blocklist.")
    return True

Types of Device ID

• Device Fingerprinting - A probabilistic identifier created by combining multiple hardware and software attributes of a device, such as its browser, operating system, plugins, and screen resolution. It is highly unique and difficult for fraudsters to spoof completely.
• Mobile Advertising ID (MAID) - A unique, user-resettable ID provided by the mobile operating system, such as Apple's IDFA or Google's GAID. It's the standard for tracking users in mobile apps but can be reset by users to evade tracking.
• Cookie-Based ID - A unique identifier stored in a user's browser as a small text file (cookie). This was a traditional method for tracking users but has become less reliable due to cookie blocking, deletion by users, and browser privacy restrictions.
• IP-Based ID - Uses a device's IP address as a primary identifier. It is often combined with other signals because an IP address can be shared by many devices (e.g., on a public Wi-Fi network) or changed easily using VPNs.

How Differential privacy Works

[Raw Traffic Data] → +-----------+ → [Anonymized Data] → +------------------+ → [Fraud Score] → +----------------+
(IP, User Agent,   │ Add Noise │   (Noisy Metrics)   │ Fraud Model      │   (0.0 - 1.0)   │ Block/Allow    │
 Click Timestamps) └-----------┘                     └------------------┘                 └----------------+

🧠 Core Detection Logic

Example 1: Anomalous Click Velocity

This logic detects rapid-fire clicks originating from a similar source cluster, a common bot behavior. It uses a differentially private count of clicks within a short time window. By adding noise, it analyzes the cluster’s aggregate speed without identifying specific IPs, protecting user privacy while flagging suspicious velocity.

FUNCTION check_click_velocity(traffic_data):
  // Aggregate clicks by a generalized IP prefix (e.g., /24 subnet)
  subnet = generalize_ip(traffic_data.ip)
  timestamp = traffic_data.timestamp

  // Query a differentially private counter for this subnet
  // Noise is added to the count to protect privacy
  recent_clicks = differentially_private_count(
    subnet = subnet,
    time_window = 5_seconds
  )

  // Define a threshold for suspicious velocity
  IF recent_clicks > 20 THEN
    RETURN "High Risk: Anomalous Click Velocity"
  ELSE
    RETURN "Low Risk"
  END IF

Example 2: User Agent Mismatch Heuristics

This rule identifies non-standard or mismatched user agent and device profiles, a frequent indicator of fraudulent traffic. The logic queries a differentially private database of legitimate user-agent-to-OS combinations. It checks for anomalies in aggregate without tracking individual users, preventing bots that use inconsistent headers.

FUNCTION check_user_agent_mismatch(traffic_data):
  user_agent = traffic_data.user_agent
  os = traffic_data.operating_system

  // Query a differentially private set of valid (UA, OS) pairs
  // The query result is noisy and doesn't confirm any single user's data
  is_valid_combination = differentially_private_lookup(
    collection = "valid_ua_os_pairs",
    item = (user_agent, os)
  )

  // is_valid_combination is a probabilistic result
  IF is_valid_combination < 0.5 THEN // Lower probability suggests a mismatch
    RETURN "Medium Risk: User Agent and OS Mismatch"
  ELSE
    RETURN "Low Risk"
  END IF

Example 3: Geographic Inconsistency

This logic flags clicks where the stated timezone of the browser or device does not align with the geographical location of the IP address. The system queries a large, privacy-protected dataset of typical IP-to-timezone mappings to find deviations, which often indicate VPN or proxy usage by bots.

FUNCTION check_geo_inconsistency(traffic_data):
  ip_location = get_geo_from_ip(traffic_data.ip) // e.g., "New York"
  device_timezone = traffic_data.timezone // e.g., "Asia/Tokyo"

  // Check against a differentially private model of common geo-timezone pairs
  // This model is built on aggregate data and provides a probabilistic match
  match_probability = differentially_private_geo_model(
    location = ip_location,
    timezone = device_timezone
  )

  IF match_probability < 0.1 THEN // Very low probability of this combination being legit
    RETURN "High Risk: Geographic Inconsistency Detected"
  ELSE
    RETURN "Low Risk"
  END IF

📈 Practical Use Cases for Businesses

• Campaign Shielding – Protects ad budgets by analyzing traffic patterns with added noise, making it possible to identify and block botnets and other coordinated attacks without processing personally identifiable information. This ensures spend is directed toward real users.
• Data-Rich Analytics – Allows businesses to gain deep insights into aggregate user behavior and traffic quality. Differential privacy enables the analysis of sensitive datasets to uncover fraud trends while ensuring compliance with privacy regulations like GDPR and CCPA.
• Improved Return on Ad Spend (ROAS) – By filtering out fraudulent and invalid traffic before it depletes budgets, differential privacy ensures that campaign metrics are more accurate. This leads to better decision-making, optimized ad spend, and a higher overall return.
• Collaborative Fraud Detection – Enables multiple companies to securely share fraud-related insights. By adding noise to their respective datasets, organizations can collaboratively build more robust fraud detection models without exposing their sensitive customer data to each other.

Example 1: Click Farm Geofencing Rule

This logic blocks traffic from geographic clusters exhibiting behavior typical of click farms, such as an unusually high number of clicks from a small, non-commercial area. The analysis is done on aggregated, noisy data to protect individual user location privacy.

PROCEDURE apply_geo_fencing(click_event):
  // Generalize location to a city or region from noisy IP data
  click_location = get_noisy_location(click_event.ip)

  // Query a differentially private list of high-risk click farm regions
  is_high_risk_zone = differentially_private_lookup(
    collection = "click_farm_hotspots",
    location = click_location
  )

  IF is_high_risk_zone THEN
    REJECT_CLICK(click_event)
    LOG("Blocked: Click from high-risk geographic cluster.")
  END IF

Example 2: Session Scoring with Behavioral Noise

This pseudocode evaluates user sessions based on behavior like mouse movements and time on page. To protect privacy, small amounts of random noise are added to timing and coordinate data before analysis, allowing the system to flag non-human, robotic session patterns in aggregate.

FUNCTION score_session(session_data):
  // Add noise to sensitive behavioral metrics
  noisy_time_on_page = session_data.time_on_page + generate_noise()
  noisy_mouse_movements = session_data.mouse_movements + generate_noise()
  
  score = 0
  
  IF noisy_time_on_page < 2 THEN
    score = score + 40 // Unusually short session
  
  IF noisy_mouse_movements < 5 THEN
    score = score + 50 // Very few mouse movements, typical of simple bots

  IF score > 70 THEN
    RETURN "FRAUDULENT_SESSION"
  ELSE
    RETURN "VALID_SESSION"
  END IF

🐍 Python Code Examples

This Python code simulates detecting abnormal click frequency from a single source using a simplified differential privacy approach. It adds random "Laplacian" noise to the true click count, allowing for threshold-based fraud detection without revealing the exact number of clicks tied to a user.

import numpy as np

def private_click_frequency_check(true_click_count, sensitivity=1, epsilon=0.5):
    """
    Adds Laplacian noise to a click count to make it differentially private.
    """
    scale = sensitivity / epsilon
    noise = np.random.laplace(0, scale, 1)
    
    private_count = true_click_count + noise
    
    print(f"True count: {true_click_count}, Private count: {private_count:.2f}")
    
    # Check if the noisy count exceeds a fraud threshold
    if private_count > 100:
        return "Fraudulent activity detected."
    else:
        return "Activity appears normal."

# Simulate checking a user with a high number of clicks
print(private_click_frequency_check(110))

# Simulate checking a user with a normal number of clicks
print(private_click_frequency_check(15))

This example demonstrates filtering traffic based on suspicious user agents. A differentially private mechanism probabilistically determines if a user agent belongs to a known list of bad bots, ensuring that the check doesn't definitively confirm any user's exact software configuration.

import random

def private_user_agent_filter(user_agent, bad_user_agents):
    """
    Probabilistically checks if a user agent is on a blocklist with privacy.
    """
    # Epsilon (privacy budget) determines the probability of truthful reporting
    epsilon = 0.7
    is_on_list = user_agent in bad_user_agents
    
    # Flip the answer with a certain probability to ensure privacy
    if random.random() < (1 / (1 + np.exp(epsilon))):
        is_on_list = not is_on_list # Flip the result
        
    if is_on_list:
        return f"Block: User agent '{user_agent}' is likely a bad bot."
    else:
        return f"Allow: User agent '{user_agent}' seems legitimate."

# List of known fraudulent user agents
suspicious_agents = ["BadBot/1.0", "FraudClient/2.2"]

# Test a known bad user agent
print(private_user_agent_filter("BadBot/1.0", suspicious_agents))

# Test a legitimate user agent
print(private_user_agent_filter("Mozilla/5.0", suspicious_agents))

Types of Differential privacy

• Local Differential Privacy – This approach adds noise to data directly on a user's device before it is ever sent to a central server. In fraud detection, it ensures that the raw data (like a click event) is anonymized at the source, offering the highest level of user privacy as the central system never sees identifiable information.
• Global Differential Privacy – In this model, a trusted central server or "curator" collects the raw, sensitive data and then adds noise to the results of aggregate queries. This is useful for complex fraud analysis where more accurate aggregate statistics are needed, but it relies on trusting the central entity to protect the raw data.
• Distributed Differential Privacy – A hybrid model where data is shuffled and processed through multiple, non-colluding servers. This spreads the trust requirement, as no single server has access to all the raw data. It can offer a balance between the strong privacy of the local model and the data utility of the global model for collaborative fraud detection.
• Data-Adaptive Differential Privacy – This advanced type adjusts the amount of noise added based on the characteristics of the input data itself. For click fraud, it might add less noise to queries about traffic sources that are already known to be safe, thereby improving the accuracy of detection for genuinely ambiguous traffic sources.

How Digital Ad Intelligence Works

  Incoming Ad Traffic
        │
        ▼
+---------------------+
│   Data Collection   │
│ (IP, UA, Behavior)  │
+---------------------+
        │
        ▼
+---------------------+
│  Analysis Engine    │←───────────[Threat Intel & Rules]
│ (Pattern Matching)  │
+---------------------+
        │
        ▼
+---------------------+
│  Action & Filtering │
│  (Block / Allow)    │
+---------------------+
        │
        └─ Invalid Traffic (Blocked)
        │
        ▼
  Clean Traffic to Ad/Site

🧠 Core Detection Logic

Example 1: IP Reputation Filtering

This logic checks the visitor’s IP address against a known database of fraudulent or suspicious sources. It is a fundamental, first-line defense used to block obvious non-human traffic originating from data centers, public proxies, or networks associated with previous malicious activity.

FUNCTION checkIP(ip_address):
  // Database of known bad IP addresses and types (e.g., data center, proxy)
  DATABASE bad_ip_list

  IF ip_address IS IN bad_ip_list:
    // Check if the IP type is a data center or known proxy
    ip_type = bad_ip_list.getType(ip_address)
    IF ip_type == "datacenter" OR ip_type == "proxy":
      RETURN "BLOCK"
    END IF
  END IF

  RETURN "ALLOW"
END FUNCTION

Example 2: Session Heuristics Analysis

This logic analyzes the behavior of a user within a single session to detect anomalies. It focuses on patterns that are unnatural for genuine human interaction, such as an impossibly high number of clicks in a short time or instantaneous actions that defy human physical limitations.

FUNCTION analyzeSession(session_data):
  // Define thresholds for suspicious behavior
  MAX_CLICKS_PER_MINUTE = 5
  MIN_TIME_BETWEEN_EVENTS_MS = 100

  // Calculate click frequency
  click_rate = session_data.clicks.count() / session_data.duration_minutes
  
  IF click_rate > MAX_CLICKS_PER_MINUTE:
    RETURN "FLAG_FOR_REVIEW"
  END IF

  // Check time between page load and first action
  IF session_data.first_action_timestamp - session_data.page_load_timestamp < MIN_TIME_BETWEEN_EVENTS_MS:
    RETURN "FLAG_FOR_REVIEW"
  END IF

  RETURN "PASS"
END FUNCTION

Example 3: Geo-Mismatch Detection

This logic compares the geographical location reported by the user's browser or device with the location associated with their IP address. A significant mismatch can indicate the use of GPS spoofing tools or other methods designed to conceal the user's true origin, a common tactic in sophisticated ad fraud.

FUNCTION checkGeoMismatch(ip_geo, device_geo):
  // ip_geo is the location derived from the IP address
  // device_geo is the location from the device's GPS or browser API

  IF ip_geo AND device_geo:
    // Calculate distance between the two geographic points
    distance = calculate_distance(ip_geo.coordinates, device_geo.coordinates)

    // If the distance is greater than a plausible threshold (e.g., 100 km)
    IF distance > 100:
      RETURN "BLOCK_SUSPICIOUS_GEO"
    END IF
  END IF

  RETURN "ALLOW"
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding – Actively blocks clicks and impressions from bots and other non-human sources, ensuring that PPC and CPM budgets are spent only on reaching genuine potential customers.
• Analytics Purification – Filters out fraudulent traffic from analytics platforms. This provides a clean, accurate view of campaign performance and user behavior, leading to better strategic decisions.
• ROAS Optimization – Improves Return on Ad Spend (ROAS) by eliminating wasted expenditure on fraudulent clicks that will never convert. This allows advertisers to reallocate their budget to higher-performing, legitimate channels.
• Lead Generation Integrity – Prevents bots from submitting fake information through lead generation forms, ensuring that sales teams receive valid, high-quality leads and are not wasting time on fraudulent submissions.

Example 1: Geofencing Enforcement Rule

This logic ensures that ads are only shown to users within a specific geographic region defined by the campaign's targeting settings, blocking clicks from outside the target area.

// USE CASE: A local business wants to ensure its ad spend is not wasted on clicks from outside its service area.

FUNCTION enforceGeofence(user_ip, campaign_target_region):
  user_location = getLocation(user_ip)

  IF user_location IS_NOT_IN campaign_target_region:
    // Block the click and log the event
    log("Blocked out-of-region click from IP: " + user_ip)
    RETURN "BLOCK"
  END IF
  
  RETURN "ALLOW"
END FUNCTION

Example 2: Session Scoring for Conversion Fraud

This logic assigns a risk score to a user session based on multiple behavioral indicators. A high score suggests the user is likely a bot, preventing fraudulent conversion events.

// USE CASE: An e-commerce site wants to prevent bots from faking "add to cart" or "purchase" events.

FUNCTION scoreSession(session_events):
  risk_score = 0

  // Rule 1: Instantaneous form fill
  IF session_events.form_fill_time < 2 seconds:
    risk_score += 40
  END IF

  // Rule 2: No mouse movement detected
  IF session_events.mouse_movement_events == 0:
    risk_score += 30
  END IF

  // Rule 3: Traffic from known data center
  IF isDataCenterIP(session_events.ip_address):
    risk_score += 50
  END IF

  // If score is above threshold, flag as fraudulent
  IF risk_score > 60:
    RETURN "FRAUDULENT"
  ELSE:
    RETURN "LEGITIMATE"
  END IF
END FUNCTION

🐍 Python Code Examples

This Python function simulates checking for rapid-fire clicks from a single IP address. If the number of clicks from an IP exceeds a set limit within a short timeframe, it is flagged as suspicious, a common sign of bot activity.

CLICK_TIMESTAMPS = {}
TIME_WINDOW_SECONDS = 60
CLICK_THRESHOLD = 10

def is_click_flood(ip_address):
    """Checks if an IP is generating an abnormally high number of clicks."""
    import time
    current_time = time.time()
    
    if ip_address not in CLICK_TIMESTAMPS:
        CLICK_TIMESTAMPS[ip_address] = []

    # Remove timestamps older than the time window
    CLICK_TIMESTAMPS[ip_address] = [t for t in CLICK_TIMESTAMPS[ip_address] if current_time - t < TIME_WINDOW_SECONDS]
    
    # Add the current click timestamp
    CLICK_TIMESTAMPS[ip_address].append(current_time)
    
    # Check if click count exceeds the threshold
    if len(CLICK_TIMESTAMPS[ip_address]) > CLICK_THRESHOLD:
        print(f"ALERT: Click flood detected from IP {ip_address}")
        return True
        
    return False

# Example usage:
is_click_flood("192.168.1.100")

This code filters incoming traffic based on its user-agent string. It maintains a blocklist of user-agents known to be associated with bots and data center traffic, preventing them from interacting with the ad.

SUSPICIOUS_USER_AGENTS = [
    "HeadlessChrome",
    "PhantomJS",
    "python-requests",
    "curl"
]

def filter_by_user_agent(user_agent_string):
    """Blocks traffic from known suspicious user agents."""
    for suspicious_ua in SUSPICIOUS_USER_AGENTS:
        if suspicious_ua in user_agent_string:
            print(f"BLOCK: Suspicious user agent found: {user_agent_string}")
            return False
            
    print(f"ALLOW: User agent is clean: {user_agent_string}")
    return True

# Example usage:
filter_by_user_agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36")
filter_by_user_agent("python-requests/2.28.1")

Types of Digital Ad Intelligence

• Rule-Based Intelligence – This type uses a predefined set of static rules to filter traffic. For example, it might automatically block all traffic from a specific country, a list of known fraudulent IP addresses, or traffic using an outdated browser version. It is straightforward but less effective against new threats.
• Behavioral Intelligence – This method focuses on analyzing user actions in real-time to identify non-human patterns. It tracks metrics like mouse movement, click speed, and page scroll velocity, flagging traffic that behaves more like a bot than a person. It is highly effective at detecting sophisticated automated threats.
• Reputational Intelligence – This approach assesses traffic based on the historical reputation of its source. It leverages global data networks to check whether an IP address, device ID, or user agent has been associated with fraudulent activity in the past, blocking sources with a poor reputation.
• Heuristic Intelligence – This type combines multiple data points and analytical techniques to assign a "fraud score" to a visitor. It doesn't rely on a single red flag but rather the collective weight of several suspicious indicators, allowing for more nuanced and accurate detection of subtle or emerging fraud tactics.

How DNS Monitoring Works

  +-----------------+      +--------------------+      +----------------------+      +----------------+
  |   User Click    | →    |  DNS Query Sent    | →    | DNS Monitoring Layer | →    |   Decision     |
  +-----------------+      +--------------------+      +----------------------+      +----------------+
                                                         │                      
                                                         │                      
                                                         └─> +----------------->+
                                                             │ Analysis Engine  │
                                                             +------------------+
                                                             │ 1. IP Reputation │
                                                             │ 2. Domain Check  │
                                                             │ 3. Behavior Rule │
                                                             └──────────────────┘

🧠 Core Detection Logic

Example 1: IP Reputation Filtering

This logic prevents clicks from IP addresses known to be associated with malicious activities like botnets, data centers, or spam operations. It acts as a first line of defense by blocking traffic from sources with a poor reputation before they can interact with an ad.

FUNCTION check_ip_reputation(ip_address):
  // Query internal and external IP reputation databases
  reputation_list = query_threat_feeds(ip_address)

  IF ip_address in reputation_list.known_bad_ips:
    RETURN "BLOCK"
  ELSE IF ip_address in reputation_list.proxy_or_vpn:
    RETURN "FLAG_FOR_REVIEW"
  ELSE:
    RETURN "ALLOW"
  END IF
END FUNCTION

Example 2: DNS Query Pattern Analysis

This technique identifies non-human behavior by analyzing the frequency and pattern of DNS requests from a single source. A high volume of queries in a short time is a strong indicator of an automated bot attempting to generate fraudulent clicks across multiple ad domains.

FUNCTION analyze_dns_frequency(source_ip, time_window_seconds):
  // Get all DNS queries from the source IP in the last X seconds
  query_logs = get_dns_queries(source_ip, time_window_seconds)
  query_count = count(query_logs)

  // Set a threshold for suspicious frequency
  threshold = 20 // queries per 10 seconds

  IF query_count > threshold:
    RETURN "BLOCK_IP_TEMPORARILY"
  ELSE:
    RETURN "ALLOW"
  END IF
END FUNCTION

Example 3: Geolocation Mismatch Detection

This logic compares the geographic location of the IP address making the DNS query with the location targeted by the ad campaign. If an ad is targeted to users in Germany, but the click’s DNS query originates from a data center in Vietnam, it is flagged as likely fraudulent.

FUNCTION check_geo_mismatch(ip_address, campaign_targeting):
  ip_location = get_geolocation(ip_address)
  
  IF ip_location.country NOT IN campaign_targeting.countries:
    RETURN "BLOCK"
  ELSE IF ip_location.is_datacenter:
    // Block traffic from data centers even if in a targeted country
    RETURN "BLOCK"
  ELSE:
    RETURN "ALLOW"
  END IF
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding: Actively block clicks from known bots, data centers, and competitors, ensuring that ad spend is directed only toward genuine potential customers.
• Analytics Integrity: Filter out invalid traffic at the DNS level to prevent skewed metrics in analytics platforms, leading to more accurate data and better strategic decisions.
• Budget Protection: Prevent rapid-fire clicks from automated scripts that can quickly drain daily PPC budgets, thereby maximizing the return on ad spend (ROAS).
• Geographic Targeting Enforcement: Ensure ad impressions and clicks originate from the intended geographic regions by blocking traffic from non-targeted locations or known VPN/proxy services.

Example 1: Geofencing Rule

This pseudocode demonstrates a basic geofencing rule that blocks traffic from countries not included in a campaign’s target list and from any IP identified as a proxy, regardless of location.

RULESET ad_campaign_geofence_shield
  TARGET_COUNTRIES = ["US", "CA", "GB"]
  
  ON (dns_query):
    source_ip = query.source.ip
    ip_info = get_ip_info(source_ip)

    IF ip_info.country NOT IN TARGET_COUNTRIES:
      ACTION: BLOCK_QUERY
      LOG ("Blocked non-target country: " + ip_info.country)
    
    IF ip_info.is_proxy == TRUE:
      ACTION: BLOCK_QUERY
      LOG ("Blocked proxy IP: " + source_ip)
END RULESET

Example 2: Session Anomaly Scoring

This logic assigns a risk score to a user session based on DNS query behavior. A session accumulating too many risk points in a short period is flagged as fraudulent.

FUNCTION calculate_risk_score(dns_query):
  session_id = query.session_id
  risk_score = get_session_score(session_id)

  // Rapid, repeated queries to the same domain
  IF query_is_repetitive(query, within_seconds=5):
    risk_score += 10

  // Query for a domain known for ad stacking
  IF query.domain IN known_ad_stacking_domains:
    risk_score += 25

  // Query originates from a hosting provider (not residential)
  IF query.source.isp_type == "HOSTING":
    risk_score += 15
  
  IF risk_score > 50:
    ACTION: BLOCK_SESSION(session_id)
  
  UPDATE_SESSION_SCORE(session_id, risk_score)
END FUNCTION

🐍 Python Code Examples

This code simulates checking a list of incoming click IP addresses against a known blocklist of fraudulent IPs. This is a fundamental step in filtering out traffic from previously identified bad actors.

# A simple blocklist of known fraudulent IP addresses
FRAUDULENT_IP_BLOCKLIST = {"198.51.100.5", "203.0.113.10", "192.0.2.200"}

def filter_suspicious_ips(click_logs):
    """Filters out clicks from IPs on a blocklist."""
    clean_clicks = []
    for click in click_logs:
        if click['ip_address'] not in FRAUDULENT_IP_BLOCKLIST:
            clean_clicks.append(click)
        else:
            print(f"Blocked fraudulent click from IP: {click['ip_address']}")
    return clean_clicks

# Example usage with incoming click data
incoming_clicks = [
    {'ip_address': '8.8.8.8', 'timestamp': '2025-07-17T10:00:01Z'},
    {'ip_address': '203.0.113.10', 'timestamp': '2025-07-17T10:00:02Z'},
    {'ip_address': '10.0.0.1', 'timestamp': '2025-07-17T10:00:03Z'}
]
valid_clicks = filter_suspicious_ips(incoming_clicks)

This example demonstrates how to detect abnormally high click frequency from a single source. By tracking the timestamps of clicks, the function can identify and flag automated behavior characteristic of bot activity.

from collections import defaultdict
from datetime import datetime, timedelta

def detect_rapid_clicks(click_stream, max_clicks=5, time_window_seconds=10):
    """Identifies IPs with abnormally high click frequency."""
    ip_clicks = defaultdict(list)
    flagged_ips = set()
    
    for click in click_stream:
        ip = click['ip_address']
        timestamp = datetime.fromisoformat(click['timestamp'].replace('Z', ''))
        
        # Remove timestamps older than the time window
        ip_clicks[ip] = [t for t in ip_clicks[ip] if timestamp - t < timedelta(seconds=time_window_seconds)]
        
        ip_clicks[ip].append(timestamp)
        
        if len(ip_clicks[ip]) > max_clicks:
            flagged_ips.add(ip)
            print(f"Flagged IP for rapid clicking: {ip}")
            
    return flagged_ips

# Example usage
click_stream = [
    {'ip_address': '203.0.113.25', 'timestamp': '2025-07-17T12:00:00Z'},
    {'ip_address': '203.0.113.25', 'timestamp': '2025-07-17T12:00:01Z'},
    {'ip_address': '203.0.113.25', 'timestamp': '2025-07-17T12:00:02Z'},
    {'ip_address': '203.0.113.25', 'timestamp': '2025-07-17T12:00:03Z'},
    {'ip_address': '203.0.113.25', 'timestamp': '2025-07-17T12:00:04Z'},
    {'ip_address': '203.0.113.25', 'timestamp': '2025-07-17T12:00:05Z'},
]
detect_rapid_clicks(click_stream)

Types of DNS Monitoring

• Recursive DNS Monitoring: This type analyzes queries sent to a recursive DNS server, which resolves domains on behalf of users. It offers a broad view of traffic from a network and is effective for identifying general threats and policy violations by inspecting where users or bots are attempting to go.
• Passive DNS Monitoring: This method involves collecting and analyzing DNS data from various sources without actively querying servers. It builds a historical database of domain-to-IP mappings, helping identify malicious domains, track infrastructure changes, and uncover relationships between different malicious entities over time.
• Active DNS Probing: This technique involves actively sending DNS queries to specific domains or name servers to test their configuration, responsiveness, and security posture. It is used to verify that security measures are working correctly and to check for vulnerabilities like open resolvers that could be exploited.
• DNS Firewall Monitoring: This type specifically focuses on logging and analyzing the traffic that is blocked or allowed by a DNS firewall. It provides direct insight into the effectiveness of security rules and helps refine policies by showing what threats are actively being prevented.

How Domain Spoofing Works

+---------------------+      +------------------------+      +----------------------+
|   Fraudulent Bot    |----->| Ad Exchange (RTB)      |----->|   Advertiser's Bid   |
| (on bad-site.com)   |      |                        |      | (Pays Premium Price) |
+---------------------+      +------------------------+      +----------------------+
           │                   │    ▲                                      │
           │                   │    │                                      ▼
           │                   │    │ Verification Call             +----------------+
           │                   │    └-----------------------------+ | Security System|
           │                   │                                  +----------------+
           │                   │                                          │
           │                   └─ Spoofed Domain: "premium-site.com"       │
           │                                                              │
           └─ Actual Origin: "bad-site.com" ------------------------------>│
                                                                          │
                                                                 +-------------------+
                                                                 │ Mismatch Detected │
                                                                 │ --> BLOCK         │
                                                                 +-------------------+

🧠 Core Detection Logic

Example 1: Referrer and Placement Mismatch

This logic checks if the domain declared in the ad request (placement) matches the actual website where the ad click originated from (referrer). A mismatch is a strong signal of domain spoofing, as fraudsters often declare a premium domain while serving the ad on a low-quality site.

FUNCTION checkDomainMismatch(adRequest, clickEvent):
  declared_domain = adRequest.placement_domain
  actual_domain = clickEvent.http_referrer_domain

  IF declared_domain != actual_domain:
    RETURN "Fraudulent: Domain Mismatch"
  ELSE:
    RETURN "Legitimate"
END FUNCTION

Example 2: Ads.txt Authorization Check

This logic programmatically checks the publisher’s `ads.txt` file to verify if the seller of the ad space is authorized. If the seller ID from the bid request is not listed in the publisher’s `ads.txt` file, the inventory is considered unauthorized and likely fraudulent.

FUNCTION verifySeller(bidRequest):
  publisher_domain = bidRequest.domain
  seller_id = bidRequest.seller_id
  
  authorized_sellers = fetchAdsTxt(publisher_domain)

  IF seller_id IN authorized_sellers:
    RETURN "Authorized Seller"
  ELSE:
    RETURN "Unauthorized: Potential Spoofing"
END FUNCTION

Example 3: SupplyChain Object Validation

In programmatic advertising, the SupplyChain Object (schain) provides a transparent view of all parties involved in selling a bid request. This logic inspects the `schain` to ensure the listed nodes are legitimate and the path from the publisher to the seller is complete and makes sense.

FUNCTION validateSupplyChain(bidRequest):
  schain = bidRequest.supply_chain_object
  
  IF schain IS NULL OR schain.is_incomplete:
    RETURN "Fraudulent: Incomplete Supply Chain"
  
  FOR node IN schain.nodes:
    IF isKnownFraudulent(node.seller_id):
      RETURN "Fraudulent: Known Bad Actor in Chain"
      
  RETURN "Legitimate Supply Chain"
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding – Businesses use domain spoofing detection to ensure their ads appear only on approved, brand-safe websites. This protects advertising budgets from being wasted on fraudulent sites that offer no real value and prevents damage to brand reputation.
• Analytics Integrity – By filtering out traffic from spoofed domains, companies maintain clean and accurate data in their analytics platforms. This allows for reliable performance measurement and ensures that marketing decisions are based on real user engagement, not fraudulent activity.
• Return on Ad Spend (ROAS) Optimization – Preventing spend on fraudulent impressions from spoofed domains directly improves ROAS. Budgets are allocated to legitimate publishers who deliver genuine audiences, leading to higher conversion rates and a better overall return on investment.
• Supply Path Optimization – Advertisers can analyze supply paths to ensure they are buying inventory from authorized sellers. This helps cut out unnecessary intermediaries and reduces the risk of exposure to spoofed domains being injected into the ad tech supply chain.

Example 1: Brand Safety Geofencing Rule

This pseudocode demonstrates a rule that combines domain verification with geographic targeting. It ensures that an ad campaign for a specific region is only shown on authorized domains, preventing budget waste from bots that often use mismatched geolocations.

RULE brand_safety_geo_filter:
  GIVEN ad_request
  
  LET campaign_region = "US"
  LET request_geo = ad_request.geolocation
  LET domain = ad_request.domain
  
  IF request_geo != campaign_region:
    BLOCK "Geo Mismatch"
    
  IF isAuthorizedDomain(domain) == FALSE:
    BLOCK "Unauthorized Domain"
    
  ALLOW
END RULE

Example 2: Session Scoring for New Domains

This logic scores user sessions based on behavior to identify suspicious activity, paying special attention to traffic from newly observed or unverified domains. A low score indicates non-human behavior, typical of bots on spoofed sites.

FUNCTION scoreSession(session_data):
  
  LET score = 100
  
  IF session_data.is_new_domain == TRUE:
    score = score - 20
    
  IF session_data.time_on_page < 2_seconds:
    score = score - 30
    
  IF session_data.mouse_events == 0:
    score = score - 25

  IF score < 50:
    FLAG "Suspicious Session: Potential Spoofing"
  
  RETURN score
END FUNCTION

🐍 Python Code Examples

This function simulates checking a publisher's ads.txt file. It fetches a list of authorized seller IDs for a given domain and checks if a specific seller is permitted to sell their inventory, which is a core defense against domain spoofing.

import requests

def is_seller_authorized(domain, seller_id):
    """
    Checks if a seller is listed in the domain's ads.txt file.
    """
    try:
        response = requests.get(f"http://{domain}/ads.txt", timeout=2)
        if response.status_code == 200:
            ads_txt_content = response.text.split('n')
            for line in ads_txt_content:
                if seller_id in line:
                    return True
    except requests.RequestException:
        return False
    return False

# Example
# print(is_seller_authorized("example.com", "pub-1234567890"))

This script analyzes click data to detect abnormal frequency from a single IP address within a short time frame. High-frequency clicking is a common attribute of bot traffic used in conjunction with domain spoofing to generate fraudulent revenue.

from collections import defaultdict
import time

CLICK_LOGS = [
    {'ip': '192.168.1.1', 'timestamp': time.time()},
    {'ip': '192.168.1.1', 'timestamp': time.time() + 0.1},
    {'ip': '192.168.1.1', 'timestamp': time.time() + 0.2},
    {'ip': '10.0.0.5', 'timestamp': time.time() + 1.0},
]
TIME_WINDOW = 1 # in seconds
CLICK_THRESHOLD = 2

def detect_click_spam(clicks):
    """
    Detects high-frequency clicks from the same IP address.
    """
    ip_clicks = defaultdict(list)
    flagged_ips = set()

    for click in clicks:
        ip = click['ip']
        timestamp = click['timestamp']
        
        # Remove clicks older than the time window
        ip_clicks[ip] = [t for t in ip_clicks[ip] if timestamp - t < TIME_WINDOW]
        
        ip_clicks[ip].append(timestamp)
        
        if len(ip_clicks[ip]) > CLICK_THRESHOLD:
            flagged_ips.add(ip)
            
    return list(flagged_ips)

# print(f"Flagged IPs: {detect_click_spam(CLICK_LOGS)}")

Types of Domain Spoofing

• URL Substitution in Ad Requests - This is the most common form where fraudsters replace the true, low-quality domain with a premium domain name in the bid request sent to ad exchanges. Advertisers bid high, thinking their ad will appear on a reputable site.
• Cross-Domain iFrame Injection - Fraudsters embed a low-quality website or ad into an invisible iFrame on a higher-quality, legitimate website. This makes the fraudulent ad appear as though it's being shown on the high-quality parent domain, stealing its credibility and viewability data.
• Malware and Browser Extension Hijacking - Malicious browser extensions or malware on a user's device can inject ads onto websites or alter ad requests in transit. This software can misreport the domain where the ad is actually displayed, making it another effective spoofing method.
• Custom Browser Spoofing - Bots use custom-built browsers that are programmed to mimic human behavior and visit websites. These browsers can spoof the HTTP header information, falsely reporting that the "user" is visiting a premium website when the bot is actually cycling through low-quality sites.

How Duplicate IP address Works

  Incoming Ad Traffic (Clicks/Impressions)
              │
              ▼
+-----------------------------+
│   Traffic Security System   │
+-----------------------------+
              │
              ▼
┌─[ IP Address Extraction ]
│             │
│             ▼
└─[ IP Aggregation & Counting ]
              │ (Group by IP, Count Occurrences)
              ▼
┌─[ Rule Engine Application ]
│   (e.g., Clicks > 5 in 1 min?)
│             │
│             ├─(Yes)→ [ Flag as Suspicious ] ───> Block/Alert
│             │
└─(No)─→ [ Allow Traffic ] ──────────> To Advertiser

🧠 Core Detection Logic

Example 1: IP Frequency Capping

This logic counts the number of clicks from each IP address for a specific ad campaign within a set time frame. If the count exceeds a predefined threshold, the IP is flagged as suspicious. This is a foundational method for catching simple bot or manual fraud attacks.

FUNCTION check_ip_frequency(ip_address, campaign_id, time_window_minutes):
  
  // Get all clicks from the last N minutes for this campaign
  clicks = get_recent_clicks(campaign_id, time_window_minutes)
  
  // Count clicks from the specific IP
  ip_click_count = 0
  FOR each click IN clicks:
    IF click.ip == ip_address:
      ip_click_count += 1
  
  // Check against a predefined threshold
  IF ip_click_count > 5:
    RETURN "fraudulent"
  ELSE:
    RETURN "legitimate"

Example 2: Session Heuristics with IP Matching

This approach analyzes user behavior within a session originating from a single IP. It looks for anomalies like impossibly short time-on-page or repetitive actions. A high number of rapid-fire, low-engagement sessions from the same IP indicates automated, non-human traffic.

FUNCTION analyze_ip_session(ip_address):
  
  sessions = get_sessions_by_ip(ip_address, last_24_hours)
  suspicious_sessions = 0
  
  FOR each session IN sessions:
    // A session with less than 2 seconds on page is suspicious
    IF session.duration < 2 seconds:
      suspicious_sessions += 1
      
  // If more than 3 sessions from the same IP are suspicious, flag it
  IF suspicious_sessions > 3:
    FLAG_IP(ip_address, "Low engagement session cluster")
    RETURN "suspicious"
  
  RETURN "normal"

Example 3: Geo-Mismatch and IP Correlation

This logic cross-references the IP address’s geolocation with other data. For instance, if an ad campaign targets a specific city, but a single IP generates clicks that appear to come from multiple countries within minutes, it suggests the use of proxies or a VPN to mask the true location.

FUNCTION check_geo_mismatch(click_event):
  
  ip = click_event.ip_address
  declared_location = click_event.user_profile.location
  ip_location = get_geolocation(ip)
  
  // Check if the IP's physical location is vastly different from the user's declared location
  IF distance(ip_location, declared_location) > 500 miles:
    FLAG_IP(ip, "Geographic mismatch detected")
    RETURN "fraudulent"
    
  // Check for rapid changes in location for the same IP
  previous_locations = get_previous_locations_for_ip(ip, last_hour)
  FOR each location IN previous_locations:
    IF distance(ip_location, location) > 1000 miles:
      FLAG_IP(ip, "Impossible travel detected")
      RETURN "fraudulent"
      
  RETURN "legitimate"

📈 Practical Use Cases for Businesses

• Campaign Shielding – Automatically block IPs that exhibit repetitive, non-converting click behavior, preserving the PPC budget for genuine customers and preventing competitors from maliciously depleting funds.
• Analytics Purification – Filter out traffic from known fraudulent IPs before it pollutes marketing analytics dashboards. This ensures that metrics like conversion rate, bounce rate, and user engagement reflect real user behavior.

– Lead-Gen Form Protection – Prevent bots from submitting fake leads by blocking IPs that make multiple rapid submissions. This improves lead quality and saves sales teams from wasting time on fraudulent entries.

• Return on Ad Spend (ROAS) Integrity – By ensuring that ad spend is directed toward legitimate human users, duplicate IP detection helps maintain the integrity of ROAS calculations, giving businesses a true measure of campaign effectiveness.

Example 1: PPC Budget Protection Rule

This pseudocode defines a rule to protect a pay-per-click (PPC) campaign. It automatically adds an IP address to a blocklist if it clicks on ads for the same campaign more than a set number of times without ever leading to a conversion, thus saving money.

// Rule runs on a schedule (e.g., every 10 minutes)
FUNCTION protect_campaign_budget(campaign_id):

  // Define thresholds
  max_clicks_without_conversion = 10
  
  // Get recent click data
  clicks = get_clicks_for_campaign(campaign_id, last_24_hours)
  
  // Group clicks by IP
  ip_groups = group_by(clicks, "ip_address")
  
  FOR each ip, clicks_from_ip IN ip_groups:
    has_converted = check_for_conversion(ip, campaign_id)
    
    IF count(clicks_from_ip) > max_clicks_without_conversion AND NOT has_converted:
      // Block this IP from seeing ads in this campaign
      add_to_blocklist(ip, campaign_id, "Excessive non-converting clicks")

Example 2: Analytics Data Cleansing Filter

This logic is designed to be used before generating marketing reports. It identifies sessions originating from IPs that are on a known fraud blocklist and excludes them from analytics calculations to provide a more accurate picture of true user engagement.

FUNCTION clean_analytics_data(raw_session_data):

  // Load the central fraud IP blocklist
  fraud_ip_list = get_global_blocklist()
  
  clean_sessions = []
  
  FOR each session IN raw_session_data:
    // Check if the session's IP is on the blocklist
    IF session.ip_address NOT IN fraud_ip_list:
      add session to clean_sessions
      
  RETURN clean_sessions

🐍 Python Code Examples

This code defines a function to count the occurrences of each IP address in a list of log entries. It helps identify which IPs are most active, serving as a first step in detecting potential click fraud through high frequency.

def count_ip_occurrences(log_data):
    """
    Counts how many times each IP address appears in a list of logs.
    
    Args:
      log_data: A list of strings, where each string is an IP address.
      
    Returns:
      A dictionary with IPs as keys and their counts as values.
    """
    ip_counts = {}
    for ip in log_data:
        ip_counts[ip] = ip_counts.get(ip, 0) + 1
    return ip_counts

# Example Usage:
click_logs = ["203.0.113.1", "198.51.100.5", "203.0.113.1", "203.0.113.1"]
fraud_candidates = count_ip_occurrences(click_logs)
print(fraud_candidates)
# Output: {'203.0.113.1': 3, '198.51.100.5': 1}

This example demonstrates how to filter out clicks from a known blocklist of suspicious IPs. This is a common, direct approach to prevent recognized bad actors from interacting with ads or accessing a website.

def filter_blocked_ips(clicks, blocklist):
    """
    Removes clicks that originate from IPs on a blocklist.
    
    Args:
      clicks: A list of dictionaries, each representing a click with an 'ip' key.
      blocklist: A set of IP addresses to be blocked.
      
    Returns:
      A list of legitimate clicks.
    """
    legitimate_clicks = []
    for click in clicks:
        if click.get("ip") not in blocklist:
            legitimate_clicks.append(click)
    return legitimate_clicks

# Example Usage:
incoming_clicks = [
    {"ip": "203.0.113.45", "ad_id": "A1"},
    {"ip": "10.0.0.1", "ad_id": "A2"}, # Known bad IP
    {"ip": "192.168.1.10", "ad_id": "A3"} # Known bad IP
]
known_bad_ips = {"10.0.0.1", "192.168.1.10"}
clean_traffic = filter_blocked_ips(incoming_clicks, known_bad_ips)
print(clean_traffic)
# Output: [{'ip': '203.0.113.45', 'ad_id': 'A1'}]

Types of Duplicate IP address

• Single Fraudulent Actor – A single user or bot repeatedly clicking on an ad from the same device and network. This is the most basic form of click fraud and is often easy to detect through simple frequency analysis.
• Proxy or VPN Abuse – Fraudsters use proxy servers or VPNs to mask their true IP address. While this can make them appear to come from different locations, a single misconfigured proxy server can inadvertently funnel many fraudulent clicks through one shared IP, creating a duplicate IP signal.
• Device Farm Traffic – Large-scale fraud operations use “device farms” with hundreds of real mobile devices. If these devices are all connected to the same Wi-Fi network, they will share the same public IP address, generating a massive number of clicks or installs that appear to come from one duplicate IP.
• Shared Public Networks – Legitimate users connected to the same public Wi-Fi (e.g., in a cafe, airport, or library) will share a single IP address. This can sometimes trigger false positives if multiple users coincidentally click on the same ad.
• Corporate and University Gateways – All users within a large organization or university often have their internet traffic routed through a single gateway (NAT). This means thousands of legitimate individual users can appear to come from one IP address, which requires more sophisticated analysis to avoid blocking valid traffic.

How Earned media Works

User Interaction (Click/Visit)
       │
       ▼
+----------------------+
│ Data Collection      │
│(IP, UA, Timestamp,   │
│   Referrer, etc.)    │
+----------------------+
       │
       ▼
+---------------------------------+
│ Analysis Engine                 │
│ └─ Compare with Known Patterns │
│    ├─ Paid Traffic Behavior    │
│    └─ Earned Media Baseline    │
│       (Organic, Direct, Social) │
+---------------------------------+
       │
       ▼
+----------------------+
│ Score & Classify     │
│  ├─ Fraudulent (Block)│
│  └─ Legitimate (Allow)│
+----------------------+

🧠 Core Detection Logic

Example 1: Referral Source Validation

This logic checks if the traffic’s referral path is consistent with its claimed source. For instance, traffic claiming to be from organic search should have a matching search engine referrer. This helps detect bots that falsify referral data to appear legitimate, a pattern that earned, organic traffic would not exhibit.

FUNCTION checkReferrer(clickData):
  IF clickData.source == "PaidSearch" AND NOT clickData.referrer.contains("google.com"):
    clickData.fraudScore += 20
    RETURN "Anomaly: Mismatched search referrer"
  
  IF clickData.source == "Social" AND clickData.referrer == NULL:
    clickData.fraudScore += 15
    RETURN "Anomaly: Missing social referrer"
    
  RETURN "Referrer OK"

Example 2: Session Engagement Heuristics

This logic analyzes a user’s on-page behavior after the initial click. It compares the engagement metrics of paid traffic (e.g., time on page, scroll depth) against the established baseline from earned traffic (organic, direct). Abnormally low engagement from a paid click is a strong indicator of non-human or uninterested traffic.

FUNCTION scoreSession(sessionData, earnedBaseline):
  // earnedBaseline is pre-calculated from organic traffic
  // e.g., earnedBaseline.avgTimeOnPage = 45 seconds

  IF sessionData.sourceType == "Paid":
    IF sessionData.timeOnPage < 3 AND sessionData.scrollDepth < 10:
      // Compare against the more engaged baseline
      IF earnedBaseline.avgTimeOnPage > 30:
        sessionData.fraudScore += 40
        RETURN "Flagged: Low engagement compared to earned baseline"

  RETURN "Engagement OK"

Example 3: Cross-Campaign Anomaly Detection

This logic identifies a single user (based on IP or device fingerprint) clicking on multiple, unrelated ad campaigns in an unnaturally short period. Genuine users sourced from earned media typically show focused interest. In contrast, bots often traverse the web clicking on any ad they find, regardless of context, to maximize fraudulent revenue.

FUNCTION checkMultiCampaignFraud(userHistory):
  // userHistory stores recent clicks for a user
  
  campaignsClicked = userHistory.getCampaigns(lastMinutes=5)
  
  // If user clicked on more than 3 different campaigns recently
  IF campaignsClicked.uniqueCount > 3:
    userHistory.fraudScore += 50
    RETURN "Flagged: Unnatural multi-campaign activity"
    
  RETURN "Activity OK"

📈 Practical Use Cases for Businesses

• Budget Protection – Prevent ad spend from being wasted on automated bots and fraudulent clicks by differentiating them from users who show genuine, earned-style interest.
• Analytics Integrity – Ensure marketing data is clean and reliable by filtering out bot traffic that skews key metrics like conversion rates, bounce rates, and session duration.
• Improved ROAS – Optimize Return on Ad Spend by making sure that paid advertisements are served to real human users who exhibit authentic engagement patterns, not automated scripts.
• Lead Generation Filtering – Protect sales funnels by ensuring that contact or lead forms are filled by genuinely interested prospects, not bots that mimic conversions.

Example 1: Geofencing and Proxy Detection

This logic prevents fraud from users or bots attempting to hide their true location, which is a common tactic. Traffic from a paid campaign targeting a specific country should not originate from a data center IP in another part of the world.

FUNCTION applyGeoFilter(click):
  // Check if IP is from a known data center or proxy service
  isProxy = checkIPAgainstProxyDB(click.ipAddress)
  
  // Check if IP's country matches the campaign's target country
  isMismatch = click.ipCountry != click.campaignTargetCountry
  
  IF isProxy OR isMismatch:
    blockClick(click)
    log("Blocked click due to geo/proxy violation")
    RETURN FALSE
  
  RETURN TRUE

Example 2: Session Behavior Scoring

This logic scores a session based on its interaction quality. A session with zero mouse movement or scrolling is indicative of a simple bot. Comparing this to the active behavior of ‘earned’ organic traffic makes it easy to spot and block.

FUNCTION scoreBehavior(session):
  behaviorScore = 0
  
  IF session.mouseMovements == 0:
    behaviorScore += 30
    
  IF session.scrollPercentage < 5:
    behaviorScore += 25
    
  IF session.timeOnPage < 2:
    behaviorScore += 20
    
  IF behaviorScore > 50:
    flagForReview(session.id, "Low-quality behavioral signals")
    RETURN "Suspicious"
    
  RETURN "Legitimate"

🐍 Python Code Examples

This function simulates checking for abnormally high click frequency from a single IP address within a short time frame. This is a common indicator of bot activity, as human users do not typically click on ads with such machine-like regularity.

from collections import deque
import time

CLICK_HISTORY = {}
TIME_WINDOW_SECONDS = 60
CLICK_THRESHOLD = 10

def is_click_frequency_abnormal(ip_address):
    """Flags an IP if it exceeds a click threshold in a given time window."""
    current_time = time.time()
    
    if ip_address not in CLICK_HISTORY:
        CLICK_HISTORY[ip_address] = deque()

    # Remove clicks older than the time window
    while (CLICK_HISTORY[ip_address] and 
           CLICK_HISTORY[ip_address] < current_time - TIME_WINDOW_SECONDS):
        CLICK_HISTORY[ip_address].popleft()

    # Add the current click
    CLICK_HISTORY[ip_address].append(current_time)
    
    # Check if the number of clicks exceeds the threshold
    if len(CLICK_HISTORY[ip_address]) > CLICK_THRESHOLD:
        print(f"ALERT: High click frequency detected for IP {ip_address}")
        return True
        
    return False

# Example usage
is_click_frequency_abnormal("192.168.1.100")

This code example provides a simple way to filter out traffic based on known bot signatures in the user-agent string. While sophisticated bots can spoof user agents, this remains an effective first line of defense against less advanced automated traffic.

KNOWN_BOT_AGENTS = ["bot", "spider", "crawler", "headlesschrome"]

def filter_suspicious_user_agent(user_agent):
    """Checks if a user-agent string contains known bot signatures."""
    ua_lower = user_agent.lower()
    
    for bot_signature in KNOWN_BOT_AGENTS:
        if bot_signature in ua_lower:
            print(f"BLOCKED: Suspicious user agent detected: {user_agent}")
            return False
            
    return True

# Example usage
filter_suspicious_user_agent("Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)")
filter_suspicious_user_agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36")

Types of Earned media

• Direct Traffic Analysis

  This involves analyzing the behavior of users who navigate directly to a website. These users often have the highest intent, and their deep engagement patterns—such as multiple page views and long session durations—provide a powerful baseline for what “ideal” traffic looks like.

• Organic Search Benchmarking

  This type focuses on users arriving from non-paid search engine results. Their behavior is a strong indicator of genuine interest in the site’s content. Analyzing their journey helps distinguish between legitimate keyword-driven traffic and fraudulent clicks on ads targeting the same keywords.

• Social Media Referral Patterns

  This examines traffic from non-promoted, organic posts on social media. It helps establish a model for natural referral chains and user sharing behavior, which can be contrasted with artificial traffic spikes from bot-driven social media accounts clicking on paid links.

• Brand-Driven Navigational Queries

  This involves studying users who find the site by searching for the brand name directly. This group demonstrates high brand awareness and loyalty, and their interaction patterns are a gold standard for authentic engagement, making deviations from this norm easier to spot.