Stop bot traffic before attribution, while protecting the customer journey

A request can reach your campaign infrastructure without representing a potential customer. Automated scans, repeated requests and preview fetches can all touch the same endpoints that real prospects use. Letting everything through adds noise. Blocking aggressively can create a different problem: real customers who never reach the advertised app.

The useful question is not whether the edge can identify every bot. It is which unwanted requests you can safely stop before your own infrastructure forwards them, and how you will know that the intervention improved traffic quality rather than simply reduced traffic.

For app advertisers, that distinction matters. An edge decision, an attribution decision and a valuable customer are three different things. They need separate evidence.

Map the journey from ad click to destination. A campaign might route through an owned redirect or landing page before reaching a measurement link, an app store or a deep link. A CDN or Worker can inspect requests that actually traverse that controlled route. It cannot inspect a click sent directly to somebody else’s destination. Only introduce or change intermediate routes where the advertising platform and measurement or deep-link integration support them. Test destination and attribution-parameter preservation.

Check execution order as well as the diagram. Cloudflare notes that features evaluated before bot scoring, including some Redirect Rules, can prevent a request from receiving a score. A redirect running on the same platform is not proof that your intended detection logic evaluated it. [1]

Define the intervention precisely: reject a malformed request, slow repeated access to a route, or stop a suspicious request before forwarding. Do not describe this as preventing all advertising fraud. It also does not undo a click or charge already recorded upstream by an advertising platform.

An ad-click route and a server-to-server postback may share a hostname, but they should not automatically share a security policy. One expects a browser. The other expects a machine-readable response and reliable delivery.

Cloudflare’s interstitial challenges return an HTML page and interrupt the request flow. That can break clients expecting a non-HTML response. A browser challenge is therefore not a general-purpose control for an attribution provider’s callback. [5]

Keep callback protection tied to the integration’s supported authentication, request format and replay controls. Validate both accepted requests and delivery failures with the provider’s documented retry behavior. For browser traffic, test the actual supported journey, including in-app browsers, rather than assuming a desktop success proves the route works everywhere.

Start with checks whose meaning you can explain: whether the route exists, whether the method is supported and whether required parameters are valid. Even these need a baseline. A missing parameter can indicate an old link or a broken integration, not an attacker.

Then evaluate behavioral signals. Cloudflare bot scores estimate automation likelihood, not the probability of advertising fraud. A score of zero means the score was not computed. Granular scores also depend on the available product and plan. Do not turn one score threshold into a universal definition of bad traffic. [1]

Some automation is legitimate: monitoring, previews and search crawlers have different purposes from a prospective customer. Keep those categories observable instead of counting all automation as fraud or all allowed traffic as qualified demand. Verified-bot signals can help, but do not assume they cover every legitimate advertising reviewer. Never use detection rules to show reviewers different claims or conceal the actual customer experience. [2]

Choose the action according to the confidence and cost of being wrong. Observation, a route-specific limit and a block are not interchangeable. Cloudflare’s own guidance recommends learning from traffic and considering false positives before broad enforcement. [3]

Repeated activity can be a useful signal, but an IP address is not a person. Mobile carriers and privacy proxies can put many legitimate customers behind a shared address. An aggressive per-IP limit may reject a cluster of real prospects precisely when a campaign starts reaching more people.

Cloudflare explicitly cautions about that risk in its Workers Rate Limiting binding documentation. That binding also operates per Cloudflare location, with permissive, eventually consistent counters. It is not designed for precise accounting. These details apply to that binding, not automatically to every rate-limiting product. [4]

Choose a key and time window that fit the specific abuse pattern and the data you are entitled to use. Test high-volume legitimate behavior before enforcement. Do not report a rate-limit counter as unique users, an exact global click quota or a billing reconciliation.

A signed request can help detect changes to the fields covered by its signature. An expiry can limit how long it remains valid. Cloudflare’s signing example verifies an HMAC and timestamp, and notes that a deployment may need to sign additional fields such as the hostname and query parameters. [6]

Those properties do not establish that a human clicked, that an install followed, or that the request is single-use. A valid signed URL can be replayed during its lifetime unless the design also tracks consumption. Where single-use behavior is genuinely required, it needs an appropriate server-side deduplication or nonce design, including concurrency and legitimate retry handling.

Treat signing examples as building blocks, not production-ready campaign architecture. Keep signing secrets out of URLs and client-side code. Make sure the signed fields, expiry and retry rules match the actual link journey before enforcing them.

A useful rollout makes false positives visible before they become a revenue problem. For each controlled route, record its legitimate consumers, expected response, destination, rule owner and rollback path. Then compare proposed decisions with observed traffic before enabling enforcement.

• Separate browser routes, preview traffic and machine integrations in the baseline. Do not combine their expected behavior into one threshold.
• Enable a narrow, explainable rule first. Record the rule version and reason for each action so a change can be investigated later.
• Test real supported devices and in-app browsers. Check destination handoffs, query-parameter preservation and callback delivery where applicable.
• Watch both rejection signals and successful journeys. A lower request total can mean cleaner traffic, a broken route or lost legitimate customers.
• Keep a tested rollback to the previous rule version. If legitimate handoffs or integration delivery deteriorate, roll back the new control and investigate before expanding it.

There is no universal safe threshold or observation period. The right baseline depends on campaign volume, traffic mix and the cost of interrupting a legitimate journey. A small low-risk change with a clear comparison is more informative than a dramatic block count.

Give every reported rate a denominator and a window. “Blocked requests divided by eligible requests on these routes” is an edge-block rate. It is not an install-fraud rate. Eligible requests should mean requests subject to the named rule set before enforcement, within the stated routes and window. Define how retries, previews, challenges and forwarded requests are counted so the same activity is not presented as several different customers.

Compare like with like where possible: campaign, source, geography, device and time of day. A change in campaign mix can alter apparent quality even when the rule itself has no beneficial effect. If a matched comparison is not possible, state that limitation rather than assigning every improvement to the filter.

Carry the review downstream. Reconcile destination handoffs and delivery errors with advertiser-provided MMP outcomes, later fraud classifications, retention and revenue where available. AppsFlyer’s Protect360 documentation distinguishes real-time blocking from fraud identified after attribution. A blocked attribution also does not necessarily prevent the person from installing the app. [8]

For a marketing partner, the responsibility is to explain and reconcile those layers with the advertiser, not claim control of the app or its fraud configuration. Traffic that passes an edge rule should remain “forwarded,” not “verified human.” Accepted attribution should not automatically become “valuable customer.”

A practical decision log can include the timestamp, route class, interaction identifier, rule version, action and reason. Those fields help connect an incident to a change without routinely copying full headers or raw query strings into analytics.

OWASP advises excluding secrets, access tokens and unnecessary sensitive information from logs, and using de-identification where identity is not needed. Signed URLs and callback parameters deserve particular care. Hashing an identifier is not, by itself, a guarantee of anonymity. Set access and retention deliberately. [7]

The objective is not the largest possible pile of rejected requests. It is a cleaner, more dependable path from paid attention to an outcome the advertiser can evaluate. Edge controls earn their place when the reasons are explainable, legitimate customers still get through, integrations keep delivering and downstream evidence supports the result.

Primary sources checked October 21, 2026. Rollout and measurement recommendations are editorial synthesis, not vendor performance benchmarks.

Cloudflare: Bot scores [1]

Cloudflare: Bot Management variables [2]

Cloudflare: Challenge bad bots [3]

Cloudflare: Workers Rate Limiting binding [4]

Cloudflare: Challenge Pages [5]

Cloudflare: Sign requests [6]

OWASP: Logging Cheat Sheet [7]

AppsFlyer: Protect360 anti-fraud guide [8]