Pre-bid Integration Phases

A Pinokio Pre-bid integration runs through five phases. Your account manager will guide you through each one. The first three focus on getting one bidder deployment producing clean lookups; the last two cover expanding to all of your traffic and validating that the predictions are stable enough to use.

We recommend assigning engineering time to the integration up front. Most of the work is straightforward — running a binary, querying it from your bidder, and reading the response — but a dedicated engineer makes the process noticeably faster.

Do not use Pre-bid predictions in production bidding logic until you have completed all phases and Pinokio has confirmed the setup is ready.

The five phases

1. Scoping

   We collect information about your bidder environment: regions, traffic volume, expected peaks, network constraints, deployment preferences, and whether you plan to run Post-bid alongside.

   At the end of scoping we agree on the deployment plan, the timeline, and the technical steps required. Useful details to bring to the first call:

   • bidder regions and data center locations
   • average and peak QPS per region
   • network and latency requirements
   • preferred deployment environment (bare metal, container, VM)
   • whether Post-bid is in scope now or later

2. Environment setup

   We provide the Pre-bid binary. You run it close to your bidder — ideally on the same host, otherwise on a host in the same rack or VPC. The binary speaks HTTP/1.1 over a local interface and does not need to share the machine with your bidder, but the closer the better.

   During this phase your team prepares the runtime environment, deploys the binary, and confirms that the bidder can reach it.

3. Testing

   Once the binary is running, you start sending real requests to it in a single region — but you do not yet act on the responses. The goal is to confirm correctness end-to-end without affecting live bidding.

   What to verify:

   • request format
   • response format
   • connectivity and timeouts
   • latency under realistic load
   • error handling on your side
   • logging and metrics
   • that the prediction values look sensible for your traffic

4. Scaling

   We ramp traffic to production levels. Pinokio watches latency, throughput, and response stability. If you operate in multiple regions, you deploy the binary in each one — every instance is independent, so this is mostly a matter of repeating phase 2 per region.

   If you only run in one region, this phase just confirms that the single deployment holds up at peak.

5. Validation

   You send production-level traffic for a defined validation window. Pinokio reviews the collected data, confirms that predictions are stable for your traffic mix, and flags any anomalies.

   We strongly recommend enabling Post-bid during validation. Post-bid signals feed back into Pre-bid predictions, so the sooner they both active and work together the sooner predictions are adopting to your actual traffic patterns.

   Once Pinokio confirms the integration, you can start using Pre-bid predictions in your bidding logic — for example, dropping bid requests with a high-risk band or a failed schain check.

After validation

We monitor integration health during the first weeks, verify performance, and make sure nothing in the predictions behave unexpectedly.