How to Govern Amazon DSP Brand Safety

Begin with a written risk brief before opening the campaign controls. Name the advertised product, audience, geography, creative format, landing page, regulatory or contractual restrictions, and contexts the brand will not accept. Amazon describes brand safety as baseline protection against inappropriate content, while suitability lets an advertiser apply its own tolerance across eligible inventory. That distinction matters because an eligible placement can still be unsuitable for a particular brand, product, or campaign. Assign one business approver and one platform operator so the policy decision and the DSP configuration are both owned.

Translate the brief into observable rules instead of broad labels such as safe or premium. List disallowed adjacency themes, sensitive news conditions, user-generated content tolerance, marketplace or app restrictions, language requirements, and any campaign-specific exclusions. Document whether each rule comes from Amazon policy, law, a customer contract, or the brand's own standard. Keep the current version, effective date, approver, and review date. A shared control matrix prevents one operator from silently applying a different interpretation when cloning or editing a line item.

Inventory eligibility is the first layer. Amazon's DSP inventory policies cover supply made available for display, video, Streaming TV, and audio and define requirements for transparency, content, and quality. Read the current policy before launch and record the version reviewed. Then inspect the controls exposed for the actual inventory and campaign type. Do not assume a setting available in one market, format, or deal applies everywhere. Capture the line item, supply source, control name, selected value, operator, and timestamp in the release record.

Apply advertiser-specific suitability after baseline eligibility. Amazon describes filtering capabilities across inventory sources and also documents tools such as domain lists. Use an allowlist or blocklist only when its ownership and maintenance are clear. Normalize domains and app identifiers, remove duplicates, state whether subdomains inherit the rule, and test a known included and excluded example. Treat category exclusions and lists as different layers. A domain decision cannot replace a content-category decision, and a category filter cannot prove that every page on an allowed domain is appropriate.

Create a canary line item with a bounded budget, short review window, known inventory scope, and explicit stop conditions. Save screenshots or exports of the control configuration before activation, but avoid exposing account identifiers or confidential lists in broad channels. Record the expected eligible supply and the evidence that will be reviewed after delivery. The canary is meant to prove configuration and observability, not to prove long-term performance or that no unsuitable impression can ever occur.

Before increasing delivery, verify the creative and destination are approved, the selected controls persisted, and the operator can retrieve placement or supply evidence at the required grain. Review unexpected domains, apps, content categories, exchanges, and deal paths. If reporting aggregates away the detail needed for a policy decision, do not infer compliance from a clean summary. Hold expansion until the team has a supported evidence path or narrows inventory to a surface it can govern. Keep bid, reach, and conversion changes out of the safety conclusion unless the evidence directly supports them.

Schedule reviews by campaign risk and supply volatility. Compare the approved control matrix with the current DSP configuration, active line items, inventory sources, domain or app lists, and recent placement evidence. Sample both high-spend and long-tail placements. Classify findings as policy violation, brand-specific suitability exception, configuration drift, reporting gap, or false positive. Preserve the source record and do not publish a placement allegation until the evidence is sufficient and authorized for sharing.

Amazon states that invalid traffic is ineligible for demand and is removed from reported metrics and invoices under its inventory policies. That platform treatment does not eliminate the advertiser's need to monitor anomalies. Separate invalid-traffic questions from content suitability, viewability, performance, and fraud in the advertiser's own systems. Each has a different definition and evidence trail. Escalate repeated unexplained anomalies through the supported account channel, retain case identifiers, and avoid estimating wasted spend when the platform evidence does not support an amount.

Require a ticket or release record for additions, removals, and overrides. The record should include the business reason, affected campaigns, old and new values, approver, operator, activation time, validation evidence, and rollback step. Recheck inherited settings when duplicating campaigns or changing supply. Review Amazon policy pages on a defined cadence because the inventory ecosystem and policy language can change. Retire stale lists and document why a previously blocked source became eligible rather than quietly deleting the entry.

If an unacceptable placement is confirmed, pause the narrowest affected scope that protects the brand, preserve the evidence, and verify the control state before editing. Apply the approved exclusion or suitability change, then run another bounded canary and confirm the placement no longer appears in supported evidence. If the tool cannot express the required restriction, keep that inventory path paused and escalate. Recovery is complete only when the configuration matches the current brief, evidence is available, owners agree on the result, and the exception record has a clear disposition.