Pre-bid Best Practices

A few practices keep Pre-bid fast, stable, and useful. None of them are exotic — most come down to “treat the local binary like any other latency-critical endpoint.”

Keep the binary close to the bidder

Run Pre-bid on the same host as your bidder when you can. If not, keep it in the same rack, the same Kubernetes node, or at minimum the same VPC. Crossing an AZ adds round-trip time that defeats the point of running locally.

We do not recommend putting load balancers, service meshes, or transparent proxies between your bidder and the Pre-bid binary. Each hop costs latency and offers nothing in return — the binary handles its own concurrency.

Don’t expose predictions or decisions

Pinokio’s predictions rely on signals that fraudsters actively try to reverse-engineer. The moment a verdict is observable from outside your servers, it becomes a debugging tool for them.

Use persistent, long-lived connections

Open a small number of HTTP/1.1 connections to the binary with Connection: keep-alive set, and reuse them.

Health-check the binary

The binary exposes a /health-check endpoint. Poll it from your monitoring system — anywhere from once every 10 seconds to once a minute is reasonable.

• 200 means the binary is healthy.
• 503 means it cannot serve lookups. If you see this, check the local process and recent config changes before escalating.

If your bidder cannot reach the binary, fall back to skipping the Pre-bid call and continuing with the bid (or whatever your default is). Do not let a failed health check stall the bid request.

Don’t modify the request format

The lookup endpoint expects a specific parameter set, all lowercase, all encoded. Changing parameter names, casing, or encoding breaks the lookup and produces empty or stale predictions. If you need to pass a new dimension, add it as one of the custom parameters (p1–p5) rather than renaming an existing one.

Run Post-bid in parallel

Pre-bid and Post-bid are designed to be used together. Post-bid sees what actually happened after the impression rendered — bot signatures, hardware spoofing, evasion attempts and etc. — and that data tunes Pre-bid predictions for your specific traffic. See the Post-bid overview.

Test failure modes before going live

Once the binary is deployed and your bidder can reach it, run a few failure-mode tests against your integration:

• Stop the binary process and confirm your bidder falls back gracefully.
• Add artificial latency in front of the binary (e.g. tc netem) and confirm your timeout behavior.
• Restart the binary mid-traffic and confirm the bidder recovers without leaking errors.

These are quick to run and prevent surprises at peak hours.