Detecting E-Commerce Fraud in Your Analytics Pipeline

Fraud doesn't just cost you money through chargebacks and stolen goods. It also corrupts your analytics data. A bot submitting fake purchase events inflates your revenue metrics, skews your conversion rates, and makes your cohort analysis unreliable. If you're making marketing decisions based on data that includes fraudulent transactions, you're optimizing for the wrong things.

This article covers the common fraud patterns that affect e-commerce analytics, how to detect them automatically, and how to keep your data clean without blocking legitimate customers.

Why Analytics Fraud Matters

Consider a scenario: you run a deep link campaign on social media. Your analytics show a 12% conversion rate and $15,000 in attributed revenue. You double the campaign budget. But $4,000 of that revenue was from bot-generated purchase events. The real conversion rate was 8%, and the real revenue was $11,000. You just doubled your spend based on inflated numbers.

Analytics fraud affects every downstream metric:

• Revenue attribution: Fraudulent purchases get attributed to campaigns, making some channels look more effective than they are
• Conversion funnels: Fake events distort stage-to-stage conversion rates
• Cohort LTV: Fraudulent transactions inflate lifetime value calculations for specific cohorts
• Audience segments: Fraud-tainted segments receive budget they don't deserve
• A/B test results: If one variant receives more fraudulent traffic, the test results are invalid

The Association of Certified Fraud Examiners estimates that organizations lose 5% of revenue to fraud annually. For e-commerce analytics specifically, the damage to decision-making can exceed the direct financial loss.

Common Fraud Patterns

1. Bot Purchases

Automated scripts that simulate the purchase funnel, sending view_item, add_to_cart, and purchase events without any real transaction occurring. These bots may be:

• Affiliate fraud bots: Generating fake conversions to earn affiliate commissions
• Competitor bots: Inflating your costs by triggering attribution on paid campaigns
• Scraping bots: Testing your checkout flow for vulnerabilities while generating fake analytics events as a side effect

Bot purchases typically have telltale characteristics:

• Consistent, machine-like timing between events (exactly 2.0 seconds between each funnel step)
• No variation in browsing patterns (no scrolling, no product comparisons)
• User agents that don't match real devices
• IP addresses from data centers or known proxy services

2. Velocity Attacks

A single user (or IP address) generates an abnormal number of events in a short time period. For example:

• 50 purchase events from the same device in one hour
• 200 add_to_cart events from the same IP in 10 minutes
• A single user account generating revenue that exceeds any reasonable purchasing pattern

Velocity attacks can be intentional (someone trying to exploit a promotion or referral reward) or accidental (a bug in the client app that sends duplicate events). Either way, they corrupt your analytics.

3. Impossible Revenue

Purchase events with revenue values that don't match reality:

• A $0.01 purchase for a product that costs $49.99
• A $99,999 purchase from a store where the average order value is $45
• Negative revenue values (which can happen with buggy event implementations)
• Revenue in currencies that your store doesn't accept

These events might result from client-side tampering (someone modifying the SDK payload), integration bugs (a misconfigured server-side event), or deliberate manipulation.

4. Currency Exploitation

Submitting purchase events with obscure or mismatched currencies to inflate or deflate reported revenue. For example, sending a purchase of "1,000" in a high-denomination currency when the actual transaction was in a low-denomination currency. Without currency validation, this can dramatically skew your revenue data.

When your analytics platform supports 200+ currencies, you need validation rules to ensure that the currency in the event matches the currencies your store actually uses.

How Automated Fraud Detection Works

Effective fraud detection for analytics uses a rules-based approach with configurable thresholds. Machine learning systems exist for payment fraud, but for analytics event fraud, well-tuned rules catch the vast majority of issues with less complexity.

Rule 1: Velocity Limits

Set maximum event counts per user, device, or IP address within a time window.

Example configuration:

• Maximum 5 purchase events per user per hour
• Maximum 20 add_to_cart events per device per hour
• Maximum 100 total e-commerce events per IP per hour

When the threshold is exceeded, subsequent events are flagged or blocked. The key is setting thresholds high enough that legitimate power users (someone buying gifts for 10 people, for example) aren't affected.

Rule 2: Revenue Bounds

Define minimum and maximum acceptable revenue values for purchase events.

Example configuration:

• Minimum purchase value: $1.00
• Maximum purchase value: $10,000
• Maximum single-item value: $5,000

Events outside these bounds are flagged. You'll need to adjust these based on your product catalog. A luxury retailer has different bounds than a convenience store app.

Rule 3: Currency Validation

Only accept purchase events in currencies your store supports.

Example configuration:

• Accepted currencies: USD, EUR, GBP, CAD, AUD
• Any event with a currency not in this list is flagged

This prevents currency exploitation attacks and catches integration bugs where a developer accidentally hardcoded the wrong currency code.

Rule 4: Session Consistency

Check that events follow a logical sequence. A purchase event without a preceding view_item or add_to_cart is suspicious (though not always fraudulent, since server-side events might skip the browsing steps).

Example configuration:

• Flag purchase events with no preceding view_item event in the same session
• Flag add_to_cart events for items that weren't viewed in the past 24 hours

This rule has a higher false-positive rate than the others, so it's best used for flagging rather than blocking.

Severity Levels: Flagged vs. Blocked

Not every suspicious event should be dropped. A two-tier system works well:

Flagged events are recorded in your analytics but marked with a fraud flag. They appear in reports with a visual indicator, and you can filter them in or out. Flagged events are included in totals by default but can be excluded for clean analysis.

Use flagging for:

• Events that are unusual but might be legitimate
• Session consistency violations (Rule 4)
• Events from new users or devices without enough history to judge

Blocked events are rejected entirely. They're logged for audit purposes but don't appear in your analytics data at all.

Use blocking for:

• Clear velocity violations (50 purchases in an hour is never legitimate)
• Revenue values that are physically impossible (negative amounts, values over $1M)
• Events from known fraudulent IPs or device IDs

The distinction matters because false positives are expensive. Blocking a legitimate $500 purchase because it exceeded an arbitrary threshold damages both revenue and customer trust. Flag first, investigate, then tighten rules based on what you learn.

Configuring Fraud Detection in Tolinku

Tolinku's e-commerce analytics include four built-in fraud detection rules that you can configure in your Appspace settings:

1. Velocity limits: Set per-user and per-IP thresholds for each event type
2. Revenue bounds: Define acceptable minimum and maximum purchase values
3. Currency whitelist: Specify which currencies your store accepts
4. Session validation: Configure how strictly events must follow the expected funnel sequence

Each rule can be set to one of three modes:

• Off: Rule is disabled
• Flag: Suspicious events are recorded but marked
• Block: Suspicious events are rejected

Start with all rules in "Flag" mode. Run for two weeks. Review the flagged events to calibrate your thresholds. Then move the rules with low false-positive rates to "Block" mode.

Webhook Alerts for Flagged Events

Passive fraud detection (rules running in the background) works for ongoing monitoring, but you also want to be notified when something unusual happens. Tolinku supports webhook alerts for fraud events.

Configure a webhook endpoint in your Appspace settings, and Tolinku will send a POST request whenever an event is flagged or blocked. The payload includes:

{
  "event": "fraud.flagged",
  "rule": "velocity_limit",
  "details": {
    "eventType": "purchase",
    "userId": "user_abc123",
    "eventsInWindow": 12,
    "threshold": 5,
    "windowMinutes": 60
  },
  "timestamp": "2026-08-20T14:32:00Z"
}

You can route these webhooks to Slack, PagerDuty, or your own fraud review dashboard. The goal is to catch fraud patterns early, before they accumulate enough volume to meaningfully distort your analytics.

For webhook configuration details, see the Tolinku webhooks documentation.

Keeping Analytics Data Clean

Beyond automated rules, follow these practices to maintain data quality:

Validate events server-side

Client-side event tracking (from the SDK in your app) is inherently vulnerable to tampering. For high-value events like purchases, also send a server-side event from your backend after the payment processor confirms the transaction. Server-side events are much harder to fake.

Client SDK → "purchase" event (used for funnel tracking)
Payment API → Server-side "purchase" confirmation (used for revenue reporting)

When both events exist, use the server-side event for revenue calculations. When only the client-side event exists, flag it for review.

Deduplicate transactions

Send a unique transactionId with every purchase event. If the same transaction ID appears twice (due to a retry, network issue, or duplication bug), the second event should be ignored. This is a basic but frequently overlooked data quality measure.

Audit regularly

Schedule a monthly review of:

• Events flagged by fraud rules (are the thresholds correct?)
• Revenue outliers (top and bottom 1% of transaction values)
• Unusual traffic patterns (sudden spikes in events from specific campaigns)
• Currency distribution (are you seeing transactions in currencies you don't accept?)

Separate real-time and verified data

If your team needs real-time dashboards, display them with a "pending verification" label. Show verified (fraud-filtered) data in separate reports used for strategic decisions. This prevents the urgency of real-time data from overriding the accuracy of verified data.

The Cost of Ignoring Fraud

Analytics fraud has a compounding effect. Each fraudulent event slightly distorts your data. Over time, those distortions accumulate:

• You over-invest in a channel because its attributed revenue includes fraud
• You under-invest in a channel because fraud on another channel makes it look less effective by comparison
• Your cohort LTV calculations include fraudulent revenue, leading to inflated CAC targets
• Your audience segments include fraudulent users, diluting targeting accuracy

The Federal Trade Commission reported that fraud losses in the US exceeded $10 billion in 2023. While most of that is payment fraud rather than analytics fraud, the underlying point holds: fraud detection isn't optional for any business processing transactions at scale.

Getting Started

If you don't have fraud detection in your analytics pipeline today, here's a practical starting plan:

1. Week 1: Enable all four fraud rules in "Flag" mode. Don't block anything yet.
2. Week 2: Review flagged events. How many are there? What rules triggered most? Are there obvious false positives?
3. Week 3: Adjust thresholds based on your review. Tighten rules with zero false positives. Loosen rules with many false positives.
4. Week 4: Move high-confidence rules (velocity limits, currency validation) to "Block" mode. Keep lower-confidence rules (session validation) in "Flag" mode.
5. Ongoing: Set up webhook alerts. Review flagged events weekly. Adjust thresholds quarterly.

Clean data leads to better decisions. Better decisions lead to more efficient marketing spend. More efficient spending leads to higher margins. Fraud detection isn't a security feature; it's a business intelligence feature. Tolinku's e-commerce analytics give you the tools to implement it without building a fraud detection system from scratch.