Archives: Glossary Terms

How Edge Computing Security Works

  User Click/Request → Edge Node → +-----------------------+ → Decision → Upstream
                       │           │ Real-Time Analysis:   │   │
                       │           │ └─ IP Reputation      │   │
                       │           │ └─ Device Fingerprint │   ├─ [ALLOW] → Ad Server
                       │           │ └─ Behavior Heuristics│   │
                       │           │ └─ Signature Match   │   └─ [BLOCK] → Null/Alternate
                       │           +-----------------------+

🧠 Core Detection Logic

Example 1: IP Filtering at the Edge

This logic checks the incoming request’s IP address against a dynamic, distributed database of suspicious IPs (e.g., known data centers, proxies, or botnet-associated addresses). It serves as a fundamental, first-line defense at the network perimeter before more complex analysis is needed.

FUNCTION handle_request(request):
  ip = request.get_ip()
  
  IF ip_is_in_blocklist(ip):
    RETURN block_request("IP is on a known fraudulent list")
  
  ELSE:
    RETURN allow_request()

Example 2: Session-Based Velocity Check

This logic analyzes the rate of actions within a single user session to detect non-human behavior. An impossibly high number of clicks in a very short time frame from the same session ID is a strong indicator of an automated script or bot, which can be flagged at the edge.

FUNCTION check_session_velocity(session_id, click_timestamp):
  session_data = get_session_history(session_id)
  
  // Check for more than 5 clicks in 1 second
  clicks_in_last_second = count_clicks_since(session_data, click_timestamp - 1_second)
  
  IF clicks_in_last_second > 5:
    RETURN score_session(session_id, risk_level="high")
  
  ELSE:
    RETURN score_session(session_id, risk_level="low")

Example 3: Geographic Mismatch Detection

This logic cross-references the geographic location derived from the request’s IP address with other data points like the browser’s language settings or timezone. A significant mismatch (e.g., an IP from Vietnam with English-US language and EST timezone) indicates a potential proxy or VPN user trying to mask their origin.

FUNCTION analyze_geo_mismatch(request):
  ip_geo = get_geolocation(request.get_ip()) // e.g., "Vietnam"
  browser_lang = request.get_header("Accept-Language") // e.g., "en-US"
  
  // Rule: If IP country is not in North America but language is US English
  IF ip_geo.country != "USA" AND ip_geo.country != "CAN" AND browser_lang == "en-US":
    RETURN flag_as_suspicious("Geographic mismatch detected")
  
  ELSE:
    RETURN mark_as_valid()

📈 Practical Use Cases for Businesses

• Campaign Shielding – Instantly blocks invalid traffic from known fraudulent sources at the edge, ensuring that advertising budgets are spent on reaching real, potential customers rather than bots.
• Analytics Integrity – Filters out non-human and malicious traffic before it hits analytics platforms. This provides businesses with clean, reliable data for making accurate decisions about campaign performance and user engagement.
• Improved Return on Ad Spend (ROAS) – By preventing wasteful spending on fraudulent clicks, Edge Computing Security directly improves campaign efficiency. This ensures a higher return on ad spend by focusing resources on genuine interactions that can lead to conversions.
• User Experience Protection – Protects legitimate users from malvertising and other threats delivered through fraudulent ad placements by inspecting traffic at the perimeter, before malicious payloads can be delivered.

Example 1: Geofencing Rule for Local Campaigns

A local business running a campaign targeted only to users in California can use an edge rule to automatically block any clicks originating from IP addresses outside the state, saving money and focusing data on the relevant audience.

FUNCTION handle_request(request):
  // Campaign is targeted for California (US-CA)
  TARGET_REGION = "US-CA"
  
  ip_geo = get_geolocation(request.get_ip())
  
  IF ip_geo.region_code != TARGET_REGION:
    RETURN block_request("Click is outside target campaign region")
  ELSE:
    RETURN allow_request()

Example 2: Session Scoring for Bot Detection

An e-commerce site scores user sessions at the edge. A session gets high-risk points for having a data center IP, a headless browser user-agent, and impossibly fast navigation. If the score exceeds a threshold, the session is blocked from interacting with paid ad links.

FUNCTION score_session(request):
  risk_score = 0
  
  IF ip_is_datacenter(request.get_ip()):
    risk_score += 40
    
  IF user_agent_is_headless(request.get_user_agent()):
    risk_score += 50
    
  IF time_on_page(request.get_session_id()) < 1_second:
    risk_score += 20
    
  // Threshold is 100
  IF risk_score >= 100:
    RETURN block_session("High risk score indicates bot activity")
  ELSE:
    RETURN allow_session()

🐍 Python Code Examples

This code demonstrates a basic click frequency check. It helps identify non-human behavior by tracking the timestamps of clicks from the same IP address and flagging it if the rate exceeds a plausible threshold for human activity.

# Dictionary to store click timestamps for each IP
ip_click_history = {}
CLICK_THRESHOLD = 5  # max clicks
TIME_WINDOW_SECONDS = 10  # within 10 seconds

def is_click_fraud(ip_address):
    """Checks if an IP has an abnormally high click frequency."""
    import time
    current_time = time.time()
    
    if ip_address not in ip_click_history:
        ip_click_history[ip_address] = []
    
    # Remove old timestamps outside the window
    ip_click_history[ip_address] = [t for t in ip_click_history[ip_address] if current_time - t < TIME_WINDOW_SECONDS]
    
    # Add current click
    ip_click_history[ip_address].append(current_time)
    
    # Check if threshold is exceeded
    if len(ip_click_history[ip_address]) > CLICK_THRESHOLD:
        print(f"Fraudulent activity detected from IP: {ip_address}")
        return True
        
    return False

# Simulation
is_click_fraud("192.168.1.100") # Returns False
# ... rapid clicks from the same IP ...
is_click_fraud("192.168.1.100") # Will eventually return True

This example shows how to filter traffic based on the User-Agent string. The function checks if a request’s User-Agent matches any known patterns associated with bots or automated scripts, allowing the system to block them at the edge.

SUSPICIOUS_USER_AGENTS = ["PhantomJS", "Selenium", "ScrapyBot", "HeadlessChrome"]

def is_suspicious_user_agent(request_headers):
    """Identifies if the User-Agent is on a blocklist."""
    user_agent = request_headers.get("User-Agent", "")
    
    for bot_signature in SUSPICIOUS_USER_AGENTS:
        if bot_signature in user_agent:
            print(f"Suspicious User-Agent detected: {user_agent}")
            return True
            
    return False

# Simulation
headers_1 = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."}
headers_2 = {"User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/90.0.4430.212 Safari/537.36"}

is_suspicious_user_agent(headers_1) # Returns False
is_suspicious_user_agent(headers_2) # Returns True

Types of Edge Computing Security

• Edge-Based WAF (Web Application Firewall) – Deploys security rules and filters on a distributed network of servers. It inspects incoming HTTP/S requests at the edge, blocking common threats like SQL injection and cross-site scripting, as well as bot traffic, before they reach the origin server.
• On-Device Detection – Involves running security logic directly on the end-user’s device (e.g., via an SDK in a mobile app). This allows for the analysis of device-specific signals and user behavior in a secure sandbox, identifying fraud at its ultimate source.
• CDN (Content Delivery Network) Filtering – Leverages the infrastructure of a CDN to provide security. CDNs inherently sit at the edge and can be configured with rules to identify and block traffic based on IP reputation, geolocation, request headers, and known attack signatures, effectively serving as a first line of defense.
• Serverless Edge Functions – Uses platforms like AWS Lambda@Edge or Cloudflare Workers to run custom security code in response to traffic events. This allows for highly flexible and programmable fraud detection logic that can be updated and deployed globally in minutes to counter emerging threats.

How Effective cost per mille eCPM Works

Ad Traffic → │  [Data Collection]  │ → │ [eCPM Calculation] │ → │   [Anomaly Detection]   │ → │ [Action/Alert] │
(Impressions,  │ (IP, User Agent,   │   │   (Earnings / Imp)   │   │ (Sudden Drops,        │   │ (Block IP,     │
 Clicks,       │  Behavioral Data)   │   │        * 1000        │   │  Geo Mismatches)      │   │  Flag Source)  │
 Revenue)      │                     │   │                      │   │                       │   │                │
     └─────────+─────────────────────+───+──────────────────────+───+───────────────────────+───+────────────────┘

🧠 Core Detection Logic

Example 1: Traffic Source eCPM Monitoring

This logic continuously calculates and monitors the eCPM for each traffic source (e.g., different publisher websites). A sudden and significant drop in eCPM from a specific source, without a corresponding drop in traffic volume, indicates that the source may have started sending fraudulent, non-converting traffic.

FUNCTION check_source_eCPM(source_id):
  // Get revenue and impressions for the last hour
  current_revenue = get_revenue(source_id, last_hour)
  current_impressions = get_impressions(source_id, last_hour)

  // Calculate current eCPM
  current_eCPM = (current_revenue / current_impressions) * 1000

  // Get historical average eCPM for this source
  historical_eCPM = get_historical_avg_eCPM(source_id)

  // Check if the drop is significant (e.g., > 70%)
  IF current_eCPM < (historical_eCPM * 0.3):
    FLAG_SOURCE_AS_SUSPICIOUS(source_id)
    SEND_ALERT("Significant eCPM drop for source: " + source_id)
  END IF
END FUNCTION

Example 2: Geographic eCPM Mismatch

This logic flags traffic as suspicious when the eCPM from a specific geographic region is drastically lower than the established benchmark for that region. This is effective for detecting proxy or VPN traffic where users appear to be from high-value regions but their engagement quality is low.

FUNCTION check_geo_eCPM(impression_data):
  geo_country = impression_data.country
  revenue_generated = impression_data.revenue
  
  // Assumes a single impression for this check
  impression_eCPM = (revenue_generated / 1) * 1000

  // Get expected eCPM for that country
  expected_eCPM = get_benchmark_eCPM_for_country(geo_country)
  
  // If an impression from a premium geo generates zero or very low revenue
  IF impression_eCPM < (expected_eCPM * 0.1):
    // Increment a suspicion score for the IP/user
    increment_suspicion_score(impression_data.ip_address)
    RETURN "SUSPICIOUS"
  ELSE:
    RETURN "VALID"
  END IF
END FUNCTION

Example 3: Session-Based eCPM Anomaly

This heuristic analyzes the total revenue generated within a single user session against the number of impressions served. A session with an abnormally high number of impressions but zero or near-zero revenue contribution (resulting in a session eCPM of almost $0) is a strong indicator of a bot.

FUNCTION analyze_session_eCPM(session_id):
  session_data = get_data_for_session(session_id)
  total_impressions = session_data.impression_count
  total_revenue = session_data.revenue_generated

  // Avoid division by zero
  IF total_impressions == 0:
    RETURN
  END IF

  // Calculate eCPM for the entire session
  session_eCPM = (total_revenue / total_impressions) * 1000

  // Flag sessions with many impressions but no revenue
  IF total_impressions > 20 AND session_eCPM < 0.01:
    user_ip = session_data.ip_address
    BLOCK_IP(user_ip)
    LOG_EVENT("Bot-like session detected from IP: " + user_ip)
  END IF
END FUNCTION

📈 Practical Use Cases for Businesses

By monitoring eCPM, businesses can protect their advertising investments and ensure data accuracy. Sudden drops in eCPM often serve as the first warning sign of fraudulent activity, allowing for swift intervention. This proactive approach not only saves money but also preserves the integrity of campaign analytics, leading to better-informed marketing decisions and an improved return on ad spend.

• Publisher Vetting
  Stops businesses from partnering with publishers who provide low-quality or fraudulent traffic by analyzing the eCPM generated from their inventory during a test period.
• Campaign Optimization
  Improves campaign ROI by automatically identifying and pausing ad placements or targeting segments that consistently yield near-zero eCPM, indicating they are attracting bot traffic instead of real users.
• Budget Protection
  Prevents ad budget waste by setting up real-time alerts that trigger when a campaign's eCPM drops below a critical threshold, signaling a potential click fraud attack that needs immediate attention.
• Affiliate Fraud Detection
  Identifies fraudulent affiliates by monitoring the eCPM of the traffic they send. Affiliates delivering traffic with an extremely low eCPM are likely using bots or other invalid methods to generate impressions.

Example 1: Publisher Performance Rule

This pseudocode automatically flags a new publisher if the eCPM generated from their traffic is significantly lower than the campaign average after an initial evaluation period.

FUNCTION evaluate_new_publisher(publisher_id, campaign_id):
  // Data from first 48 hours
  publisher_impressions = get_impressions(publisher_id, last_48_hours)
  publisher_revenue = get_revenue(publisher_id, last_48_hours)

  IF publisher_impressions > 10000: // Ensure sufficient data
    publisher_eCPM = (publisher_revenue / publisher_impressions) * 1000
    campaign_avg_eCPM = get_campaign_average_eCPM(campaign_id)

    // Flag if publisher eCPM is less than 25% of the campaign average
    IF publisher_eCPM < (campaign_avg_eCPM * 0.25):
      PAUSE_TRAFFIC_FROM(publisher_id)
      NOTIFY_MANAGER("Low performance from new publisher: " + publisher_id)
    END IF
  END IF
END FUNCTION

Example 2: Ad Placement Scoring

This logic scores different ad placements based on their historical eCPM. Placements that consistently fall into a low-eCPM tier are automatically deprioritized or removed from the campaign to stop budget allocation to non-performing spots.

FUNCTION score_ad_placements(campaign_id):
  placements = get_placements(campaign_id)
  
  FOR EACH placement IN placements:
    // Analyze performance over the last 7 days
    placement_eCPM = calculate_eCPM(placement.id, last_7_days)
    
    IF placement_eCPM > 10.0:
      placement.score = "PREMIUM"
    ELSE IF placement_eCPM > 2.0:
      placement.score = "STANDARD"
    ELSE:
      placement.score = "UNDERPERFORMING"
      // Optional: auto-pause if consistently low
      IF is_consistently_low(placement.id):
        PAUSE_PLACEMENT(placement.id)
      END IF
    END IF
    
    UPDATE_PLACEMENT_SCORE(placement.id, placement.score)
  NEXT
END FUNCTION

🐍 Python Code Examples

Example 1: Calculate eCPM and Detect Anomalies

This code calculates the eCPM for a given set of campaign data and flags any source where the eCPM is suspiciously low compared to the average, a common sign of invalid traffic.

import pandas as pd

def analyze_campaign_data(data):
    df = pd.DataFrame(data)
    
    # Calculate eCPM for each traffic source
    df['eCPM'] = (df['revenue'] / df['impressions']) * 1000
    
    # Calculate the average eCPM for the campaign
    average_ecpm = df['eCPM'].mean()
    
    # Identify sources with eCPM less than 20% of the average
    suspicious_sources = df[df['eCPM'] < average_ecpm * 0.2]
    
    if not suspicious_sources.empty:
        print("Suspiciously low eCPM detected from the following sources:")
        for index, row in suspicious_sources.iterrows():
            print(f"- Source ID: {row['source_id']}, eCPM: ${row['eCPM']:.2f}")
    
    return suspicious_sources

# Sample data: list of dictionaries
campaign_data = [
    {'source_id': 'pub-123', 'impressions': 50000, 'revenue': 250},
    {'source_id': 'pub-456', 'impressions': 60000, 'revenue': 300},
    {'source_id': 'bot-789', 'impressions': 100000, 'revenue': 5}, # Fraudulent source
]

analyze_campaign_data(campaign_data)

Example 2: Filter Traffic Based on Real-Time eCPM Threshold

This script simulates a real-time check. If an incoming request is from an IP address known to have a very low historical eCPM, it can be blocked before an ad is even served, saving resources and preventing fraud.

# Database of historical eCPM per IP (could be a more complex data structure)
ip_performance_db = {
    '198.51.100.10': 5.50,  # Good IP
    '198.51.100.11': 6.20,  # Good IP
    '203.0.113.5': 0.01,   # Known fraudulent IP
    '203.0.113.6': 0.02    # Known fraudulent IP
}

MIN_eCPM_THRESHOLD = 0.50 # Minimum acceptable eCPM

def should_serve_ad(ip_address):
    # Get the historical eCPM for the IP, default to a high value if unknown
    historical_ecpm = ip_performance_db.get(ip_address, 999)
    
    if historical_ecpm < MIN_eCPM_THRESHOLD:
        print(f"Blocking request from {ip_address} due to low historical eCPM (${historical_ecpm:.2f})")
        return False
    else:
        print(f"Serving ad to {ip_address} (eCPM: ${historical_ecpm:.2f})")
        return True

# Simulate incoming requests
should_serve_ad('198.51.100.10')
should_serve_ad('203.0.113.5')

Types of Effective cost per mille eCPM

• Platform-Specific eCPM
  This type measures eCPM across different ad platforms (e.g., Google AdSense, Facebook Audience Network). It helps identify which platforms deliver the most valuable impressions, allowing advertisers to allocate their budget more effectively and detect fraud concentrated on a specific, underperforming platform.
• Ad Format-Specific eCPM
  This measures the revenue performance of different ad formats, such as video, display, or native ads. By comparing the eCPM of each format, publishers can identify which ones are most susceptible to invalid traffic (e.g., a banner ad with an unusually low eCPM despite high impressions).
• Geographic eCPM
  This involves analyzing eCPM by country or region. A significant mismatch between expected and actual eCPM in a high-value geography can signal fraudulent activity, such as bots using proxies or VPNs to appear as legitimate users from premium locations.
• Segmented eCPM
  This type analyzes eCPM by audience segment, such as new vs. returning users or by demographic groups. A drastic difference in eCPM between segments that should perform similarly can uncover sophisticated bot attacks targeting specific user profiles.
• eCPM Floor
  An eCPM floor is the minimum price a publisher will accept for 1,000 ad impressions. While primarily a monetization tool, setting a floor can help filter out low-quality demand that may be associated with invalid traffic, as fraudulent bidders are often unwilling to meet higher price thresholds.

How Efficiency Metrics Works

Incoming Ad Traffic (Clicks, Impressions)
           │
           ▼
+---------------------+
│ 1. Data Collection  │
│ (IP, UA, Timestamp) │
+---------------------+
           │
           ▼
+---------------------+
│ 2. Heuristic Rules  │
│  (Thresholds, IP   │
│   Blacklists)       │
+---------------------+
           │
           ▼
+---------------------+      +-------------------+
│ 3. Behavioral     ├──────>│ 4. Anomaly Engine │
│    Analysis       │      │  (Pattern Recog.) │
│ (Session, Clicks) │      +-------------------+
+---------------------+
           │
           ▼
+---------------------+
│ 5. Scoring &      │
│    Classification │
└──────────┬──────────┘
           │
┌──────────┴──────────┐
│                     │
▼                     ▼
+-----------+     +-------------+
│ Block/Flag│     │ Allow       │
│ (Fraud)   │     │ (Legitimate)│
+-----------+     +-------------+

🧠 Core Detection Logic

Example 1: Click Frequency Throttling

This logic prevents a single user (or bot) from clicking an ad repeatedly in a short period. It’s a fundamental rule in traffic protection systems to block basic bot attacks and manual click fraud from click farms. It operates at the earliest stages of traffic filtering.

// Define click frequency limits
MAX_CLICKS_PER_MINUTE = 5
MAX_CLICKS_PER_HOUR = 20

FUNCTION check_click_frequency(user_ip, ad_id):
  // Get recent click timestamps for this IP and ad
  clicks_minute = get_clicks(user_ip, ad_id, last_60_seconds)
  clicks_hour = get_clicks(user_ip, ad_id, last_3600_seconds)

  IF count(clicks_minute) > MAX_CLICKS_PER_MINUTE THEN
    RETURN "BLOCK_FRAUD"
  END IF

  IF count(clicks_hour) > MAX_CLICKS_PER_HOUR THEN
    RETURN "BLOCK_FRAUD"
  END IF

  RETURN "ALLOW"
END FUNCTION

Example 2: Geographic Mismatch Detection

This logic identifies fraud by comparing the user’s IP-based geolocation with other location data, such as their browser’s language settings or timezone. A significant mismatch often indicates the use of a proxy or VPN to mask the user’s true origin, a common tactic in ad fraud.

FUNCTION check_geo_mismatch(ip_address, browser_timezone, browser_language):
  // Get location data from IP
  ip_geo = get_geolocation(ip_address) // e.g., {country: "USA", timezone: "America/New_York"}
  
  // Compare IP timezone with browser timezone
  IF ip_geo.timezone != browser_timezone THEN
    RETURN "FLAG_SUSPICIOUS"
  END IF

  // Compare IP country with typical language country
  expected_country = get_country_for_language(browser_language) // e.g., "en-US" -> "USA"
  IF ip_geo.country != expected_country THEN
    RETURN "FLAG_SUSPICIOUS"
  END IF

  RETURN "ALLOW"
END FUNCTION

Example 3: Session Behavior Analysis

This heuristic analyzes user behavior after the click. An immediate bounce (leaving the site instantly) or a session with zero interaction (no scrolling, no mouse movement) is highly indicative of non-human traffic. This logic helps identify low-quality or bot traffic that slips past initial filters.

FUNCTION analyze_session_behavior(session_id):
  session = get_session_data(session_id)
  
  // Check for immediate bounce
  IF session.duration < 2 seconds THEN
    RETURN "SCORE_FRAUD_HIGH"
  END IF

  // Check for lack of interaction
  IF session.scroll_events == 0 AND session.mouse_movements == 0 THEN
    RETURN "SCORE_FRAUD_MEDIUM"
  END IF
  
  // Check for impossibly fast form submission
  IF session.form_submit_time < 5 seconds THEN
    RETURN "SCORE_FRAUD_HIGH"
  END IF

  RETURN "SCORE_LEGITIMATE"
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding – Automatically blocks clicks from known fraudulent sources like data centers and competitor IPs, preventing budget waste before it occurs and preserving the integrity of pay-per-click (PPC) campaigns.
• Lead Generation Filtering – Analyzes form submissions to filter out fake leads generated by bots. This ensures that sales teams only spend time on genuine prospects, improving their efficiency and conversion rates.
• Analytics Purification – Excludes invalid traffic from performance dashboards. This provides marketers with clean, accurate data, enabling them to make better strategic decisions about budget allocation and campaign optimization.
• Conversion Fraud Prevention – Identifies and blocks fraudulent conversion events, such as fake app installs or sign-ups, which protects advertisers from paying for actions that were not performed by real users.
• Return on Ad Spend (ROAS) Improvement – By eliminating wasteful spending on fraudulent clicks and impressions, businesses ensure their ad budget is spent on reaching real potential customers, directly increasing the overall return on their investment.

Example 1: Data Center IP Blocking

This pseudocode demonstrates a basic but critical rule to block traffic originating from known data centers, which are almost never legitimate sources of customer traffic.

// Load a list of known data center IP ranges
DATA_CENTER_IPS = load_list("datacenter_ip_ranges.txt")

FUNCTION check_ip_source(user_ip):
  // Check if the user's IP falls within any data center range
  FOR range IN DATA_CENTER_IPS:
    IF user_ip IN range:
      // Block the request immediately
      RETURN "BLOCK_DATACENTER_IP"
    END IF
  ENDFOR

  RETURN "ALLOW"
END FUNCTION

Example 2: Session Scoring for Lead Quality

This logic assigns a quality score to a user session based on their behavior, helping to differentiate between a real interested user and a bot filling out a lead form.

FUNCTION score_lead_quality(session):
  score = 0
  
  // Real users take time to read and type
  IF session.time_on_page > 10 seconds:
    score += 1

  // Bots often have no mouse movement
  IF session.mouse_movements > 5:
    score += 1
  
  // Check for copy-pasted or nonsensical form inputs
  IF is_gibberish(session.form_data.name):
    score -= 2

  IF score >= 2:
    RETURN "VALID_LEAD"
  ELSE:
    RETURN "INVALID_LEAD"
  END IF
END FUNCTION

🐍 Python Code Examples

This function simulates checking how many times a click has occurred from a single IP address within a short time frame. It's a simple way to detect basic bot attacks or manual fraud where an entity repeatedly clicks an ad.

from collections import defaultdict
import time

# In a real system, this would be a database or a persistent cache
click_log = defaultdict(list)
TIME_WINDOW_SECONDS = 60
CLICK_THRESHOLD = 5

def is_suspicious_click_frequency(ip_address):
    """Checks if an IP has clicked too frequently in a given time window."""
    current_time = time.time()
    
    # Filter out old clicks
    valid_clicks = [t for t in click_log[ip_address] if current_time - t < TIME_WINDOW_SECONDS]
    click_log[ip_address] = valid_clicks
    
    # Add the new click
    click_log[ip_address].append(current_time)
    
    # Check if threshold is exceeded
    if len(click_log[ip_address]) > CLICK_THRESHOLD:
        print(f"Suspicious activity from {ip_address}: {len(click_log[ip_address])} clicks.")
        return True
        
    return False

# Simulation
print(is_suspicious_click_frequency("8.8.8.8")) # False
# ...imagine 5 more rapid clicks from the same IP...
for _ in range(5):
    is_suspicious_click_frequency("8.8.8.8")
print(is_suspicious_click_frequency("8.8.8.8")) # True

This example demonstrates how to filter traffic based on the User-Agent string. A missing or known bot-related User-Agent can be a strong indicator of fraudulent or unwanted traffic.

# List of user agents known to be associated with bots or scrapers
SUSPICIOUS_USER_AGENTS = {
    "Googlebot", # Example: You might want to block some bots but not all
    "AhrefsBot",
    "SemrushBot",
    "Python-urllib/3.9",
    None # Missing user agent
}

def filter_by_user_agent(user_agent):
    """Filters traffic based on the user agent string."""
    if user_agent in SUSPICIOUS_USER_AGENTS or not user_agent:
        print(f"Blocking suspicious user agent: {user_agent}")
        return False # Block traffic
    
    print(f"Allowing user agent: {user_agent}")
    return True # Allow traffic

# Simulation
filter_by_user_agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64)...") # Allowed
filter_by_user_agent("AhrefsBot") # Blocked
filter_by_user_agent(None) # Blocked

Types of Efficiency Metrics

• Heuristic-Based Metrics – This type uses predefined rules and thresholds to identify fraud. For example, a rule might block any IP address that clicks an ad more than five times in one minute. It is effective against simple, high-volume bot attacks and is computationally efficient for real-time filtering.
• Behavioral Metrics – These metrics analyze user interaction patterns to distinguish humans from bots. This includes measuring session duration, scroll depth, mouse movements, and click patterns. Unnatural or non-human-like interactions are flagged as fraudulent, catching more sophisticated bots that evade simple rule-based systems.
• Anomaly Detection Metrics – This approach uses machine learning and statistical analysis to identify deviations from baseline traffic patterns. It can detect sudden, unexpected spikes in traffic from a specific country or an unusually high click-through rate on a new campaign, indicating coordinated fraudulent activity.
• Reputation-Based Metrics – This type assesses the trustworthiness of a traffic source based on historical data. It involves checking IP addresses against blacklists of known fraudsters, identifying traffic from data centers, or flagging requests that use proxies or VPNs to hide their origin.
• Cross-Campaign Analysis Metrics – This technique involves analyzing data across multiple advertising campaigns to spot widespread fraud. If the same group of suspicious IP addresses or device IDs appears across different advertisers and platforms, it strongly indicates an organized fraud ring that can be blocked system-wide.

How Emulated devices Works

+------------------+     +--------------------+     +------------------+
| Fraudster        | --> | Emulator           | --> | Ad Network       |
| (Initiates Fraud)|     | (Mimics Device &   |     | (Serves Ad)      |
|                  |     |  Automates Clicks) |     |                  |
+------------------+     +---------+----------+     +--------+---------+
                                   |                         |
                                   | Fake Interaction Data   | Ad Impression
                                   | (Click, Install)        |
                                   v                         v
+----------------------------------+-------------------------+---------+
| Traffic Protection System                                            |
|                                                                      |
| └─> Data Analysis (IP, User Agent, Behavior, Device Properties)      |
|                                                                      |
| └─> Anomaly Detection (Finds non-human patterns, inconsistencies)    |
|                                                                      |
| └─> Flag & Block (Identifies emulator traffic as fraudulent)         |
|                                                                      |
+----------------------------------------------------------------------+

🧠 Core Detection Logic

Example 1: Inconsistent Device Fingerprint

This logic checks for contradictions in the device’s reported attributes. Emulators often fail to create a perfectly consistent profile, leaving behind clues. For example, a device might report itself as an iPhone but have technical properties (like a WebGL renderer) exclusive to Android emulators. This check is fundamental in identifying spoofed devices.

FUNCTION checkDeviceFingerprint(request):
  device_properties = request.getDeviceProperties()
  user_agent = device_properties.getUserAgent()
  renderer = device_properties.getWebGLRenderer()

  // Known emulator signature
  IF "Google SwiftShader" IN renderer:
    RETURN "FRAUD"

  // Contradictory properties
  IF "iPhone" IN user_agent AND "Android" IN device_properties.getOS():
    RETURN "FRAUD"

  // Missing essential hardware properties
  IF device_properties.hasAccelerometer() == FALSE:
    RETURN "POTENTIAL_FRAUD"

  RETURN "LEGITIMATE"

Example 2: Behavioral Heuristics

This logic analyzes the timing and frequency of user actions during a session. Emulators controlled by scripts often perform actions with unnatural speed and regularity. This rule flags traffic that shows impossibly short intervals between a click and an app install or multiple clicks occurring faster than a human can manage.

FUNCTION checkBehavior(session):
  click_timestamp = session.getClickTime()
  install_timestamp = session.getInstallTime()
  time_to_install = install_timestamp - click_timestamp

  // Flag installs happening too quickly after a click
  IF time_to_install < 2 SECONDS:
    RETURN "FRAUD"

  click_count = session.getClickCount(within_last_minute)
  
  // Flag abnormally high click frequency from one source
  IF click_count > 30:
    RETURN "FRAUD"
  
  RETURN "LEGITIMATE"

Example 3: Sensor Data Validation

This logic verifies the presence of data from physical sensors commonly found in mobile devices. Emulators cannot replicate authentic sensor data from accelerometers, gyroscopes, or proximity sensors. The absence of this data, or the presence of perfectly uniform and predictable data, is a strong indicator of a non-physical, emulated device.

FUNCTION checkSensorData(request):
  device_sensors = request.getSensorData()

  // Emulators typically lack access to these hardware sensors
  IF device_sensors.has("accelerometer") == FALSE AND device_sensors.has("gyroscope") == FALSE:
    RETURN "FRAUD"

  // Check for unnatural, static sensor values
  accelerometer_data = device_sensors.get("accelerometer_events")
  IF accelerometer_data.isStatic() OR accelerometer_data.isEmpty():
    RETURN "POTENTIAL_FRAUD"

  RETURN "LEGITIMATE"

📈 Practical Use Cases for Businesses

• Campaign Shielding: Protect advertising budgets by proactively blocking clicks and installs from known emulators, ensuring that ad spend reaches real potential customers, not fraudulent bots.
• Data Integrity: Ensure marketing analytics and user acquisition data are clean and accurate. By filtering out emulator traffic, businesses can make better strategic decisions based on real user behavior and campaign performance.
• ROAS Improvement: Improve Return On Ad Spend (ROAS) by eliminating wasteful spending on fraudulent interactions. This leads to lower customer acquisition costs and higher conversion rates from genuine traffic sources.
• Publisher Quality Control: For ad networks, identifying emulated traffic helps in vetting and removing fraudulent publishers from their platform, maintaining the network’s integrity and value for advertisers.

Example 1: IP and Geolocation Mismatch Rule

// Use Case: Filter out traffic where the IP address location (likely a data center)
// does not match the device's reported language or timezone.

FUNCTION validateGeo(request):
  ip_info = getIPInfo(request.ip) // Returns {country, type}
  device_info = request.getDeviceProperties() // Returns {language, timezone}

  // Block known data center traffic
  IF ip_info.type == "DATA_CENTER":
    RETURN "BLOCK"

  // Flag inconsistencies between IP country and device language
  IF ip_info.country == "Vietnam" AND device_info.language == "en-US":
    RETURN "FLAG_FOR_REVIEW"
  
  RETURN "ALLOW"

Example 2: Session Fraud Scoring

// Use Case: Score each user session based on multiple risk factors.
// Sessions exceeding a certain score are blocked automatically.

FUNCTION getFraudScore(session):
  score = 0
  
  IF session.isFromKnownEmulator():
    score += 50
  
  IF session.ip.isDataCenterIP():
    score += 20
    
  IF session.behavior.isRobotic(): // e.g., clicks too fast
    score += 15
    
  IF session.device.hasSensorMismatch():
    score += 15

  RETURN score

// Implementation
user_session = getCurrentSession()
fraud_score = getFraudScore(user_session)

IF fraud_score >= 50:
  blockRequest()
ELSE:
  allowRequest()

🐍 Python Code Examples

This function checks if a given user agent string contains keywords commonly associated with Android emulators. It provides a simple, signature-based method for filtering out traffic from known developer tools that are often repurposed for ad fraud.

def is_known_emulator(user_agent):
    """
    Checks for common emulator footprints in a user agent string.
    """
    emulator_signatures = ["Genymotion", "sdk_gphone", "BlueStacks", "NoxPlayer"]
    for signature in emulator_signatures:
        if signature in user_agent:
            return True
    return False

# Example usage:
ua_string = "Mozilla/5.0 (Linux; Android 10; sdk_gphone_x86) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Mobile Safari/537.36"
if is_known_emulator(ua_string):
    print("Emulator detected.")

This function analyzes a list of click timestamps from a single user or IP to detect unnaturally frequent clicks. By setting a minimum time threshold between clicks, it can effectively identify and flag automated scripts designed to generate high volumes of fraudulent clicks.

import time

def has_abnormal_click_frequency(click_timestamps, time_window_sec=10, max_clicks=5):
    """
    Detects if more than `max_clicks` occurred within a `time_window_sec`.
    `click_timestamps` should be a list of sorted unix timestamps.
    """
    if len(click_timestamps) < max_clicks:
        return False

    # Check the time difference between a click and the click `max_clicks-1` positions before it
    for i in range(len(click_timestamps) - max_clicks + 1):
        if click_timestamps[i + max_clicks - 1] - click_timestamps[i] < time_window_sec:
            return True
            
    return False

# Example usage:
clicks =
if has_abnormal_click_frequency(clicks):
    print("Fraudulent click frequency detected.")

Types of Emulated devices

• Standard SDK Emulators: These are official software tools, such as those from Android Studio or Xcode, designed for developers to test apps. Fraudsters abuse these legitimate tools by running them on servers to generate fake traffic, often leaving behind recognizable software fingerprints.
• Custom-Built Emulators: More sophisticated fraudsters use custom-developed emulators designed specifically to avoid detection. These tools are engineered to better mimic real device hardware and software properties, making them harder to identify than standard, off-the-shelf emulators.
• Headless Browsers: While not full device emulators, headless browsers (like Puppeteer or Selenium) can be scripted to simulate mobile browsers and user interactions. They are often used for simpler click fraud schemes where a full device OS simulation is not required.
• Device Spoofing: This technique involves altering device parameters within data packets sent to the ad server to impersonate a legitimate device, without actually emulating the entire device. It's a lightweight form of fraud used to disguise the true origin of traffic, often coming from servers.

How Encrypted DNS Traffic Works

User Click on Ad
        │
        ▼
   [ DNS Query ] ───────────→ Encrypted via DoH/DoT Protocol
                                    │
                                    ▼
+-----------------------------------+
|   Traffic Protection System       |
|  (Analyzes DNS Metadata & TLS)    |
+-----------------------------------+
        │
        ├─► [Rule: High-Risk Resolver?] → Yes → [BLOCK]
        │
        ├─► [Rule: Geo-Mismatch?] ──────→ Yes → [BLOCK]
        │
        ├─► [Rule: Bot-like Pattern?]──→ Yes → [BLOCK]
        │
        ▼
     [ALLOW]
        │
        ▼
Legitimate DNS Resolution → [Landing Page]

🧠 Core Detection Logic

Example 1: DNS Resolver Reputation Check

This logic identifies fraudulent traffic by checking the source of the DNS query. Bots often run in data centers, not on residential devices. This code checks if the IP address of the DNS resolver used for the click belongs to a known data center, which is a strong signal of non-human traffic.

FUNCTION check_resolver_reputation(resolver_ip):
  // List of ASNs known to belong to data centers/hosting providers
  DATACENTER_ASN_LIST = ["ASN15169", "ASN16509", "ASN396981"]

  resolver_asn = get_asn(resolver_ip)

  IF resolver_asn IN DATACENTER_ASN_LIST:
    RETURN "fraudulent"
  ELSE:
    RETURN "legitimate"
  END IF
END FUNCTION

Example 2: Session Heuristics and Geo Mismatch

This logic detects fraud by finding inconsistencies in a user’s session data. A real user’s IP address and their DNS resolver are typically in the same country. A mismatch often indicates the use of a proxy or VPN to disguise traffic, a common tactic in sophisticated bot attacks.

FUNCTION check_geo_mismatch(user_ip, resolver_ip):
  user_country = get_country_from_ip(user_ip)
  resolver_country = get_country_from_ip(resolver_ip)

  IF user_country != resolver_country:
    // Flag for further analysis or block immediately
    RETURN "suspicious_geo_mismatch"
  ELSE:
    RETURN "ok"
  END IF
END FUNCTION

Example 3: TLS Fingerprinting (JA3/JARM)

This logic identifies the client application that made the encrypted request. Different applications (browsers, bots) create unique TLS handshake signatures. By matching the signature (known as a JA3 or JARM hash) against a database of known bot tools, this logic can detect non-human traffic without decrypting the payload.

FUNCTION analyze_tls_fingerprint(tls_handshake_data):
  // Database of fingerprints from known botnets and automation tools
  KNOWN_BOT_FINGERPRINTS = ["e7d4f1a2...", "a4f6b3c8...", "f9e1d0g7..."]

  client_fingerprint = generate_jarm_hash(tls_handshake_data)

  IF client_fingerprint IN KNOWN_BOT_FINGERPRINTS:
    RETURN "bot_detected"
  ELSE:
    RETURN "human_traffic"
  END IF
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding: Actively filter out invalid traffic originating from data centers and known proxies by analyzing DNS resolver information, directly protecting ad budgets from being wasted on non-human interactions.
• Data Integrity: Ensure marketing analytics are based on real human behavior. By weeding out bot-driven sessions at the DNS level, businesses can trust their conversion rates, user engagement metrics, and site statistics.

–

• Return on Ad Spend (ROAS) Improvement: Increase campaign efficiency by ensuring ads are served only to legitimate users. Blocking fraudulent clicks at the earliest stage means that ad spend is concentrated on audiences with real conversion potential.

–

• Blocking Sophisticated Bots: Identify and block advanced bots that mimic human behavior. Techniques like TLS fingerprinting can unmask automated clients even when their IP addresses appear legitimate, protecting against complex fraud schemes.

Example 1: Geolocation Mismatch Rule

This rule is used to automatically flag or block clicks where the user’s apparent location (from their IP address) is different from their DNS resolver’s location. This is a common indicator of proxy or VPN usage, which is often employed to commit ad fraud.

RULE ad_traffic_filter_geo_mismatch
  WHEN
    click.user_ip.country != click.dns_resolver.country
  THEN
    BLOCK TRAFFIC
    REASON "Geographic mismatch between user and DNS resolver."
END RULE

Example 2: Session Scoring with DNS Reputation

This logic assigns a risk score to an incoming click based on multiple factors, including the reputation of the DNS resolver. If the resolver is associated with a data center or known for malicious activity, the risk score increases, potentially leading to the click being invalidated.

FUNCTION calculate_risk_score(click_event):
  score = 0
  
  // Check if DNS resolver is from a known datacenter
  IF is_datacenter_ip(click_event.dns_resolver.ip):
    score += 50
  
  // Check if resolver is on a threat intelligence blocklist
  IF is_on_blocklist(click_event.dns_resolver.ip):
    score += 30

  // Check for geo mismatch
  IF click_event.user_ip.country != click_event.dns_resolver.country:
    score += 20

  RETURN score
END FUNCTION

🐍 Python Code Examples

This Python function simulates checking a DNS resolver’s IP address against a predefined blocklist of IPs known to be associated with data centers or malicious actors. This is a primary step in filtering out non-human traffic from ad campaigns.

# A list of known fraudulent or non-human IP addresses (e.g., from data centers)
DNS_RESOLVER_BLOCKLIST = {
    "8.8.8.8",  # Example: Google DNS (often legitimate, but used for illustration)
    "1.1.1.1",  # Example: Cloudflare DNS
    "208.67.222.222", # Example: OpenDNS
    "94.140.14.14" # AdGuard DNS
}

def filter_by_resolver_blocklist(resolver_ip: str) -> bool:
    """
    Checks if the resolver IP is in a known blocklist.
    Returns True if the IP should be blocked, False otherwise.
    """
    if resolver_ip in DNS_RESOLVER_BLOCKLIST:
        print(f"FLAGGED: Resolver {resolver_ip} is on the blocklist.")
        return True
    print(f"OK: Resolver {resolver_ip} is not on the blocklist.")
    return False

# --- Simulation ---
suspicious_click_resolver = "94.140.14.14"
legitimate_click_resolver = "192.168.1.1" # A typical local resolver

filter_by_resolver_blocklist(suspicious_click_resolver)
filter_by_resolver_blocklist(legitimate_click_resolver)

This code analyzes session data to detect anomalies that suggest fraudulent activity. By comparing the geographic location derived from the user’s IP address with the location of the DNS resolver, it can flag sessions where a significant mismatch might indicate the use of a proxy or botnet.

# In a real system, this would use a GeoIP database.
# Here we simulate it with a dictionary.
IP_GEO_DATABASE = {
    "81.2.69.142": "UK", # User IP
    "208.67.222.222": "USA", # DNS Resolver IP
    "195.46.39.39": "DE" # Another DNS Resolver IP
}

def detect_geo_mismatch(user_ip: str, resolver_ip: str) -> bool:
    """
    Compares the country of the user IP and the DNS resolver IP.
    Returns True if a mismatch is detected, False otherwise.
    """
    user_country = IP_GEO_DATABASE.get(user_ip)
    resolver_country = IP_GEO_DATABASE.get(resolver_ip)

    if not user_country or not resolver_country:
        print("Could not determine location for one or both IPs.")
        return False

    if user_country != resolver_country:
        print(f"FRAUD ALERT: Mismatch found! User in {user_country}, Resolver in {resolver_country}.")
        return True
    
    print(f"OK: User and resolver are both in {user_country}.")
    return False

# --- Simulation ---
# Scenario 1: A fraudulent click with a geo-mismatch
detect_geo_mismatch("81.2.69.142", "208.67.222.222")

# Scenario 2: A legitimate click
detect_geo_mismatch("81.2.69.142", "195.46.39.39")

Types of Encrypted DNS Traffic

• DNS over TLS (DoT): This method wraps DNS queries in the Transport Layer Security protocol and sends them over a dedicated port (853). In fraud detection, its use of a distinct port makes DoT traffic identifiable, allowing security systems to isolate and analyze it for anomalies without needing to inspect other web traffic.
• DNS over HTTPS (DoH): This type encapsulates DNS queries within standard HTTPS traffic on port 443. This makes DNS requests indistinguishable from normal browsing activity, helping bots evade detection. For security, this means fraud analysis must rely on other signals, like TLS fingerprinting or the resolver’s reputation, to identify malicious clients.
• DNSCrypt: An earlier protocol that encrypts and authenticates DNS traffic between a user and their resolver. While less common than DoT or DoH, its presence can be a signal for analysis. Fraud detection systems can profile clients using DNSCrypt to identify patterns associated with specific tools or botnets.
• Private Relay: Apple’s implementation that uses a dual-hop architecture to separate a user’s IP address from their DNS query. While designed for privacy, scammers have been found spoofing Private Relay traffic to commit ad fraud. Detection requires identifying inconsistencies between traffic claiming to be from Private Relay and its actual technical signatures.

How Endpoint Protection Works

User Device (Endpoint)
        │
        ├─▶ Ad Click Event
        │
        └─▶ Data Collection (IP, User Agent, Behavior)
                        │
                        ▼
+---------------------------------------+
|         Traffic Security System         |
|                   │                     |
|                   ▼                     |
|           Analysis Engine             |
|  ┌─────────────────────────────────┐  |
|  │ Heuristics & Behavioral Rules   │  |
|  │ Signature & IP Reputation Match │  |
|  │ Anomaly & Pattern Detection     │  |
|  └─────────────────────────────────┘  |
|                   │                     |
+-------------------|---------------------+
                    │
                    ▼
          ┌─────────┴─────────┐
          │  Fraud Assessment │
          └─────────┬─────────┘
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
   Allow Click             Block Click
 (Legitimate)            (Fraudulent)

🧠 Core Detection Logic

Example 1: IP Filtering and Reputation

This logic checks the source IP address of a click against known blacklists containing IPs associated with data centers, proxies, and VPNs, which are often used to mask fraudulent activity. It serves as a foundational layer of defense by blocking traffic from sources that have no legitimate reason to be clicking on consumer-facing ads.

FUNCTION checkIP(ip_address):
  IF ip_address IN data_center_blacklist:
    RETURN "BLOCK"
  
  IF ip_address IN known_proxy_list:
    RETURN "BLOCK"
  
  IF get_ip_reputation(ip_address) < 20: // Score out of 100
    RETURN "FLAG_FOR_REVIEW"
  
  RETURN "ALLOW"
END FUNCTION

Example 2: Session Heuristics and Click Velocity

This logic analyzes the timing and frequency of clicks within a user session to identify automated behavior. Bots often click ads much faster or at more regular intervals than a human can. This rule flags or blocks sessions with an unnaturally high click velocity, preventing budget waste from bot-driven click spam.

FUNCTION analyze_session(session_id, click_timestamp):
  clicks = get_clicks_for_session(session_id)
  
  IF count(clicks) > 5:
    first_click_time = clicks.timestamp
    time_difference = click_timestamp - first_click_time
    
    // If more than 5 clicks in under 10 seconds, block
    IF time_difference < 10:
      RETURN "BLOCK_SESSION"
      
  RECORD_CLICK(session_id, click_timestamp)
  RETURN "ALLOW"
END FUNCTION

Example 3: Geo Mismatch Detection

This logic compares the geographical location derived from the user's IP address with other available location data, such as timezone settings from the browser or language preferences. A significant mismatch—for instance, an IP from Vietnam with a system timezone set to Central US Time—can be a strong indicator of a proxy or a compromised device being used for fraud.

FUNCTION check_geo_mismatch(ip_address, browser_timezone):
  ip_geo = get_geolocation_from_ip(ip_address) // e.g., "Asia/Ho_Chi_Minh"
  
  IF ip_geo.continent != browser_timezone.continent:
    RETURN "BLOCK_GEO_MISMATCH"
    
  // Check for significant timezone offset within the same continent
  IF abs(ip_geo.offset - browser_timezone.offset) > 3_HOURS:
    RETURN "BLOCK_GEO_MISMATCH"
    
  RETURN "ALLOW"
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding – Prevents invalid clicks from depleting PPC budgets on platforms like Google Ads and Meta Ads, ensuring that ad spend is directed toward genuine potential customers.
• Analytics Integrity – Filters out non-human and fraudulent traffic before it pollutes website analytics, providing a cleaner and more accurate view of true user engagement, conversion rates, and campaign performance.
• Return on Ad Spend (ROAS) Improvement – By blocking wasteful clicks from bots and competitors, Endpoint Protection increases the proportion of budget spent on valuable traffic, directly improving campaign efficiency and ROAS.
• Lead Generation Quality Control – Ensures that forms and lead submissions are filled out by real people, not bots, which saves sales teams time and resources by preventing them from chasing fake leads.

Example 1: Geofencing Rule

A business targeting customers only in Canada can use a geofencing rule to automatically block any clicks originating from IP addresses outside of its target country, protecting its budget from irrelevant international traffic.

// Rule: Geofence for "Canada Only" Campaign
FUNCTION handle_request(request):
  user_ip = request.ip_address
  user_country = get_country_from_ip(user_ip)
  
  IF user_country != "CA":
    // Block the click before it consumes the ad budget
    BLOCK_CLICK(reason="Outside target geography")
    RETURN
  
  // Allow click to proceed to the landing page
  PROCESS_CLICK(request)
END FUNCTION

Example 2: Session Scoring Logic

This logic assesses multiple data points from a user's session to generate a "fraud score." A high score indicates likely fraud and results in the click being blocked. This provides a more nuanced approach than relying on a single data point.

// Rule: Calculate fraud score based on multiple factors
FUNCTION calculate_fraud_score(session_data):
  score = 0
  
  IF session_data.ip_type == "Data Center":
    score += 50
    
  IF session_data.user_agent IN known_bot_signatures:
    score += 40
    
  IF session_data.time_on_page < 2_SECONDS:
    score += 10
    
  // A score of 60 or higher is considered fraudulent
  IF score >= 60:
    RETURN "BLOCK_HIGH_FRAUD_SCORE"
  ELSE:
    RETURN "ALLOW"
END FUNCTION

🐍 Python Code Examples

This function simulates checking a click's IP address against a predefined blacklist of fraudulent IPs. This is a common first-line defense in stopping known bad actors or traffic from data centers, which is often associated with bot activity.

# A set of known fraudulent IP addresses
FRAUDULENT_IPS = {"198.51.100.1", "203.0.113.24", "192.0.2.15"}

def filter_by_ip_blacklist(click_ip):
    """Blocks a click if its IP is in the fraudulent list."""
    if click_ip in FRAUDULENT_IPS:
        print(f"Blocking click from fraudulent IP: {click_ip}")
        return False
    print(f"Allowing click from IP: {click_ip}")
    return True

# Example usage:
filter_by_ip_blacklist("203.0.113.24")
filter_by_ip_blacklist("8.8.8.8")

This example demonstrates a function to analyze click frequency from a single source. If an IP address generates an excessive number of clicks in a very short time frame, it is flagged as bot-like behavior and subsequent clicks are blocked.

from collections import defaultdict
import time

CLICK_LOG = defaultdict(list)
TIME_WINDOW_SECONDS = 10
CLICK_THRESHOLD = 5

def is_click_frequency_abnormal(ip_address):
    """Checks if click frequency from an IP is too high."""
    current_time = time.time()
    
    # Filter out clicks older than the time window
    CLICK_LOG[ip_address] = [t for t in CLICK_LOG[ip_address] if current_time - t < TIME_WINDOW_SECONDS]
    
    # Add the current click timestamp
    CLICK_LOG[ip_address].append(current_time)
    
    # Check if click count exceeds the threshold
    if len(CLICK_LOG[ip_address]) > CLICK_THRESHOLD:
        print(f"Abnormal click frequency detected from {ip_address}. Blocking.")
        return True
        
    print(f"Normal click frequency from {ip_address}.")
    return False

# Example usage:
for _ in range(6):
    is_click_frequency_abnormal("10.0.0.1")

Types of Endpoint Protection

• Client-Side (JavaScript-Based) Protection

  This type uses a JavaScript tag deployed on the website or landing page. It collects rich data directly from the user's browser, including behavioral biometrics like mouse movements, screen resolution, and browser properties. This method is highly effective at detecting sophisticated bots that can mimic human traffic.

• Server-Side Protection

  This method analyzes request data at the server level when a click is received. It inspects HTTP headers, IP addresses, and other network-level information to identify signs of fraud. While less detailed than client-side analysis, it is fast and effective for catching obvious bots, proxies, and data center traffic.

• Hybrid Protection

  This approach combines both client-side and server-side techniques for the most comprehensive defense. It correlates data collected from the user's browser with server-level request information, creating a highly detailed profile of the user to make extremely accurate decisions about traffic validity and block advanced threats.

How Engagement Metrics Works

User Click → [ Data Collection ] → [ Real-Time Analysis ] → [ Scoring Engine ] → Decision
                  │                    │                     │                   └─┬─→ (Block IP)
                  │                    │                     │                     └─┬─→ (Flag for Review)
                  │                    │                     └─(Low Score)─────→ (Allow)
                  │                    └─(Behavioral Patterns)
                  └─(IP, UA, Timestamps)

🧠 Core Detection Logic

Example 1: Session Engagement Scoring

This logic assesses the quality of a user session by combining multiple engagement signals. It moves beyond a single metric (like time on page) to create a more holistic view, making it harder for simple bots to achieve a “passing” score. It is a foundational element in behavioral-based fraud detection.

FUNCTION calculate_engagement_score(session):
  score = 0
  
  // Rule 1: Time on page
  IF session.time_on_page > 3 SECONDS THEN score += 10
  IF session.time_on_page > 15 SECONDS THEN score += 20

  // Rule 2: Scroll activity
  IF session.scroll_depth > 25% THEN score += 25
  IF session.scroll_depth < 5% AND session.time_on_page > 10 SECONDS THEN score -= 15

  // Rule 3: Mouse movement
  IF session.has_mouse_movement = TRUE THEN score += 20
  ELSE score -= 30 // Penalize sessions with no mouse activity

  // Rule 4: Clicks on page
  IF session.internal_clicks > 0 THEN score += 15
  
  RETURN score

Example 2: Click Timestamp Anomaly Detection

This logic identifies non-human speed by analyzing the time between a page loading and the first significant user action (like a click). Bots often act instantly, much faster than a real person can read and decide. This check is crucial for catching automated scripts that trigger clicks programmatically.

FUNCTION check_timestamp_anomaly(click_event):
  time_since_pageload = click_event.timestamp - page.load_timestamp
  
  // A human needs time to orient and click.
  IF time_since_pageload < 1.5 SECONDS:
    RETURN "FLAG_AS_SUSPICIOUS"
  
  // Check for rapid-fire clicks from the same source.
  last_click_time = get_last_click_time(click_event.source_ip)
  time_since_last_click = click_event.timestamp - last_click_time
  
  IF time_since_last_click < 2.0 SECONDS:
    RETURN "FLAG_AS_REPETITIVE_BOT_ACTIVITY"

  update_last_click_time(click_event.source_ip, click_event.timestamp)
  RETURN "VALID_CLICK"

Example 3: Behavioral Path Analysis

This logic evaluates the user's navigation path after the initial click. Legitimate users often explore a site, visiting multiple pages. Bots, especially those designed only for click fraud, typically land on one page and leave (a high bounce rate). This helps distinguish between curious visitors and single-interaction fraudulent clicks.

FUNCTION analyze_navigation_path(session):
  
  // High bounce rate with minimal interaction is a red flag.
  IF session.pages_visited = 1 AND session.time_on_page < 5 SECONDS:
    RETURN "HIGH_PROBABILITY_FRAUD"

  // Legitimate users often follow a logical path.
  IF session.path CONTAINS "Homepage" -> "Pricing" -> "Contact":
    session.trust_score += 20
    RETURN "ORGANIC_BEHAVIOR_DETECTED"
    
  // Erratic, non-logical navigation can be suspicious.
  IF session.path CONTAINS "Contact" -> "About Us" -> "Privacy Policy" IN < 10 SECONDS:
    session.trust_score -= 10
    RETURN "SUSPICIOUS_NAVIGATION_PATTERN"

  RETURN "ANALYSIS_INCONCLUSIVE"

📈 Practical Use Cases for Businesses

• PPC Budget Protection – Prevents bots and competitors from clicking on paid ads, ensuring that advertising spend is used to attract real customers and not wasted on fraudulent traffic.
• Lead Generation Filtering – Analyzes user behavior on lead submission forms to filter out fake or automated sign-ups, improving the quality of sales and marketing leads.
• Affiliate Fraud Prevention – Monitors traffic from affiliate channels to ensure they are driving genuine, engaged users, rather than generating fake clicks or conversions to earn commissions.
• Analytics Data Cleansing – Ensures that website analytics (like user counts, session duration, and bounce rate) reflect real user behavior by filtering out contaminating bot traffic.
• E-commerce Security – Protects against automated threats like inventory hoarding bots or fraudulent account creation by verifying that users exhibit human-like engagement patterns before allowing critical actions.

Example 1: Geofencing and Engagement Rule

This logic protects a local business's ad campaign by ensuring clicks not only come from the target country but also show genuine engagement. It filters out low-quality international traffic and disengaged local clicks.

FUNCTION screen_local_ad_click(click):
  
  // Rule 1: Geolocation Check
  IF click.country != "USA":
    block_and_log(click.ip, "GEO_MISMATCH")
    RETURN

  // Rule 2: Engagement Check for allowed geos
  wait_for_engagement_data(click.session_id, timeout=15)
  engagement_score = get_session_score(click.session_id)

  IF engagement_score < 30: // 30 is the minimum threshold
    block_and_log(click.ip, "LOW_ENGAGEMENT_SCORE")
  ELSE:
    approve_and_log(click.ip, "VALID_TRAFFIC")

Example 2: Session Scoring for High-Value Keywords

This pseudocode demonstrates a strategy for protecting bids on expensive keywords. It applies stricter engagement criteria to traffic from high-cost ad groups to minimize financial losses from sophisticated bots.

FUNCTION validate_high_value_click(click, session):
  
  // Expensive keywords require higher proof of legitimacy.
  MIN_REQUIRED_SCORE = 75 
  
  // Analyze deep engagement signals.
  score = 0
  score += analyze_mouse_dynamics(session.mouse_events) // e.g., velocity, curvature
  score += analyze_scroll_behavior(session.scroll_events) // e.g., speed, pauses
  score += analyze_interaction_timing(session.events) // time between actions

  IF score < MIN_REQUIRED_SCORE:
    add_to_blocklist(click.ip_address)
    report_invalid_click_to_ad_platform(click.id)
    RETURN "FRAUDULENT"
  
  RETURN "LEGITIMATE"

🐍 Python Code Examples

This function simulates a basic check for abnormally high click frequency from a single IP address. Tracking clicks over time helps identify automated scripts that repeatedly hit ads faster than a human could, which is a common pattern in click fraud.

# Dictionary to store the last click timestamp for each IP
CLICK_HISTORY = {}
# Time in seconds
MIN_TIME_BETWEEN_CLICKS = 5.0 

def is_click_too_frequent(ip_address: str) -> bool:
    import time
    current_time = time.time()
    
    if ip_address in CLICK_HISTORY:
        last_click_time = CLICK_HISTORY[ip_address]
        if (current_time - last_click_time) < MIN_TIME_BETWEEN_CLICKS:
            # Flag as suspicious if clicks are too close together
            return True
            
    # Record the current click time for this IP
    CLICK_HISTORY[ip_address] = current_time
    return False

# --- Simulation ---
print(f"Click 1 from 192.168.1.1: {'Suspicious' if is_click_too_frequent('192.168.1.1') else 'OK'}")
# Simulating a rapid second click
print(f"Click 2 from 192.168.1.1: {'Suspicious' if is_click_too_frequent('192.168.1.1') else 'OK'}")

This example demonstrates how to score a user session based on simple engagement metrics. By combining time spent on a page with scroll depth, it creates a more robust indicator of genuine interest than either metric alone, helping to filter out low-quality or fraudulent traffic.

def get_session_engagement_score(time_on_page_sec: int, scroll_depth_percent: int) -> int:
    """
    Calculates a simple engagement score.
    A score below 50 might be considered low engagement or a bot.
    """
    score = 0

    # Award points for time spent on the page
    if time_on_page_sec > 5:
        score += 30
    if time_on_page_sec > 20:
        score += 40

    # Award points for scrolling
    if scroll_depth_percent > 30:
        score += 30
    
    # Penalize for quick bounce with no scrolling
    if time_on_page_sec < 4 and scroll_depth_percent < 10:
        score = 0
        
    return min(score, 100) # Cap score at 100

# --- Simulation ---
# Good user
score1 = get_session_engagement_score(time_on_page_sec=35, scroll_depth_percent=70)
print(f"Engaged User Score: {score1} -> {'Likely Human' if score1 > 50 else 'Likely Bot'}")

# Bot or uninterested user
score2 = get_session_engagement_score(time_on_page_sec=2, scroll_depth_percent=0)
print(f"Bounce User Score: {score2} -> {'Likely Human' if score2 > 50 else 'Likely Bot'}")

Types of Engagement Metrics

• Behavioral Metrics – These metrics track the physical actions a user takes on a page. This includes mouse movement patterns, scroll depth, click heatmaps, and typing cadence. They are powerful for detecting bots, as non-human interactions often lack the natural variation and randomness of human behavior.
• Time-Based Metrics – This category measures user commitment through time. Key examples include average session duration, time on page, and the interval between clicks. Unusually short or long durations can be red flags; for instance, a bot might spend less than a second on a page before "bouncing."
• Interaction Metrics – These metrics focus on how deeply a user navigates a site after the initial landing. This includes pages per session, click-path analysis, and interaction with dynamic elements like forms or videos. A visitor who only ever views one page is statistically more likely to be fraudulent.
• Conversion Metrics – While also a business KPI, conversion data is a critical engagement signal. Low conversion rates paired with high click-through rates can indicate that the traffic is not genuine. This analysis helps identify sources that deliver clicks but no real customers.

How Event Logs Works

User Click → [Ad Server] → Generates Event Log (IP, Timestamp, User-Agent, etc.)
               │
               └─ Log Ingestion → [Fraud Detection System]
                                     │
                                     ├─ 1. Rule-Based Filtering (e.g., IP Blacklist)
                                     ├─ 2. Behavioral Analysis (e.g., Click Velocity)
                                     ├─ 3. Heuristic Scoring
                                     │
                                     └─ Decision → [Block/Flag] or [Allow]

🧠 Core Detection Logic

Example 1: Repetitive Click Velocity Rule

This logic identifies non-human behavior by tracking the rate of clicks from a single IP address. A sudden burst of clicks in a short period is a strong indicator of an automated script or bot. This rule is a fundamental part of real-time fraud filtering in the traffic protection pipeline.

FUNCTION check_click_velocity(event):
  ip_address = event.ip
  timestamp = event.timestamp
  
  // Get historical clicks for this IP
  recent_clicks = get_clicks_by_ip(ip_address, last_60_seconds)
  
  IF count(recent_clicks) > 10 THEN
    // More than 10 clicks in 60 seconds is suspicious
    mark_as_fraud(event, "High Click Velocity")
    RETURN "FRAUD"
  ELSE
    record_click(ip_address, timestamp)
    RETURN "VALID"
  END IF

Example 2: Geographic Mismatch Heuristic

This logic flags clicks as suspicious when the user’s IP address location is inconsistent with the targeted geographic area of the ad campaign. It is particularly useful for campaigns with specific regional targets and helps prevent budget waste on irrelevant or fraudulent international traffic.

FUNCTION check_geo_mismatch(event, campaign):
  ip_address = event.ip
  click_country = get_country_from_ip(ip_address)
  campaign_target_countries = campaign.target_geo
  
  IF click_country NOT IN campaign_target_countries THEN
    // Click from outside the campaign's intended region
    score = get_fraud_score(event)
    set_fraud_score(event, score + 20) // Add penalty points
    flag_for_review(event, "Geographic Mismatch")
    RETURN "SUSPICIOUS"
  ELSE
    RETURN "VALID"
  END IF

Example 3: Data Center & Proxy Detection

This logic checks if the click originates from a known data center, server, or public proxy IP address instead of a residential or mobile network. Since legitimate users rarely browse from data centers, such traffic is often classified as non-human or bot-driven and is blocked pre-emptively.

FUNCTION is_from_datacenter(event):
  ip_address = event.ip
  
  // Check against a database of known data center IP ranges
  is_datacenter_ip = check_ip_in_datacenter_db(ip_address)
  
  IF is_datacenter_ip IS TRUE THEN
    // Clicks from servers are almost always bots
    mark_as_fraud(event, "Data Center Origin")
    block_ip(ip_address)
    RETURN "FRAUD"
  ELSE
    RETURN "VALID"
  END IF

📈 Practical Use Cases for Businesses

• Campaign Shielding: Event logs are used to create rules that automatically block traffic from known fraudulent sources, shielding active campaigns from budget-draining activities like bot clicks or competitor sabotage.
• Analytics Purification: By filtering out fraudulent events, businesses ensure their marketing analytics reflect genuine user engagement. This leads to more accurate performance metrics, like click-through and conversion rates, and smarter strategic decisions.
• ROAS Optimization: By preventing ad spend on fake clicks, event log analysis directly improves Return on Ad Spend (ROAS). Budgets are focused on legitimate audiences with real purchasing potential, maximizing the financial return of advertising efforts.
• Publisher Quality Vetting: Businesses analyze event logs from different publishers or traffic sources to identify which ones deliver the highest quality, fraud-free traffic, allowing them to allocate future ad spend more effectively.

Example 1: Geofencing Rule

A business running a campaign targeted only at users in Canada can use event logs to enforce a strict geofencing rule, instantly blocking any click originating from an IP address outside of its target country.

// Rule: Geofence for "Canada Only" Campaign
IF event.campaign_id == "CAN-Summer-Sale" AND 
   get_country_from_ip(event.ip) != "CA"
THEN
  ACTION: BLOCK
  REASON: "Out-of-geo traffic"
END IF

Example 2: Session Authenticity Scoring

To ensure traffic is human, a business can score sessions based on behavior recorded in event logs. A session with an abnormally short duration between click and bounce (e.g., less than 1 second) receives a high fraud score.

// Logic: Score session based on engagement time
session_duration = event.timestamp_exit - event.timestamp_click

IF session_duration < 1000 // duration in milliseconds
THEN
  session.fraud_score += 50 // Add 50 points to fraud score
  REASON: "Implausible session duration"
END IF

Example 3: User Agent Signature Match

A business identifies a pattern of fraudulent clicks coming from an outdated or unusual browser user-agent. It creates a rule to block all future traffic matching that specific signature to prevent further abuse.

// Rule: Block known bad bot user agent
UA_SIGNATURE = "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

IF event.user_agent == UA_SIGNATURE
THEN
  ACTION: BLOCK
  REASON: "Matched known bot signature"
END IF

🐍 Python Code Examples

This code demonstrates how to filter a list of event logs to identify and remove entries originating from known fraudulent IP addresses, a common first step in cleaning traffic data.

# List of known fraudulent IP addresses
BLACKLISTED_IPS = {"198.51.100.24", "203.0.113.15", "192.0.2.88"}

def filter_blacklisted_ips(event_logs):
    """Filters out logs from blacklisted IP addresses."""
    clean_logs = []
    for event in event_logs:
        if event.get("ip_address") not in BLACKLISTED_IPS:
            clean_logs.append(event)
    return clean_logs

# Example Usage:
logs = [
    {"click_id": 1, "ip_address": "8.8.8.8"},
    {"click_id": 2, "ip_address": "203.0.113.15"}, # blacklisted
    {"click_id": 3, "ip_address": "9.9.9.9"}
]
print(f"Clean logs: {filter_blacklisted_ips(logs)}")

This example shows a function to detect abnormally high click frequency from a single source, a strong indicator of bot activity. It groups clicks by IP and flags those exceeding a defined threshold within a short time window.

from collections import defaultdict

def detect_high_frequency_clicks(event_logs, threshold=10, time_window_sec=60):
    """Detects IPs with an abnormally high number of clicks in a time window."""
    ip_clicks = defaultdict(list)
    fraudulent_ips = set()

    for event in sorted(event_logs, key=lambda x: x['timestamp']):
        ip = event['ip_address']
        ts = event['timestamp']
        
        # Keep clicks within the time window
        ip_clicks[ip] = [t for t in ip_clicks[ip] if ts - t < time_window_sec]
        ip_clicks[ip].append(ts)
        
        if len(ip_clicks[ip]) > threshold:
            fraudulent_ips.add(ip)
            
    return fraudulent_ips

# Example (timestamps as simple integers for clarity)
logs = [
    {'ip_address': '1.2.3.4', 'timestamp': 1}, {'ip_address': '1.2.3.4', 'timestamp': 2},
    {'ip_address': '1.2.3.4', 'timestamp': 3}, {'ip_address': '1.2.3.4', 'timestamp': 15} 
    # Assume 12 more clicks for 1.2.3.4 here to exceed threshold
]
print(f"Fraudulent IPs: {detect_high_frequency_clicks(logs, threshold=3)}")

Types of Event Logs

• Raw Click Logs: This is the most fundamental type of event log, containing unprocessed data captured directly from an ad server or click tracker. It includes essential fields like IP address, user-agent string, timestamp, and publisher ID, forming the primary evidence for any fraud investigation.
• Impression Logs: These logs record every instance an ad is displayed to a user, even if not clicked. They are crucial for detecting impression fraud and for calculating accurate click-through rates (CTRs), as an abnormally high CTR can indicate click fraud.
• Conversion Logs: Tracking events post-click, such as a purchase or a form submission, conversion logs help identify click fraud that generates fake clicks but no valuable actions. A high volume of clicks with zero conversions from a source is a major red flag.
• Enriched Event Logs: This refers to raw logs that have been augmented with additional data from third-party sources. For example, an IP address might be enriched with geographic location, ISP information, or whether it is a known proxy or data center, providing more context for fraud detection algorithms.
• Session Replay Logs: These logs capture a detailed sequence of user interactions within a session, such as mouse movements, scrolls, and time spent on a page. While resource-intensive, they are highly effective at distinguishing between human and bot behavior by analyzing interaction patterns.

How Event Risk Management Works

  User Event     │        Data Pipeline         │      Decision Engine
┌───────────┐    │                              │      ┌───────────────┐
│ Ad Click  │───→│ Data Collection & Ingestion ] │───→│ Risk Score  │
└───────────┘    │        (IP, UA, Time)      │      │     (0-100)     │
                 │              ↓               │      └───────┬───────┘
                 │                              │              ↓
                 │ Analysis & Correlation  ] │      ┌───────────────┐
                 │    (Behavior, History)      │      │ Action      │
                 └──────────────────────────────┘      │ (Allow/Block) │
                                                       └───────────────┘

🧠 Core Detection Logic

Example 1: Click Frequency Analysis

This logic tracks how many times a single IP address clicks on an ad in a given timeframe. It is a frontline defense against basic bots and click farms that often use the same source to generate numerous invalid clicks. By setting a reasonable threshold, it filters out abnormally high-frequency behavior.

FUNCTION checkClickFrequency(event):
  ip = event.ipAddress
  timeframe = 60 // seconds
  maxClicks = 5

  // Get recent click timestamps for this IP
  clicks = getClicksByIP(ip, within=timeframe)

  IF count(clicks) > maxClicks:
    RETURN "FRAUDULENT"
  ELSE:
    RETURN "VALID"
  ENDIF

Example 2: Session Heuristics

This logic evaluates the quality of a user session by analyzing behavior between the click and subsequent actions. A legitimate user typically spends time on the landing page, whereas a bot might “bounce” immediately. A very short session duration is a strong indicator of non-human or uninterested traffic.

FUNCTION analyzeSession(session):
  landingTime = session.pageLoadTime
  exitTime = session.exitTime
  minDuration = 2 // seconds

  duration = exitTime - landingTime

  IF duration < minDuration:
    // User left almost instantly
    score = 80 // High risk score
    RETURN score
  ELSE:
    score = 10 // Low risk score
    RETURN score
  ENDIF

Example 3: Geo Mismatch Detection

This logic compares the geographic location of the user's IP address with the campaign's targeting settings. Clicks originating from countries or regions that are not being targeted are a common sign of fraud, often from proxy servers or bots located in different parts of the world.

FUNCTION verifyGeoLocation(event, campaign):
  userCountry = getCountryFromIP(event.ipAddress)
  targetCountries = campaign.targetLocations

  IF userCountry NOT IN targetCountries:
    // Click is from outside the target area
    logFraud("Geo Mismatch", event)
    RETURN FALSE
  ELSE:
    RETURN TRUE
  ENDIF

📈 Practical Use Cases for Businesses

• Campaign Shielding – Prevents ad budgets from being wasted on clicks from bots, competitors, or click farms, ensuring that spend is allocated toward reaching genuine potential customers.
• Data Integrity – Keeps analytics platforms clean by filtering out non-human and fraudulent traffic. This leads to more accurate metrics like Click-Through Rate (CTR) and Conversion Rate, enabling better strategic decisions.
• Lead Quality Improvement – Blocks low-quality traffic at the source, which prevents fake sign-ups and junk leads from entering the sales funnel. This allows sales teams to focus on legitimate prospects.
• ROAS Optimization – Improves Return On Ad Spend (ROAS) by ensuring that marketing funds are spent on traffic that has a real chance of converting, thereby maximizing the effectiveness of advertising campaigns.

Example 1: Geofencing Rule

A business running a local campaign for a service only available in the United Kingdom can use a geofencing rule to automatically block all clicks originating from outside the country, saving budget and preventing irrelevant traffic.

// Rule: GE-UK-ONLY
// Description: Blocks any click not originating from the United Kingdom.

RULE "Allow UK Traffic Only"
WHEN
  event.type == "click" AND
  ip.country_code != "GB"
THEN
  BLOCK_REQUEST()
  LOG "Blocked non-UK traffic"
END

Example 2: Session Behavior Scoring

An e-commerce store can score traffic based on engagement. A user who clicks an ad and immediately leaves the landing page (bounces) receives a high-risk score, while a user who browses multiple pages receives a low-risk score, helping to identify disinterested or bot traffic.

// Logic: Session Scoring
// Description: Scores a session based on user actions post-click.

FUNCTION scoreSession(session):
  score = 0
  IF session.duration < 3 seconds:
    score += 50 // High bounce rate
  ENDIF
  IF session.pages_viewed < 2:
    score += 30 // Low engagement
  ENDIF
  IF score > 60:
    FLAG "High Risk"
  ENDIF
  RETURN score
END

🐍 Python Code Examples

This code simulates checking for rapid, repeated clicks from a single IP address within a short time window. It helps block basic bot attacks where a script generates many clicks from the same source quickly.

CLICK_LOG = {}
TIME_WINDOW = 60  # seconds
CLICK_THRESHOLD = 10

def is_frequent_click(ip_address):
    import time
    current_time = time.time()
    
    # Remove old clicks from the log
    if ip_address in CLICK_LOG:
        CLICK_LOG[ip_address] = [t for t in CLICK_LOG[ip_address] if current_time - t < TIME_WINDOW]
    
    # Add the new click
    clicks = CLICK_LOG.setdefault(ip_address, [])
    clicks.append(current_time)
    
    # Check if the number of clicks exceeds the threshold
    if len(clicks) > CLICK_THRESHOLD:
        return True
    return False

# --- Simulation ---
test_ip = "198.51.100.1"
for i in range(12):
    if is_frequent_click(test_ip):
        print(f"Click {i+1} from {test_ip}: Flagged as fraudulent.")
    else:
        print(f"Click {i+1} from {test_ip}: Allowed.")

This example demonstrates filtering incoming traffic based on its user-agent string. It checks against a predefined list of known bot or non-browser agents to prevent common automated scripts from interacting with ads.

KNOWN_BOT_AGENTS = [
    "Bot/1.0",
    "DataScraper/2.1",
    "ValidationTool/3.0"
]

def filter_by_user_agent(user_agent):
    if user_agent in KNOWN_BOT_AGENTS:
        return "BLOCKED"
    
    # More advanced check for common bot signatures
    if "bot" in user_agent.lower() or "spider" in user_agent.lower():
        return "BLOCKED"
        
    return "ALLOWED"

# --- Simulation ---
traffic_requests = [
    {"ip": "203.0.113.5", "ua": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."},
    {"ip": "198.51.100.2", "ua": "DataScraper/2.1"},
    {"ip": "203.0.113.6", "ua": "Googlebot/2.1 (+http://www.google.com/bot.html)"}
]

for req in traffic_requests:
    status = filter_by_user_agent(req["ua"])
    print(f"Traffic from {req['ip']} with UA '{req['ua']}': {status}")

Types of Event Risk Management

• Rule-Based Management – This type uses a predefined set of static rules to identify fraud. For instance, a rule might automatically block all clicks from known data center IP addresses or TOR exit nodes. It is effective against known, unsophisticated threats but lacks flexibility.
• Behavioral Analysis – This method focuses on user behavior patterns rather than static attributes. It analyzes mouse movements, session duration, and click timing to determine if the activity is human-like. This is effective against bots that have not perfected mimicking human interaction.
• Reputation-Based Filtering – This type assesses the historical reputation of an event's source, such as an IP address, device ID, or user agent. Sources that have been previously associated with fraudulent activity are given a higher risk score and may be blocked proactively.
• Heuristic Analysis – This approach uses experience-based models and algorithms to detect suspicious anomalies. For example, it might flag a click that occurs within milliseconds of an ad loading, as this is faster than a human could react. It helps identify new or evolving fraud tactics.
• Predictive Scoring – Leveraging machine learning, this type predicts the likelihood of an event being fraudulent based on vast datasets of past activity. It identifies complex, subtle patterns that other methods might miss, offering a more proactive and adaptive form of protection.

How False Positives Works

Incoming Traffic → +---------------------------+ → Legitimate User (True Negative)
 (Clicks, Impressions) │  Fraud Detection System   │
                     │  (Rules & Heuristics)     │
                     +---------------------------+
                                  │
                                  ├─→ Fraudulent User (True Positive)
                                  │
                                  └─→ Legitimate User Blocked (False Positive)

🧠 Core Detection Logic

Example 1: IP Reputation Filtering

This logic checks the incoming user’s IP address against a known database of suspicious IPs, such as those associated with data centers, proxies, or known bot networks. It’s a first-line defense to filter out obvious non-human traffic before it consumes more resources.

FUNCTION checkIpReputation(ipAddress):
  IF ipAddress IN knownBadIpList:
    RETURN "fraudulent"
  ELSE IF ipAddress IN dataCenterIpRanges:
    RETURN "suspicious"
  ELSE:
    RETURN "legitimate"
END FUNCTION

Example 2: Session Heuristics

This approach analyzes user behavior during a session, focusing on metrics like time-on-page, click frequency, and navigation patterns. Abnormally short session durations or an impossibly high number of clicks in a short period can indicate automated bot activity.

FUNCTION analyzeSession(sessionData):
  clickCount = sessionData.clicks
  timeOnPage = sessionData.durationInSeconds

  IF timeOnPage < 2 AND clickCount > 5:
    RETURN "fraudulent"
  
  // High frequency clicking is a bot signal
  IF (clickCount / timeOnPage) > 3:
    RETURN "suspicious"
    
  RETURN "legitimate"
END FUNCTION

Example 3: Geo Mismatch Detection

This logic compares the user’s reported timezone (from their browser or device) with the geographical location of their IP address. A significant mismatch can suggest the user is masking their true location with a VPN or proxy, which is a common tactic in ad fraud.

FUNCTION checkGeoMismatch(ipGeo, browserTimezone):
  expectedTimezone = lookupTimezone(ipGeo)
  
  IF browserTimezone != expectedTimezone:
    RETURN "suspicious"
  ELSE:
    RETURN "legitimate"
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding – Protects advertising budgets by automatically blocking clicks and impressions from known bots and fraudulent sources, preventing wasted spend on traffic that will never convert.
• Analytics Purification – Ensures marketing data is clean by filtering out non-human interactions. This leads to more accurate metrics like CTR and conversion rates, enabling better strategic decisions.
• Return on Ad Spend (ROAS) Improvement – By eliminating fraudulent traffic and reducing false positives, businesses ensure their ad spend reaches real potential customers, directly improving campaign efficiency and profitability.
• Lead Quality Enhancement – Prevents fraudulent form submissions and sign-ups from polluting sales funnels, allowing sales teams to focus on genuine prospects and increasing conversion rates.

Example 1: Geofencing Rule

This pseudocode defines a rule to block traffic originating from outside a campaign’s target countries, a common way to filter out irrelevant traffic and reduce the risk of fraud from high-risk regions.

FUNCTION applyGeofence(userIpAddress, campaignTargetCountries):
  userCountry = getCountryFromIp(userIpAddress)

  IF userCountry NOT IN campaignTargetCountries:
    BLOCK traffic
    LOG "Blocked: Traffic outside of target geo."
  ELSE:
    ALLOW traffic
  END
END

Example 2: Session Velocity Scoring

This logic scores a user session based on the number of ads they click in a given timeframe. An unusually high velocity suggests automated behavior, but whitelisting partner networks can help prevent false positives.

FUNCTION scoreSessionVelocity(userId, timeframeInSeconds):
  clicks = getClicksForUser(userId, timeframeInSeconds)
  
  // More than 10 clicks in 30 seconds is highly suspicious
  IF clicks.count > 10:
    RETURN "high_risk"
  
  // More than 3 clicks could be a bot or a highly engaged user
  IF clicks.count > 3:
    RETURN "medium_risk"
  
  RETURN "low_risk"
END

🐍 Python Code Examples

This function simulates detecting click fraud by checking the frequency of clicks from a single IP address within a short time window. An abnormally high count suggests automated bot activity rather than human behavior.

# In-memory store for tracking click timestamps
click_events = {}

def is_abnormal_click_frequency(ip_address, time_window=60, max_clicks=15):
    """Checks if an IP has an unusually high click frequency."""
    import time
    current_time = time.time()
    
    # Get timestamps for this IP, filter out old ones
    timestamps = click_events.get(ip_address, [])
    valid_timestamps = [t for t in timestamps if current_time - t < time_window]
    
    # Add current click
    valid_timestamps.append(current_time)
    click_events[ip_address] = valid_timestamps
    
    # Check if click count exceeds the threshold
    if len(valid_timestamps) > max_clicks:
        return True
    return False

# Example usage:
# print(is_abnormal_click_frequency("192.168.1.100"))

This script filters incoming traffic by checking the User-Agent string against a blocklist of known malicious or non-standard browser signatures commonly used by bots for scraping and ad fraud.

# List of user agents known to be used by bots
SUSPICIOUS_USER_AGENTS = [
    "HeadlessChrome",
    "PhantomJS",
    "Selenium",
    "Scrapy"
]

def filter_by_user_agent(user_agent_string):
    """Filters traffic based on a suspicious user agent blocklist."""
    for agent in SUSPICIOUS_USER_AGENTS:
        if agent in user_agent_string:
            print(f"Blocking traffic from suspicious user agent: {user_agent_string}")
            return False # Block traffic
            
    print(f"Allowing traffic from user agent: {user_agent_string}")
    return True # Allow traffic

# Example usage:
# filter_by_user_agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36")
# filter_by_user_agent("Mozilla/5.0 (compatible; Scrapy/2.5.0; +http://scrapy.org)")

Types of False Positives

• Heuristic-Based False Positives – Occurs when a detection rule is too broad and flags legitimate, but unusual, user behavior. For example, a fast-typing user might be mistaken for a bot filling a form, leading to an incorrect block.
• Behavioral Misinterpretation – This happens when a system misjudges a genuine user’s actions. A user quickly browsing multiple pages could be flagged for abnormal navigation patterns, even though their intent is not fraudulent.
• Technical False Positives – Arises from technical configurations like VPNs, corporate proxies, or public WiFi. These can make a legitimate user’s traffic appear to originate from a high-risk data center or an incorrect location, triggering fraud filters.
• Reputation-Based False Positives – Triggered when a user shares an IP address that was previously used for fraudulent activity. Even though the current user is legitimate, the system blocks them based on the IP’s poor reputation.