Explore the
pico DSP FAQ.

pico DSP is a next-generation demand-side platform being developed for agentic, programmatic and direct media buying. Its Rust engine brings auction decisions, creative preparation and spend controls into the same system.

The aim is a more direct, affordable way to run media buying with clear operating rules. The website describes documented engine capabilities; commercial access is coming soon.

DSP means demand-side platform. It is software a buyer uses to evaluate advertising opportunities, decide whether and how much to bid, and connect delivery to campaign budgets and reporting.

A DSP is one part of the buying chain. Publishers, supply platforms, exchanges, players and measurement providers still have their own roles.

Public buying access has not launched. The website offers an early-access signup, feature explanations and illustrative controls, rather than a production campaign account.

Join the early-access list for availability updates. A signup does not activate campaigns, reserve inventory or commit you to a contract.

pico DSP is being built for agencies, in-house media teams and platform operators that want more control over their buying infrastructure. It is particularly relevant when you want programmatic and direct execution to work with agent workflows.

The right fit depends on your formats, supply relationships, operating resources and governance requirements. Those details matter more than the size of a generic feature checklist.

pico DSP is a buying engine. An SSP helps sellers make inventory available, and an exchange provides a transaction path between supply and demand. An ad network may package inventory and services around its own commercial offering.

Configuring a DSP connection does not itself establish a publisher relationship or grant access to an exchange seat.

Agentic buying is part of the design, but the underlying auction engine does not depend on a language model making every bid. Programmatic requests, configured buying rules and direct-deal eligibility still have their own execution paths.

Which hosted interfaces and operating packages will be available at launch has not been announced. Review the workflow you want to operate, rather than assuming every task requires an agent.

The repository contains the OpenRTB model and bidder, targeting index, privacy and supply checks, VAST preparation, budget controls, event intake, protocol services and deployment assets. AdCP, AAMP and ARTF have implemented integration surfaces.

Implementation is separate from general availability. The feature pages describe the relevant engine paths, while the performance page documents selected simulator evidence and its limits.

No. The buying scenes and media artwork are illustrative. Their controls change local examples and do not place bids or spend money.

The agentic walkthrough is separately identified as a replay of an inspected integration test. It shows verified fixture assertions, not a live exchange transaction or a customer campaign.

A public pico DSP source distribution and its licensing terms have not been announced on this site. Using open advertising standards and integrating open-source validation tools does not determine the license of the DSP itself.

If source access, redistribution rights or a particular license are requirements for your business, make them explicit in your early-access discussion.

Use any Request early access button to submit your email. After the signup is confirmed, you can optionally tell us your intended use case. That answer is not required to keep your place on the list.

For a specific product or integration question, write to contact@picodsp.com. Do not include API keys, personal audience records or other sensitive campaign data in an introductory message.

Consider a change when your current platform makes important buying rules hard to inspect, limits the connections you need or creates operating costs you cannot justify. Agent access and deployment control may also change what your team needs.

Compare the complete workflow and commercial proposal. A newer system is useful only if it can meet your inventory, reporting and operating requirements.

Start with reachable inventory, total cost, campaign controls, reporting, service responsibilities and the access model. Then test a representative campaign, including the cases where buying should stop.

Ask for evidence that applies to your own use case. A protocol logo, an attractive dashboard or a headline request rate does not answer every operational question.

pico DSP's positioning centers on a lean engine, open protocol interfaces and clear buying authority for the agentic era. Established platforms may offer mature integrations, commercial supply access and services that a new platform must still establish.

We do not publish an unsupported feature ranking or claim universal parity. Compare confirmed capabilities and terms against the specific workflows you would move.

A DSP does not automatically replace your creative production, publisher ad server, consent management, independent verification or business reporting systems. Some of those systems supply inputs to the DSP; others observe delivery or business outcomes.

Map the boundaries before migration. Decide which system owns creative approval, campaign budgets, delivery records and final commercial reconciliation.

The engine includes advertiser-related access controls and principal-based buying authority that are relevant to agency operation. Those controls must be configured and tested against the separation your clients require.

Commercial account packaging, client-facing interfaces and agency service terms have not been announced. Technical advertiser separation should not be treated as a promise of a particular launch account model.

It may fit a team that wants direct control over supply connections, buying rules and the infrastructure behind campaign execution. The key question is who will operate those responsibilities and respond when something goes wrong.

Compare the staffing, integrations and service package you would need. A team seeking a fully managed service should confirm that offering rather than infer it from the engine's capabilities.

Inventory connections, advertiser access, creative assets, targeting, budgets and reporting definitions all need review. Campaign settings rarely transfer safely just because two products use similar field names.

Start with a bounded campaign and agree on acceptance criteria. Validate delivery and reconciliation before increasing spend or retiring an existing buying path.

A general campaign importer for named third-party DSPs has not been announced. Standards-based interfaces can reduce some integration work, but they do not make proprietary campaign schemas interchangeable.

Prepare the fields and assets you need to transfer, along with their units, timezones and approval states. An import should preserve buying intent and authority, not merely copy labels.

Parallel evaluation is a reasonable way to compare operations once access and supply arrangements are in place. Keep the test's budgets, audiences and inventory boundaries clear so the systems do not unintentionally compete for the same opportunities.

Agree on how you will compare delivery and costs. Cross-platform identity, frequency and reporting are separate coordination problems, not automatic benefits of running two buyers.

Ask to follow a buy from configuration through a bid decision, creative delivery and spend reporting. Include a rejected creative, an exhausted budget and a request that must not use personal data.

For agentic buying, ask who authorized the action and how an operator can inspect or stop it. Concrete failure cases reveal more than a tour of happy-path screens.

Launch pricing has not been announced. pico DSP is being built as an affordable, modern buying platform, but this website does not publish rates or a finalized billing model.

Compare any eventual proposal using the complete cost of buying: media, platform access, data, verification, infrastructure and the services your team needs.

A minimum media spend, account commitment or contract minimum has not been announced. These are different concepts and should be confirmed separately.

Your campaign budget is the amount available for a particular buy. A commercial access commitment may cover a different period or set of services. Do not assume that one defines the other.

A percentage fee, subscription, usage charge or other commercial model has not been confirmed. The engine's use of CPM bidding does not determine how platform access will be priced.

If a proposal includes a percentage, ask what amount it applies to and which costs are included. That basis is essential when comparing offers.

Look beyond the platform headline. Include media charges, audience or data fees, verification, creative hosting, exchange-related costs, support and the people or infrastructure needed to operate the system.

Separate recurring charges from one-time setup work. Ask which items are optional, which are passed through and which increase with request volume or media delivery.

Self-hosting can change how infrastructure and operations are paid for, but it does not make media, network traffic, databases or engineering time free. Licensing and support terms also need confirmation.

Compare a realistic operating plan with a hosted proposal. Include redundancy, monitoring, backups and incident response instead of comparing only a server's monthly rental.

A free plan, trial package or free production license has not been announced. The website's interactive examples are free to explore, but they are not a live buying trial.

Use early access to explain the kind of evaluation you need, including whether it requires real inventory, a sandbox or access to your own infrastructure.

CPM is cost per thousand impressions. For a simple illustration, 100,000 billable impressions at a fixed $5 CPM represent $500 of media cost before any separate charges.

That is arithmetic, not a pico DSP price quote. Auctions may produce different clearing prices, and the billable event and included fees depend on the connection and agreement.

A lower CPM is useful only in the context of the inventory and outcome you need. Compare delivery quality, eligible audiences, measurement and the full fee structure alongside price.

A cheap impression that never reaches the intended environment may not be useful. Evaluate comparable opportunities and defined campaign goals rather than treating CPM as the only measure of value.

No savings percentage, return-on-ad-spend target or outcome guarantee is published here. Affordability is a product goal, not a substitute for a confirmed proposal and a measured campaign evaluation.

Ask how each cost is calculated and how results will be attributed. Compare like-for-like scope before making a claim about savings.

Payment methods, invoicing arrangements, contract duration, cancellation terms and support packages will be confirmed for launch. The site does not currently promise credit terms, a service-level agreement or a dedicated account team.

Bring procurement requirements into the evaluation early. Technical suitability and commercial approval are both necessary before production buying begins.

Programmatic buying uses software and agreed transaction interfaces to evaluate and purchase advertising opportunities. In an auction path, the exchange sends an opportunity and the buyer returns a bid or declines it.

Automation does not remove commercial terms, creative requirements or buying authority. Those constraints still determine whether the opportunity is eligible.

OpenRTB is an IAB Tech Lab specification for communicating advertising bid requests and responses. It gives buyers and sellers a common structure for the opportunity, price and creative information exchanged during an auction.

A shared structure helps integration, but participating systems still need to agree on supported versions, extensions and commercial behavior.

The engine uses an OpenRTB 2.6 model and includes a compatibility path for supported 2.5 inputs. Accepted versions can be configured for each exchange connection.

Version support is not a claim that every exchange-specific extension or every inventory type has been integrated. Test the actual request and response contract for the connection you plan to use.

The engine decodes and normalizes the request, evaluates privacy and supply rules, finds candidate line items and applies campaign, creative and budget checks. Pricing and response rendering follow for eligible opportunities.

The pipeline can also decline the request. A no-bid may be the correct result when a deadline, floor, policy or compatibility requirement cannot be met.

A no-bid means the buyer chose not to return an eligible offer. It can be a normal outcome, such as no matching campaign, an exhausted budget or a floor above the permitted price.

Distinguish that decision from malformed input, a transport failure or a late response. The explain tools and operational metrics are intended to help make that distinction.

A bid floor is the minimum price communicated for an opportunity or deal. It needs to be interpreted with the correct currency and transaction terms.

A campaign can have a valid creative and matching targeting yet still produce a no-bid because its allowable price cannot meet the floor. Raising a budget alone does not necessarily change that price limit.

Bid shading adjusts an auction bid in an attempt to avoid paying the full configured maximum when a lower eligible price may win. The engine includes a first-price shading model.

Shading is constrained by floors, campaign limits and available inputs. It does not guarantee a saving or a win, and its behavior should be evaluated against the actual exchange and traffic mix.

The documented bidder evaluates candidate line items against the opportunity and applies priority and pricing logic when selecting an eligible bid. Creative compatibility and budget availability are part of eligibility.

The best-looking targeting match may therefore lose to another candidate or be excluded. Use a decision trace when you need to inspect the actual checks rather than infer the outcome from targeting alone.

A seat identifies a buyer in the exchange relationship. A deal ID identifies negotiated transaction terms that can be referenced in a request and bid response.

Neither is an arbitrary display label. Confirm the authorized seat, advertiser access, deal eligibility and pricing with your supply partner before expecting traffic to transact.

No. Buying only when configured conditions are met is an essential DSP behavior. Privacy restrictions, supply rules, targeting, creative checks, budgets and deadlines can all prevent a bid.

The objective is to make eligible decisions and explain refusals, not to maximize the percentage of requests that receive an offer regardless of suitability.

Direct buying starts from negotiated supply terms instead of relying only on an open auction. The engine includes deal intake and activation surfaces that can make those terms available to its buying path.

A negotiated deal still needs eligible inventory, compatible creative and an agreed execution arrangement. Direct does not automatically mean guaranteed delivery.

A private marketplace restricts a transaction to eligible buyers or negotiated opportunities, often using deal identifiers. It can still involve an auction rather than a fixed guaranteed allocation.

Confirm the actual deal mechanics. Access rules, price floors, inventory commitments and billing may differ between private marketplace arrangements.

No. Negotiated terms can be executed through a programmatic transaction path. A request may carry deal information that the buyer uses alongside campaign eligibility and budget checks.

For pico DSP, the important distinction is where the terms come from and how the engine applies them. It is not an assumption that every direct deal needs a separate buying system.

Not by itself. A deal record can describe access or pricing without guaranteeing a volume of impressions. Guaranteed commitments require explicit commercial terms and compatible execution on both sides.

Do not infer a reservation, guarantee or makegood policy from the presence of a deal ID. Confirm what the seller has actually committed to deliver.

Commercial launch exchange and publisher partners have not been announced. The documented engine supports configurable OpenRTB connections and direct-deal workflows.

A technical integration path is not a published inventory roster. Confirm the specific publisher, exchange, market and format access you need as part of early-access evaluation.

The engine is designed around configurable connections and deal intake, which can support using your own supply arrangements. Integration still depends on the partner's accepted protocol behavior and your commercial authorization.

Prepare sample requests, seats, deal terms, creative policies and billing expectations. A working configuration should be verified with the partner before production traffic is enabled.

No. The documented harness exercises an integration through an existing Prebid Server adapter pointed at the engine. It is technical evidence for a tested path.

It does not announce an upstream pico DSP adapter, exchange certification, commercial partnership or automatic access to every publisher using Prebid.

A commercial launch market list has not been announced. Technical geographic targeting does not establish local supply access, contractual eligibility or support coverage.

Identify the countries, currencies, languages and privacy requirements in your media plan. Confirm them with the actual supply and operating arrangements rather than assuming global availability.

The deal workflow includes activation controls so buying can stop while the deal record retains its terms. Resuming buying is still subject to configured permissions, campaign eligibility and current supply conditions.

A local pause does not amend a seller contract. Keep operational activation and any external cancellation or commitment terms aligned.

The website's inventory artwork is illustrative, and no named launch supply roster is published. The engine's role is to evaluate configured opportunities and execute eligible buys.

The eventual commercial relationship, payment flow and any resale arrangement must be confirmed in the applicable terms. Do not treat a format preview as an offer of specific inventory.

Agentic buying lets software agents carry out parts of the media workflow through defined interfaces. An agent might discover products, prepare a buy, submit creative or retrieve delivery information.

Useful automation still needs an authorized principal, explicit budgets and clear rules for actions that require approval. An agent's ability to propose an action should not be confused with permission to execute it.

The engine includes protocol surfaces for agent-operated media workflows and optional agent stages in the auction path. These connect to the same underlying campaign, creative and spending model used by the bidder.

The intention is to make agents part of the buying architecture rather than an unrelated chat interface. Launch access remains separate from the implementation of those surfaces.

The implemented foundation is a DSP engine and its protocol interfaces. A conversational agent can be one client of those interfaces, but the engine is responsible for validating actions and applying buying rules.

A hosted conversational interface, supported assistants and user-facing launch workflows have not been announced. Evaluate the execution and authority model as well as any interface placed on top.

No. The bidder has a rule-driven path for targeting, privacy, supply, budget and creative eligibility. Optional ARTF agents can contribute at configured stages without replacing the entire auction pipeline.

This matters for deadlines and control. A buying system should know what happens when an external service is slow or unavailable, rather than assume a model can respond in time to every opportunity.

A buyer agent works on the media-buy workflow, such as discovery, creative preparation and campaign changes. A real-time auction agent contributes within the much shorter deadline of an individual bid request.

The two roles can interact with the same buying system while using different interfaces, permissions and time budgets. Treating them as interchangeable makes integration requirements harder to evaluate.

An agent needs a client that can speak the implemented protocol and authenticate correctly. AdCP over MCP is one relevant integration path in the engine.

Compatibility with a particular assistant, vendor or agent framework has to be checked. A shared MCP transport alone does not mean the client understands every advertising task or has buying authority.

That depends on the permissions and approval rules configured for its principal. The engine includes spend constraints and approval thresholds; some authorized activity can be automated within those rules.

Decide which changes may proceed automatically and which require review. A useful agentic workflow makes that boundary explicit before campaigns are activated.

The receiving protocol service validates the request against its schema, domain rules and principal permissions. Auction-stage mutations are also subject to the host's policy.

A proposal is not a direct write into unrestricted buying state. Test rejected actions and their error handling, including budgets, advertiser access and unsupported operations, as part of integration acceptance.

The documented ARTF design bounds optional agent calls by the available deadline and can continue without a late optional contribution. Other policy or request failures may still cause a no-bid.

Confirm which agents are optional in your deployment and how their failures are monitored. There is no blanket promise that every external dependency can fail without changing a buying decision.

No. Agents can reduce some manual work and make workflows more programmable, but campaign results still depend on the strategy, data, creative, inventory and constraints they operate under.

Define the task and a measurable evaluation before delegating it. More automation is not proof of a better outcome or a reason to relax spending and approval controls.

AdCP is an open advertising protocol published by AgenticAdvertising.org. It defines shared task interfaces that agents and advertising systems can use to work on media and related workflows.

pico DSP implements a defined set of tasks. Protocol support should be evaluated at the task and version level rather than read as a claim that every capability in the broader ecosystem is available.

MCP provides the tool-oriented client/server interface used by the engine's AdCP service. The implementation exposes its supported advertising tasks over MCP Streamable HTTP.

The advertising meaning comes from the task definitions and engine behavior. Transporting a message through MCP does not by itself approve a creative, grant a budget or establish a supply relationship.

No. In pico DSP, AdCP manages parts of the media-buy workflow, while OpenRTB carries individual auction opportunities and bid responses. A media buy created through AdCP can become eligible for execution through the bidder.

This separation lets planning and control operate on a different timescale from impression-level decisions.

The AdCP service includes product discovery and creative-format discovery tasks. An authenticated client can use supported responses to understand the configured catalog before preparing a buy.

The available products are the deployment's configured offerings. A discovery response is not a promise of universal inventory access or an independent commercial quote outside the applicable terms.

A valid media-buy request maps into the engine's campaign and line-item model. After storage and the applicable approval steps, the catalog is compiled into the index used for auction decisions.

The published walkthrough follows an integration-test fixture that creates a buy and then wins a synthetic auction. It is useful evidence of connection, with clearly stated test assumptions.

The implemented AdCP surface includes media-buy updates, subject to authentication, domain validation and approval policy. A budget increase can require operator review when it reaches a configured threshold.

Do not assume every field can be changed at every lifecycle stage. Test the allowed update, cancellation and pending-approval behavior for the client you build.

The service includes creative synchronization and listing tasks. Creative preparation connects to the engine's supported formats and validation path before the material is eligible for delivery.

Successful transport is different from successful approval. The client should inspect the returned status and findings instead of assuming that an uploaded asset is ready to serve.

The implemented service includes delivery reporting for configured media buys, using the aggregates maintained by event processing. Access remains subject to the principal's authority.

Agree on the report's scope, timezone and data freshness before using it for optimization or reconciliation. A reporting response should not be treated as an independently audited invoice.

Network clients can retry when a response is delayed or lost. An idempotency key helps the service recognize a repeated operation instead of treating every retry as a fresh instruction.

Use the key and retry behavior required by the implemented task. Reusing a key for a different intended change can be just as problematic as omitting it.

No certification, membership or endorsement is claimed here. Implementing protocol tasks, running a test suite and receiving an organization's certification are different things.

Ask for the exact supported task set and relevant test evidence. Any future certification claim would need its own identifiable basis and scope.

AAMP is IAB Tech Lab's Agentic Advertising Management Protocols initiative. Its scope includes several related components for agentic advertising.

pico DSP's documented AAMP work centers on deal intake and associated agent interfaces. It should not be read as a claim that the engine implements every project or optional component within the AAMP initiative.

ARTF is IAB Tech Lab's Agentic Real Time Framework. It provides a framework for a host to call agent services that contribute to advertising decisions.

In pico DSP, configured request-stage and response-stage integrations can propose supported changes under a host policy and deadline. The host remains responsible for deciding which contributions it can accept.

They address different integration needs in the engine: agent-operated buying workflows, negotiated-deal intake and contributions inside the real-time auction path. Their outputs must still fit the same underlying campaign, creative and spending rules.

You do not need every interface for every deployment. Choose the surfaces required by your clients and supply arrangements.

AdCOM supplies common advertising definitions and enumerated values that OpenRTB can reference. Those shared lists help systems describe things such as device or creative characteristics consistently.

The engine's model and targeting rules use these kinds of values, but a shared numeric code does not make incomplete or incorrectly populated partner data reliable.

No. Partners can differ in versions, optional fields, extensions, supported formats, authentication and commercial requirements. A standards-based foundation reduces some ambiguity without eliminating integration work.

Validate representative requests, notices and creative delivery with the actual partner. Include failure cases and accepted billing behavior, not only a successful sample bid.

The Open Measurement SDK provides common measurement integration code for supported player and app environments. OMID is the interface through which verification providers can access the relevant measurement signals.

A DSP can carry verification resources in VAST, but the compatible player or app integration is what makes those resources useful during playback.

SIMID defines an interface for interactive media experiences associated with an ad. VAST carries the ad delivery information; SIMID is not a replacement for that delivery document.

Player support and creative compatibility still matter. The engine's handling of supported VAST material should not be presented as a universal guarantee that an interactive creative will run on every device.

No. The documented bidder is centered on OpenRTB 2.6 with supported 2.5 compatibility. Version numbers identify different integration contracts, not an automatic ladder of interchangeable capabilities.

If a partner requires OpenRTB 3.0 or a specific extension, treat that as a separate requirement to confirm rather than infer it from the standards strip.

This site does not claim blanket IAB certification or complete conformance with every advertising standard. It describes specific implemented paths, validation integrations and selected test evidence.

Standards adoption, organizational membership, formal certification and production acceptance are separate questions. Evaluate the exact scope relevant to your connection or campaign.

Record the protocol version, supported tasks or objects, extension behavior and test suite used for your integration. Keep that contract with your deployment configuration and acceptance evidence.

A newer specification may introduce fields or semantics an existing client does not understand. Plan version review and partner testing instead of assuming a version update is only a label change.

The documented engine and website focus on connected TV, online video and audio. Creative selection considers the requirements sent with the opportunity rather than treating every asset as interchangeable.

Technical format handling is separate from commercial launch access. Confirm the specific environment, supply connection and creative requirements in your plan.

Connected TV advertising reaches viewing experiences on internet-connected televisions and associated streaming devices. The transaction and playback environment can differ from video in a desktop browser.

For a DSP evaluation, check pod structure, creative duration, device signals, player behavior and measurement expectations. A general video label does not establish that the full CTV delivery path has been tested.

The bidder includes pod-related selection and advertiser-separation logic, and the simulator includes CTV pre-roll and live mid-roll examples. This gives specific technical paths to inspect.

It does not announce access to a named streaming service or guarantee every partner's pod implementation. Validate the pod fields, duration constraints and competitive-separation behavior with the actual supply.

Competitive separation limits which advertisers or categories can appear together within a group of ads. It affects which otherwise eligible creatives can be selected in the same pod.

The requirements depend on the request and seller rules. Confirm the categories, advertiser identities and separation conditions used by your integration instead of relying only on the campaign's display name.

The documented video path includes web video opportunities and VAST delivery. Eligibility depends on media requirements, campaign settings and a compatible creative.

Check placement, duration, MIME types, permitted APIs and verification requirements for each connection. A creative suitable for a television pod may not be appropriate for a different online video placement.

Audio uses the same overall buying and event-accounting foundation, with audio-specific impression and creative compatibility checks. The creative pipeline can generate VAST audio delivery material.

Do not assume that video and audio settings can be copied without review. Duration, asset type, supply signals and the available playback events can differ.

This website does not make a launch capability or inventory-access promise for display banners, native or digital out-of-home. Its documented buying and creative examples focus on CTV, video and audio.

The fact that a protocol can describe another format is not evidence that the engine's complete selection, rendering and delivery path supports it.

The creative must fit the duration and other restrictions communicated by the opportunity and your configured offering. The engine includes compatibility checks rather than treating any length as eligible.

Confirm duration metadata and the actual media asset before activation. A valid VAST document is not enough if the asset or pod slot requires a different length.

A general-purpose transcoding service has not been announced. The documented creative path can work with prepared media renditions and supported VAST inputs.

Plan how assets will be encoded, hosted and checked before they enter buying. Supplying a URL does not establish that every required rendition exists or meets the destination's specifications.

No. Server-side ad insertion and client players can differ in macro handling, wrapper support, tracking and verification behavior. Compatibility needs to be checked end to end.

Use representative creative and notices in your partner test. Confirm which events the player or insertion system will fire and how they map to billable delivery.

VAST is IAB Tech Lab's XML-based ad delivery specification for compatible media players. It describes material such as media resources, tracking events and verification information.

A valid document is an important input to delivery, but actual playback also depends on the asset, the player and the surrounding transaction.

The documented pipeline includes hosted video or audio assets, third-party VAST tag URLs and buyer-provided VAST XML. Those inputs follow different preparation paths before compatible rendering.

Choose the path that matches who owns the media and tracking. Treat an externally served VAST tag as an integration dependency with its own behavior, not as a static file you fully control.

An InLine describes an ad's delivery material directly. A Wrapper points to another VAST response and may add tracking or related information around that downstream ad.

This changes what must be tested. A valid wrapper can still lead to an unavailable, incompatible or excessively nested downstream response.

The creative preparation path integrates VASTlint to identify supported error-level findings in VAST material before approval. This helps catch structural and standards-related problems earlier in the workflow.

Validation findings should be interpreted with their scope. A successful XML check does not prove the asset will be reachable from every player or that a campaign will meet a business outcome.

Pixellint is used for tracking URL checks in the creative validation path. It helps inspect the trackers that accompany the supported creative material.

The result is a technical check within preparation. It does not establish consent, verify an advertiser's commercial authorization or guarantee that every external tracker will remain available during a campaign.

RTBlint is relevant to validating bid requests and responses, including the relationship between an opportunity and the returned bid. The repository's verification paths and simulator use protocol validation as part of testing.

Creative validation and auction validation answer different questions. A VAST document can be structurally valid while the bid carrying it is incompatible with the request.

The outcome depends on configured approval policy. The engine can automatically approve material with no error-level findings when that behavior is enabled, or hold work for the applicable review process.

Technical approval is separate from a publisher's creative acceptance or an advertiser's internal review. Confirm the full approval chain for the supply you intend to use.

Supported VAST preparation paths can carry trackers and compatible verification material. Their actual use depends on the creative, permitted resources and the player environment.

Review the provider's requirements and the information sent by those resources. Including a tracker is not evidence that every event will arrive or that every intended data use is permitted.

No. Rendering verification resources in VAST is different from completing the relevant OM SDK integration and compliance process in a player or app.

pico DSP does not claim OM SDK certification for every downstream environment. Confirm the player's supported measurement integration and the verification provider's requirements for the inventory you buy.

Inspect the specific finding and correct the underlying asset, document or tracking URL. Revalidate the revised input and verify that the resulting material remains compatible with the intended opportunity.

Suppressing a finding without understanding it can move the failure into live delivery. Keep the validation result with the exact creative version you approve.

A budget limits how much a campaign or line item is allowed to spend over its configured scope. A bid price expresses what the buyer is prepared to pay for a particular opportunity, commonly in CPM units.

Both constrain buying, but increasing one does not automatically increase the other. Check the units and currency whenever you compare them.

Pacing regulates how quickly a campaign participates so spend can follow its intended flight or allocation. It is distinct from checking whether any budget remains.

A campaign may have money available yet bid less aggressively to preserve delivery later in the flight. Conversely, relaxed pacing cannot create eligible inventory that does not exist.

There can be time between returning a bid and learning its billable outcome. A reservation represents spending authority held while that outcome is unresolved.

The lifecycle needs to distinguish committed spend, an outstanding reservation and released authority. Treating every bid as immediately spent, or ignoring in-flight bids entirely, can both distort budget behavior.

The documented lifecycle includes resolving reservations after an accepted billable outcome, a loss or the configured expiration behavior. The relevant event must belong to the expected bid and lifecycle.

Test late, repeated and missing events as well as the successful sequence. Reservation settings should match the notices and delivery behavior of your actual supply connection.

No universal zero-overspend guarantee is made here. Concurrency, outstanding bids, event delays, lease behavior and configuration all affect the money path and need explicit testing.

Evaluate the documented controls under your expected traffic and failure cases. Define acceptable exposure and reconciliation procedures rather than treating a budget field as a complete financial assurance.

The domain model uses integer micro-units for money rather than relying on floating-point arithmetic throughout the ledger. Values still need careful conversion at protocol boundaries such as a CPM bid price.

Integer precision does not remove the need to agree on currency, rounding, exchange terms and the event that makes an impression billable.

The engine configuration includes a bid currency and explicit exchange-rate inputs for comparing supported amounts. Exchange connections can also have currency-related settings.

Those technical controls do not announce a commercial billing-currency list or a live FX service. Confirm the currency of every budget, floor, bid and settlement report before enabling buying.

A budget lease grants a bidder a bounded amount of spending authority from the control plane. This lets auction decisions use local authority instead of making a control-plane request for every impression.

Lease sizes, expiration and outstanding authority matter during failures and scaling. Evaluate them as part of the deployment's spending-control model.

No. Underdelivery can result from targeting, limited supply, floors, creative incompatibility, privacy restrictions or operational issues. Pacing is only one possible cause.

Inspect the decision path before changing spend limits. Increasing a budget will not fix a creative that cannot serve or a connection that is not authorized to send the inventory you need.

A principal can request supported changes only within its configured permissions and limits. The AdCP update path also applies approval policy to budget increases that reach a configured threshold.

Set these boundaries before granting write access. Test the behavior of pending approvals, rejected changes and retries so automation does not rely on an assumed permission.

The targeting model includes geography, device, inventory, content, audience, deal and media-related dimensions. The bidder evaluates configured rules against the signals supplied with the opportunity.

A model field is not a guarantee that a partner provides usable data for it. Review actual request samples and privacy restrictions before planning a campaign around a targeting dimension.

Contextual buying uses information about the opportunity or content rather than depending on a person's identity or behavioral history. The engine can constrain decisions to a contextual mode under supported privacy policies.

Contextual does not mean unregulated or unrestricted. The system still needs appropriate configuration, authorized supply and compatible treatment of the information present in the request.

The targeting model includes inventory rules for domains and app bundles. These can help define an allowlist or exclusion policy for the opportunities a line item considers.

Matching depends on the fields the supply sends and how they are normalized. Keep app identifiers, publisher domains and commercial deal access distinct when you build the rules.

Geographic rules are part of the engine's targeting model. The available granularity depends on request data and the privacy decision; precise location should not be assumed available or usable.

Validate the source and meaning of geographic fields for your connection. A country label, a postal code and a precise coordinate describe different levels of information.

The model includes device and content dimensions such as device types, operating-system information and supported content attributes. Eligibility depends on both the configured rule and a compatible request signal.

Missing or inconsistent partner data can reduce the match rate. Inspect real input coverage before treating a narrow targeting rule as a reliable source of campaign scale.

The model includes audience-related inputs, but this site does not announce a universal audience onboarding service or a roster of data-provider integrations. Usable identifiers and permitted processing are separate prerequisites.

Confirm the source, format, activation path and rights for the data you want to use. An audience rule cannot create an identity match that the transaction does not provide.

Frequency capping limits repeated eligible impressions against an available identity key over a defined scope or period. The engine includes cap checks and event-driven updates where user-level processing is permitted.

Coverage depends on identity availability and the operating model. It is not a universal measure of a person's exposure across every device and buying platform.

A user-level cap needs a usable identity key and permission to use it. If the request lacks one, or the privacy decision restricts user-level processing, you cannot assume the same cap behavior as for an identifiable request.

Decide how those opportunities should be treated. Test that policy explicitly instead of silently equating missing identity with a new person.

No universal cross-device identity or frequency promise is made. Device and user identifiers can differ across environments, and this site does not announce an identity graph that resolves them into one person.

If household, cross-device or cross-platform frequency is a requirement, specify the identity source, permitted uses and expected measurement coverage during evaluation.

Several individually reasonable constraints can leave a small intersection of opportunities. A geography, app list, duration requirement, floor and privacy rule all apply together, rather than each providing its own pool of scale.

Inspect which condition excludes candidates before relaxing rules. Use a bounded test to see whether the resulting inventory still matches the campaign's purpose.

The engine derives a per-request privacy decision before using the opportunity in its buying pipeline. Depending on signals and configured policy, that can refuse the request or restrict processing to a contextual mode.

The decision also affects which user-level features can be used. A privacy check should constrain subsequent behavior, not simply attach a label to an otherwise unchanged bid.

The implementation includes TCF v2 signal decoding with policy checks relevant to TCF v2.2, GPP and US Privacy decoding, as well as handling for relevant request flags such as limited ad tracking and COPPA.

Exact section coverage and configured behavior need version review. This list is not a blanket claim of support for every jurisdiction or future framework update.

IAB Europe's Transparency and Consent Framework provides a structured way to communicate relevant privacy choices and vendor information within its scope. The engine reads supported signals as inputs to a configured processing decision.

A string's presence is not enough to justify every use of data. Vendor configuration, purpose restrictions and the actual operation still matter.

GPP is IAB Tech Lab's Global Privacy Protocol. It provides a standardized way to communicate privacy signals across supported sections and contexts.

The engine must interpret the relevant supported sections and apply the configured policy. A GPP string is not a substitute for understanding which signals apply to the request and what your deployment is allowed to do.

That depends on scope detection and the configured privacy policy. The documented defaults are restrictive; missing or unusable inputs should not be treated as unlimited permission to process personal data.

Review this behavior with your actual traffic, including incomplete fields. The appropriate operating policy must be determined for the deployment rather than inferred from a website example.

No. Removing a cookie or using a contextual strategy does not determine every obligation associated with a campaign, its data flows or its contracts.

pico DSP describes technical controls, not an automatic legal conclusion. Assess the actual processing, parties, geography and notices with qualified advisers where needed.

No. The website does not provide a legal certification or a universal compliance guarantee. Framework decoding and policy controls are parts of a system that still needs an appropriate operating model.

Confirm the relevant controller and processor roles, agreements, data uses and regional requirements before production. A technical acceptance test cannot answer all of those questions.

No consent-management-platform offering is announced. A CMP and other upstream systems collect or communicate relevant choices; the DSP consumes supported signals when deciding what processing it may perform.

Verify that the upstream implementation supplies the expected fields. A downstream decoder cannot repair an incorrectly collected choice or an absent agreement.

The documented server configuration refuses COPPA-marked requests under its supported production policy. It does not advertise unrestricted contextual buying for child-directed inventory.

Treat children's advertising requirements as a dedicated acceptance area. Do not infer suitability for a child-directed use case from the ability to decode the request flag.

No. The current notice describes this website's early-access signup and analytics. It does not serve as a complete data-processing agreement for an operating DSP deployment.

Campaign data retention, hosting location, subprocessors and commercial privacy arrangements must be established for the actual service or deployment. Keep the website signup separate from those production requirements.

These standards let a publisher or app owner declare authorized advertising sellers for the relevant inventory. Buyers can use those declarations as part of supply authorization checks.

The declaration is one piece of evidence. It does not, on its own, establish that every impression is genuine or that an otherwise authorized opportunity meets your campaign requirements.

A sellers.json file provides information about seller accounts in an advertising system. It helps buyers investigate the entities involved in the selling path.

It answers a different question from the publisher's authorization declaration. Useful supply review considers the relevant records together instead of treating either file as complete proof of inventory quality.

The SupplyChain object communicates the declared sequence of participating sellers in the transaction path. Buyers can inspect its structure and compare relevant seller information with other supply evidence.

A declared chain should still be assessed for consistency. Presence of the object is not an assurance that every claimed relationship is accurate.

The supply layer includes SupplyChain analysis and registries for ads.txt, app-ads.txt and sellers.json. Configured rules can use that information before an opportunity is allowed to proceed.

What is enforced depends on the deployment policy and available evidence. Test the policy with actual partner requests, including incomplete and stale records.

Observation records the result without necessarily blocking the opportunity. Enforcement makes the configured check part of buying eligibility. The documented configuration distinguishes those modes.

Observation can help evaluate coverage before enforcing a rule, but it should not be described as protection that already rejects the affected traffic. Confirm the active mode in production.

Not necessarily. Missing, stale, unavailable and demonstrably inconsistent evidence are different conditions. A sound policy should make those states visible rather than collapse them into one unsupported accusation.

The buyer still needs a decision about whether to proceed. Choose that behavior deliberately and investigate the missing evidence with the supply partner.

The engine repository includes a supply refresher and an HTTPS fetcher, with operational signals for stale files and refused crawls. This supports keeping local evidence current without fetching it on every bid.

An automatic refresh still needs monitoring. Network failures, publisher changes and configured fetch restrictions can leave the available evidence older or narrower than expected.

No. Seller authorization and identity records address particular supply-transparency questions. They do not establish every property of a device, a user, an ad's viewability or the surrounding content.

Use them alongside an appropriate inventory policy, traffic checks and any independent verification you require. Avoid treating one successful file lookup as a universal quality certificate.

The supply layer includes pre-filters relevant to invalid traffic and request eligibility. Their scope is a technical part of the engine's configured policy.

This site does not claim accreditation by a measurement authority or equivalence to every specialist fraud-detection service. Confirm the controls and third-party services needed for your campaign and buying contract.

No blanket brand-safety guarantee is published. Supply authorization, category controls, inventory rules and external verification each address different risks.

Specify your brand-suitability requirements and how they will be verified on the actual supply. A protocol-valid request can still represent an environment that your advertiser should not buy.

No. A winning bid is an auction outcome. Playback and impression events happen later in the delivery path, and a win does not establish that every intended playback event occurred.

Agree with the supply partner on which signal is billable and how discrepancies will be reconciled. Campaign reporting should preserve these distinctions.

The documented intake includes win, billing and loss notices along with supported VAST player events. These events feed the relevant accounting and reporting paths.

Availability of a particular player event depends on the creative and playback environment. Do not assume every player will report every milestone with identical timing or semantics.

That is connection-specific. The documented exchange configuration includes billing conventions for supported notice and impression paths, so the engine's accounting can match the agreed integration.

Set the convention intentionally and verify it with the partner. Receiving a win notice is not a universal instruction to recognize spend in every advertising relationship.

The engine includes event identity and duplicate-accounting controls because notices can be retried or arrive in different orders. A repeated signal should not simply be treated as a new impression without examining its identity and meaning.

Validate retries, recovery and reconciliation for your deployment. The existence of duplicate handling is not a blanket guarantee about every crash or external delivery pattern.

The spool provides a local persistence and replay mechanism for accepted event processing, including forwarding from bidder nodes in split deployments. It helps separate intake from downstream application or aggregation work.

Its capacity, acknowledgement behavior and recovery need monitoring. Durable local storage is useful only if the operating plan also handles disk failures, backlog and eventual reconciliation.

No universal zero-delay reporting promise is made. Event arrival, batching, forwarding and aggregation can introduce lag, and the protocol service has configured reporting behavior.

Define the freshness you need and inspect the measured delay. A recently served impression may not appear in every aggregate at exactly the same moment.

No. An impression record and a viewability measurement answer different questions. Compatible Open Measurement integration and verification resources can support measurement in suitable player environments.

Confirm what the player and measurement provider actually report for the inventory. A DSP's receipt of an event is not, by itself, independent proof that the ad met a viewability threshold.

A complete attribution product, conversion integration roster and incrementality measurement offering have not been announced. Delivery and spend aggregates are not the same as proving business outcomes caused by a campaign.

If you need conversion optimization, lift testing or a specific attribution window, make those explicit requirements. Identify the source and ownership of the outcome data.

Systems can count different events, use different timezones or apply different eligibility and deduplication rules. Delayed notices and the distinction between wins, impressions and billable delivery can also affect totals.

Reconcile definitions before treating a mismatch as missing money. Compare the relevant identifiers, event windows and commercial billing basis with each partner.

The engine includes event processing, operational logs, protocol reporting and diagnostic paths that can support investigation. The exact retention, export workflow and any hosted reporting interface need to be defined for the deployment.

Agree on the identifiers and records needed for reconciliation before launch. A dashboard total alone is often insufficient when you need to explain a particular bid or event.

A principal is a configured identity with the credentials and permissions used to call supported control interfaces. It may represent a buyer agent or an operator rather than an anonymous caller.

Permissions, advertiser access and spending constraints should reflect the responsibility of that identity. Giving two clients the same key also gives them a shared accountability boundary.

The documented configuration supports named principals with allowed scopes and related access restrictions. Read, write and administrative capabilities are not intended to be treated as interchangeable.

Grant the smallest authority needed for the workflow and test denied operations. Keep keys out of web pages, creative URLs and public repositories.

Advertiser-related restrictions are part of the engine's principal and protocol access model. They are relevant when multiple buyers or clients operate through one deployment.

Validate those boundaries against the actual operations you expose, including listing, updates and deal activation. A label in a campaign name is not a substitute for authorization.

Configured principal limits can require operator review for supported media-buy actions, including budget changes that reach the applicable threshold. The operator's decision determines whether the pending action can proceed.

An approval workflow needs a responsible operator and a way to inspect the request. Merely enabling a threshold is not enough if nobody monitors the pending queue.

A pause changes eligibility for subsequent decisions as the updated state reaches the relevant bidder. It cannot recall an ad that has already been delivered or erase notices still arriving for earlier bids.

Define and test propagation and outstanding exposure in your deployment. Treat emergency stop behavior as an operational requirement, not an assumption about a button label.

Audit records help connect supported mutations to the principal and operation that changed buying state. They can support investigation and operator review.

They do not replace all operational evidence. Define retention, access and the relationship to protocol responses and event records so an audit trail remains useful when a question arises later.

Sandbox and test-controller paths let compatible clients exercise supported workflows without treating the resulting buys as ordinary production campaigns. The documented server imposes restrictions around sandbox principals and activation surfaces.

Keep test credentials and configurations separate from production. An environment should not be considered safe merely because its display name contains the word sandbox.

No such certification or service-level commitment is announced on this website. Technical controls and deployment assets are not a substitute for independent assurance or a commercial service agreement.

Bring certification, support, incident-response and procurement requirements into the evaluation before deciding that a deployment is suitable for your organization.

The server supports resolving secrets from configured environment or file sources, and the operations documentation covers key rotation. Actual access to those sources must be controlled by the deployment operator.

Use a managed secret-handling process appropriate to your infrastructure. Do not publish credentials in configuration examples or assume that a signed tracking URL makes every other system boundary secure.

No. Signing is one mechanism for checking the integrity of supported event data. Authentication, authorization, input handling, data exposure and operating procedures remain separate security concerns.

Evaluate the complete deployment and its failure cases. No single token format, protocol test or feature page should be treated as a universal security guarantee.

The engine is designed to run on your infrastructure. The repository includes configuration and deployment assets for operating the service in different roles.

Source access, licensing and support arrangements remain commercial questions to confirm for launch. A self-hostable architecture does not itself establish a public distribution or a managed operations package.

Hosted access, onboarding and managed-service packages have not been announced. The site's early-access form is the appropriate place to register interest in the operating model you need.

Confirm who will own infrastructure, monitoring, upgrades, supply integration and incident response. Those responsibilities can materially change the cost and suitability of a proposal.

Rust is the implementation language of the engine and its protocol, bidding and infrastructure crates. The architecture emphasizes compiled targeting data and bounded work in the auction path.

Language choice is not proof of a production latency, security or uptime guarantee. Use measured evidence and an appropriate operating review to evaluate those properties.

The same server has all-in-one, control-plane and bidder roles. An all-in-one process combines responsibilities, while a split deployment separates control and catalog responsibilities from auction-serving nodes.

Choose a layout around your operating requirements and evidence. More processes do not automatically make the system safer or better suited to a small workload.

The documented server supports SQLite, PostgreSQL and an in-memory backend. SQLite is relevant to a single-node setup; PostgreSQL supports shared control-plane persistence and its leadership model. Memory storage is for suitable ephemeral use.

Backups, failure handling and the exact deployment topology still need validation. Do not use an ephemeral store when you require persistent campaign state.

Campaign and creative state is compiled into a read-oriented index used for auction decisions. Updates can produce a new snapshot that is swapped into use without rebuilding all targeting work for each request.

This separates control-plane changes from the hottest request path. It also makes catalog freshness an operational property worth monitoring.

The split architecture distributes catalog snapshots and grants bounded budget leases to bidder nodes. Events can be forwarded back to the control plane for aggregation and accounting.

Scaling requires capacity and failure testing for the entire path. Adding bidder instances without considering outstanding authority, event backlog and control-plane behavior is not a complete scale-out plan.

No. The repository includes PostgreSQL-backed control-plane leadership and standby behavior, but the database, networking, storage and deployment process also need an availability plan.

Test failover, forwarding, event recovery and operational ownership with your own timing and infrastructure. A database choice alone does not establish an uptime commitment.

The performance page reproduces documented simulator runs against a release build on a shared Apple M4 laptop. It includes request-rate and latency variation, the test setup and reported transport errors.

Those are development measurements with stated conditions. They are not an extrapolated capacity guarantee, a cloud cost estimate or a latency promise for a different traffic mix and deployment.

Plan configuration review, credential handling, health monitoring, backups, upgrades and incident response. A distributed deployment also needs visibility into catalog age, lease behavior, event forwarding and supply-data freshness.

The repository includes operations guidance and deployment assets. The team operating the system still needs to test those procedures and know who is responsible when a service or dependency fails.

Start by checking whether eligible requests are reaching the connection and whether the buy is active in the bidder's current catalog. Then inspect targeting, creative compatibility, privacy, supply rules, floors and remaining spending authority.

Use a decision trace or relevant metrics to identify the actual gate. Changing several settings at once can hide the cause and make the result harder to evaluate.

Explain mode inspects a request against the buying pipeline and reports candidate and exclusion information. It is intended to investigate why a bid could or could not be made.

The diagnostic path does not place an exchange bid or reserve spending authority. It is useful for investigating a decision without turning the investigation itself into a media buy.

Approval says the creative passed the applicable preparation and review path. It does not guarantee that the material matches every request's duration, format, category, API or other restrictions.

Inspect the particular opportunity and candidate. Campaign state, privacy, supply and budget rules can also exclude a line item even when its creative is approved.

Inspect the control-plane write result, catalog version, snapshot synchronization and index age. A successful client request and a bidder using a fresh compiled snapshot are distinct points in the update path.

For split deployments, verify the connection and health of the relevant nodes. Avoid repeatedly changing the campaign before understanding whether the original update was applied.

Auction decisions operate within a deadline. Network delay, request processing, external agent calls or an unsuitable timeout configuration can leave insufficient time to return a useful response.

Measure the path at the boundary that matters to the exchange. A fast internal function is not the same as an on-time end-to-end response.

Check creative reachability, VAST compatibility, player behavior and whether the expected notices are arriving. Also verify that the reports compare the same time window and event definitions.

A win alone does not prove playback. Work with the supply partner using the relevant bid and event identifiers rather than assuming every missing player event has the same cause.

A backlog means accepted event work is waiting for downstream application or forwarding. It can affect reporting freshness and the timely reconciliation of spending authority.

Inspect storage capacity, forwarding failures and control-plane health. Treat sustained backlog as an operational issue to resolve, not merely a cosmetic delay in a chart.

Include representative requests, version behavior, seat and deal eligibility, floors, creative rendering and the agreed notices. Verify rejected requests and no-bids as well as successful offers.

Then follow delivery into accounting and reporting. A single valid JSON response does not prove that the partner's complete buy, playback and billing sequence works.

Test discovery, supported task schemas, authentication, creative states, media-buy changes, approvals and reporting. Include retries and actions that the principal is not allowed to perform.

Where possible, follow an authorized test buy into a synthetic auction and its resulting delivery records. Keep sandbox assumptions explicit and separate from any production approval.

Prepare the connection type, supported protocol version, expected behavior and a sanitized example of the relevant request or finding. Note the approximate time, environment and non-sensitive identifiers needed to compare records.

Remove credentials, personal audience data and sensitive commercial details before sharing. For a product question or an early-access discussion, use contact@picodsp.com.