Skip to main content

​
Quickstart for Cloud Providers

The AIP bidding model uses a time-bounded asynchronous auction window rather than full broadcast fanout. When a platform sends a PlatformRequest, the AIP Operator derives a context_request, classifies the request into one or more category pools, and only brand agents and advertiser networks that have explicitly subscribed to those pools receive it. Distribution to bidders is handled through a cloud-agnostic publish/subscribe transport, starting with Google Pub/Sub in v1.0 and extendable to AWS SNS/SQS, Azure Event Grid, Kafka, or other message buses. After publishing the context, the AIP Server opens a short auction window (typically 30–70 ms) during which bidders may submit signed bids via POST /aip/bid-response. When the window closes, the server collects all bids received within the allowed timeframe, applies the AIP selection rules (CPA > CPC > CPX), and returns the auction_result to the platform. If no bids are received before the window expires, the server returns a valid no_bid response. This design enables scalable, category-aware bidding, minimizes latency, prevents unnecessary bidder fanout, and ensures that only relevant brand agents compete for each user intent.

​
Google Cloud Pub/Sub (Reference)

  1. Create Topics – For each category pool, create a topic named aip-context-<pool>.
  2. Create Subscriptions – Provision pull subscriptions per Brand Agent, binding Cloud IAM service accounts with least-privilege roles (roles/pubsub.subscriber).
  3. Grant Publisher Role – Assign the AIP Operator service account roles/pubsub.publisher on all topics.
  4. Configure AIP Server – Set auction.distribution.backend=pubsub, add project_id, and ensure the topic prefix matches your naming convention.
  5. Deploy Bid Listener – Brand Agents run lightweight subscribers (Python, Go, Node) that read messages, classify intents, and respond via HTTPS to POST /aip/bid-response.

​
AWS SNS/SQS

  • Mirror the topic layout with SNS topics per pool (e.g., aip-context-retail).
  • Attach HTTPS or SQS subscriptions for each Brand Agent; enforce SigV4 or mutual TLS for delivery.
  • Use a Lambda (or container) to bridge SNS messages into your bidding infrastructure, preserving the original auction_id and metadata.

​
Azure Event Grid

  • Create Event Grid topics scoped per pool or geography.
  • Configure Event Subscriptions that push to Azure Functions, Logic Apps, or custom HTTPS endpoints operated by Brand Agents.
  • Use Azure AD app registrations/service principals for authentication.

​
Other Message Buses

Kafka, Pulsar, NATS, or RabbitMQ can be used as long as you:
  • maintain ordering per pool
  • guarantee delivery within the auction window
  • support authenticated publish/subscribe semantics

​
Operational Tips

  • Keep the window between 30–70 ms; start with 50 ms and tune per region.
  • Record no_bid outcomes so Platforms can differentiate empty pools from outages.
  • Autoscale subscribers horizontally when pool volume surges.
  • Monitor end-to-end latency (publish → subscriber receive → bid-response) and drop late bids proactively.
For a conceptual overview, read Distributed Auctions.