# DV360 Setup & Trafficking Guide ## Enterprise Operating System Guide Purpose: Enterprise-grade operating framework for campaign architecture, advertiser setup, trafficking governance, Floodlight readiness, inventory activation, creative assignment, QA, launch management, change control, and operational excellence in Display & Video 360. This guide is designed to work alongside: - Measurement Framework - QA Checklist - Audience Guide - Supply Guide - PMP Guide - Creative Guide - Benchmarks Guide --- # 1. Guiding Principles A good DV360 setup should: - Reflect the approved media strategy. - Support measurement. - Support optimization. - Support reporting. - Scale without structural redesign. - Minimize operational risk. Poor trafficking creates: - Reporting errors - Optimization conflicts - Budget waste - Frequency problems - Conflicting attribution - Measurement failure Campaign setup is operational design, not administration. --- # 2. DV360 Hierarchy Framework Advertiser → Campaign → Insertion Order → Line Item → Creative The hierarchy should mirror business decisions. ## Advertiser Controls: - Currency - Floodlight relationship - Shared audiences - Access control - Reporting framework ## Campaign Controls: - Strategic initiative - High-level organization - Measurement grouping ## Insertion Order Controls: - Budget - KPI - Pacing - Optimization framework ## Line Item Controls: - Targeting - Inventory - Bidding - Frequency - Creative delivery Line items are execution units. --- # 3. Campaign Architecture Principles Structure should answer: - What are we trying to achieve? - What requires separate budget control? - What requires separate reporting? - What requires separate optimization? Create separation only when there is a business reason. Avoid: - unnecessary duplication - excessive segmentation - one line item per publisher when publisher controls are available elsewhere - one IO per minor targeting variation Use the simplest architecture that enables decision making. --- # 4. Naming Convention Framework Every entity requires consistent naming. Suggested components: - Platform - Market - Language - Objective - Audience - Format - Product - Flight Example format: DV360 | SG | EN | Prospecting | Display Rules: - Human readable - Consistent order - No personal abbreviations - No date ambiguity - No temporary labels --- # 5. Advertiser Setup Governance Before activation verify: - Correct advertiser - Correct currency - Correct timezone - Floodlight configuration assigned - Access permissions assigned - Measurement owner identified - Commercial owner identified Incorrect advertiser settings create downstream operational risk. Advertiser-level Floodlight configuration should be validated before campaign setup begins. --- # 6. Floodlight Readiness Floodlight should be established before activation. Floodlight supports: - Conversion tracking - Audience creation - Optimization signals - Attribution Floodlight is the shared conversion layer across Campaign Manager 360, DV360 and other Google Marketing Platform products. Validate: - activity names - activity IDs - counter vs sales activities - counting method - attribution settings - revenue fields - testing evidence --- # 7. Campaign Setup Workflow Step 1 Review approved media plan. Step 2 Review measurement plan. Step 3 Review audience plan. Step 4 Review supply strategy. Step 5 Review creative assets. Step 6 Review landing destinations. Step 7 Review QA requirements. Step 8 Build campaign hierarchy. Step 9 Validate setup. Step 10 Launch. Setup must match approved proposals, budgets, dates, targeting and formats. --- # 8. Insertion Order Design Insertion Orders should represent: - separate objectives - separate budgets - separate optimization logic - separate reporting requirements Typical structures: Prospecting vs Retargeting Display vs Video Brand vs Performance Market separation Product separation Rules: - KPI must be documented. - Budget ownership must be known. - Measurement must be aligned. - Pacing strategy must be documented. --- # 9. Budget Framework Validate: - approved budget - currency - billing method - pacing strategy - daily requirements - flight requirements Budget structure should support optimization. Never fragment budget unnecessarily. --- # 10. Pacing Framework Common pacing models: - Even - Ahead - Flight-controlled Review: - seasonality - budget availability - inventory availability - campaign objective Pacing decisions should be deliberate. --- # 11. Line Item Design Framework Line items define inventory, targeting, creatives, bidding, pacing and execution controls. Line item separation should occur when: - optimization differs - inventory differs - audience differs - creative differs materially - budgeting differs Avoid duplicates. Every line item should have: - clear purpose - clear owner - clear KPI --- # 12. Inventory Setup Validate: - format eligibility - environment eligibility - exchange eligibility - PMP eligibility - geography eligibility Inventory decisions should align with the approved Supply Guide. --- # 13. Audience Setup Validate: - audience owner - audience source - audience freshness - audience size - exclusions - suppression logic Audience conflict reviews should occur before launch. --- # 14. Geography Setup Review: - country - region - city - market restrictions Common errors: - wrong country - overlapping geographies - duplicated targeting - unapproved expansion --- # 15. Language Setup Validate: - creative language - landing page language - market language - language targeting settings Language targeting should support business requirements. --- # 16. Device Strategy Setup Review: - mobile - desktop - tablet - CTV Device exclusions require justification. --- # 17. Frequency Cap Governance Frequency is a strategic control. Document: - frequency methodology - frequency ownership - objective alignment Avoid: - conflicting caps - duplicated caps - accidental restrictions --- # 18. Brand Safety Setup Review: - suitability profile - exclusions - content categories - inventory safeguards Brand safety should be applied before launch. --- # 19. Ad Verification Setup Verification controls should be configured at campaign level before activation. Validate: - provider - viewability logic - fraud controls - geography controls - reporting requirements --- # 20. Creative Trafficking Framework Creative trafficking includes: - asset intake - validation - upload - assignment - testing - approval Review: - dimensions - duration - landing URL - tracking - rights - language --- # 21. HTML5 Creative Controls Validate: - click actions - assets - backup files - responsive behavior - rendering quality Review creative previews before launch. --- # 22. Video Creative Controls Validate: - duration - sound - captions - destination - brand compliance Document exceptions. --- # 23. Native Creative Controls Validate: - headline - descriptions - logo - image assets - destination URL Expect rendering variation by publisher. --- # 24. Landing Page Validation Confirm: - destination works - tracking parameters persist - mobile experience works - conversion path works - consent behaves correctly A functioning ad with a broken landing page is a failed launch. --- # 25. Tracking Validation Review: - UTM structure - click tracking - Floodlight activity mapping - app tracking - CRM requirements Campaigns should not launch without validated measurement. --- # 26. PMP Activation Framework Validate: - Deal ID - Publisher - Inventory scope - Pricing - Access permissions - Dates Assignment of deals to correct line items must be checked. --- # 27. Creative Assignment Framework Review: - correct creative attached - correct format attached - correct market attached - correct language attached Wrong creative assignment is one of the most common trafficking failures. --- # 28. Pre-Launch Checklist Confirm: - budgets correct - dates correct - targeting correct - frequencies correct - Floodlights correct - verification correct - creatives assigned - landing pages validated - PMPs validated - reporting owner assigned No critical issues should remain unresolved. --- # 29. Launch Governance Before launch record: - approver - reviewer - date - campaign scope - exceptions Launches must be auditable. --- # 30. Post-Launch Validation Immediately review: - spend - impressions - clicks - creative delivery - Floodlight activity - inventory quality Live monitoring and reporting reconciliation should occur immediately after deployment. --- # 31. Change Control For every material change document: - reason - owner - approver - expected impact - review date Material changes include: - budget changes - KPI changes - audience changes - inventory changes - Floodlight changes --- # 32. Trafficking QA Escalation Critical issues: - wrong destination - wrong advertiser - broken tracking - incorrect budget - compliance issue Escalate immediately. --- # 33. Enterprise Troubleshooting Shortlist Review first: - budget structure - pacing - audience size - inventory access - PMP access - creative approval - Floodlight mapping - landing page behavior Most delivery issues originate from setup decisions. --- # 34. Enterprise Templates ## Campaign Build Brief - Objective - KPI - Budget - Audience - Supply - Measurement - Creative ## Launch Sign-Off - Campaign - Reviewer - Approver - Date - Exceptions ## Change Log - Change - Owner - Reason - Impact --- # 35. Prohibited Behaviours Never: - Launch without measurement validation. - Launch without QA. - Invent tracking completion. - Ignore advertiser approvals. - Duplicate audiences without purpose. - Change Floodlights without governance. - Use unapproved creative assets. - Launch without escalation of critical issues. --- # 36. Final Enterprise Instruction Setup and trafficking are not administrative tasks. They define the quality of measurement, optimization, reporting, attribution, frequency management, inventory governance and business outcomes. The DV360 Agent must evaluate campaign structure before evaluating campaign performance. --- # 37. Campaign Architecture Decision Tree Use this decision tree before building entities. ## Decision 1: Does the activity require a separate advertiser? Create or use a separate advertiser only when the approved operating model requires a distinct currency, timezone, Floodlight configuration, access boundary, legal entity, data boundary, or reporting boundary. If none of these differ, do not create another advertiser merely for campaign organisation. ## Decision 2: Does the activity require a separate campaign? Use a separate campaign when one or more of the following materially differs: - Business initiative or product - Market or legal scope - Major flight or funding source - Measurement framework - Governance owner - Required campaign-level controls If the only difference is audience, format, publisher, or creative test, retain one campaign and evaluate separation lower in the hierarchy. ## Decision 3: Does the activity require a separate insertion order? Use a separate insertion order when independent control is required for: - Objective or performance goal - Budget ownership - Pacing - Optimisation strategy - Guaranteed commitment - Market or currency reporting - Prospecting versus retargeting economics - Test budget protection If the activity shares the same goal, budget logic, pacing, and governance, use one insertion order unless another approved requirement exists. ## Decision 4: Does the activity require a separate line item? Use a separate line item when there is a material difference in: - Line-item type or format - Inventory source or deal - Audience role - Bidding strategy - Frequency control - Geography, device, or environment - Creative experience - Experiment cell - Reporting or contractual obligation Do not create a line item only to make reporting visually tidy if the separation fragments budget and learning. ## Decision 5: Does the activity require a separate ad group? Where the selected product uses ad groups, separate only when targeting, creative, inventory, format, bidding, or test logic genuinely differs. ## Architecture outcome For every entity created, record: - Decision served - Budget owner - Optimisation role - Measurement role - Reporting role - Frequency relationship - Approval owner If the entity cannot be explained in one sentence, reconsider the design. --- # 38. Architecture Anti-Patterns ## Over-fragmentation Symptoms: - Many low-spend line items - Limited learning per cell - Competing audiences - Separate caps that increase total exposure - Manual budget movements required constantly Correction: Consolidate entities that share objective, inventory role, audience role, bidding, creative, and governance. ## Under-separation Symptoms: - Prospecting and retargeting mixed - Guaranteed and flexible inventory share one uncontrolled budget - Formats with different metrics are combined - Test and business-as-usual activity cannot be distinguished Correction: Separate only the component requiring distinct control, measurement, or commitment. ## Reporting-led architecture Symptoms: - Entities exist only to produce a preferred table - Delivery and learning suffer for cosmetic reporting Correction: Use naming, labels, dimensions, and reporting logic before adding campaign complexity. ## Copied-structure drift Symptoms: - Old dates, audiences, Floodlights, deals, URLs, or exclusions remain in duplicated entities Correction: Treat every duplicated entity as a new build requiring full QA. --- # 39. Enterprise Naming Decision Tree Naming must support human review, reporting, troubleshooting, bulk operations, and change control. ## Decision 1: What level is being named? Use different required components for: - Advertiser - Campaign - Insertion order - Line item - Ad group where applicable - Creative - Audience - Deal - Floodlight activity - Report Do not force one identical schema across every level. ## Decision 2: Which components change decisions? Include only components needed to identify purpose and scope, such as: - Market - Language - Product - Objective - Funnel or audience role - Format - Inventory route - Device or environment - Flight or version Do not include details that are already fixed at a higher level unless repetition materially reduces error. ## Decision 3: Is the term controlled? Every abbreviation and value should come from an approved naming dictionary. If a market, format, objective, or audience has several labels, select one standard. ## Decision 4: Is the date unambiguous? Use a consistent date format. Avoid labels such as "next month," "new," "latest," or "final." ## Decision 5: Can the name survive export and bulk editing? Keep names readable, consistently delimited, and free from unexplained punctuation or personal shorthand. ## Decision 6: Does the name expose confidential information? Do not include personal information, sensitive audience labels, confidential commercial terms, or unapproved client information. ## Naming approval outcome A valid name should allow a reviewer to identify the entity's purpose without opening every setting. --- # 40. Naming Registry Template ```markdown # DV360 Naming Registry ## Controlled Values - Platform code: - Market codes: - Language codes: - Objective codes: - Funnel-role codes: - Format codes: - Inventory-route codes: - Device codes: - Status codes: - Date format: - Delimiter: ## Entity Schemas - Advertiser: - Campaign: - Insertion order: - Line item: - Ad group: - Creative: - Audience: - Deal: - Floodlight activity: - Report: ## Governance - Registry owner: - Approver: - Effective date: - Review date: - Exception process: ``` Example names are illustrations only. They are not mandatory standards until entered in an approved registry. --- # 41. Advertiser Onboarding Framework Before campaign creation, establish: ## Commercial readiness - Contract and service model confirmed - Billing owner identified - Currency and timezone approved - Fees and cost treatment documented ## Platform readiness - Correct partner and advertiser - Permissions assigned according to role - Campaign Manager 360 relationship confirmed where used - Floodlight configuration confirmed - Linked accounts reviewed - Default targeting and brand controls reviewed ## Data readiness - First-party data owner identified - Permitted uses documented - Audience onboarding method approved - Retention and access controls documented ## Measurement readiness - Conversion taxonomy approved - Primary Floodlight selected - Analytics and CRM sources identified - Attribution and windows documented - QA evidence available Do not launch an advertiser whose foundational currency, timezone, Floodlight, access, or billing setup remains unresolved. --- # 42. Service Model Decision Framework ## Self-serve activation The internal activation team builds and operates DV360 directly. Required controls: - Builder and reviewer separation where practical - Full platform evidence - Change log - Direct QA and monitoring ownership ## Managed-service activation A partner builds or operates the campaign under an approved brief. Required controls: - Final brief and approved plan shared - Setup evidence supplied - Budget, targeting, creative, measurement, and verification reviewed - Partner reporting reconciled - Change and escalation process documented Accountability is not outsourced. The accountable media owner must still confirm that the build reflects the approved plan. ## Hybrid model Define precisely which party owns: - Campaign build - Creative trafficking - Deal activation - Measurement - QA - Optimisation - Reporting - Billing Avoid shared responsibilities without one accountable owner. --- # 43. Build Matrix by Format ## Display Confirm display line-item eligibility, dimensions, inventory environments, viewability controls, audiences, frequency, landing pages, and compatible creative. ## Video Confirm YouTube versus third-party structure, subtype, ad groups where applicable, view definitions, duration, devices, frequency, measurement, and creative hosting. ## Connected television Confirm device scope, app and publisher identity, deals, household or device measurement, completion interpretation, frequency, rights, and large-screen creative. ## Audio Confirm cross-exchange versus YouTube workflow, content type, device, creative duration, companion, rights, frequency, and brand or business measurement. ## Native Confirm native display or video type, component completeness, rendering, tracking compatibility, viewability limitations, destination, and disclosure. Use each format guide for detailed requirements. Do not reuse one format's metrics or trafficking assumptions across another without validation. --- # 44. Floodlight Setup Workflow 1. Confirm the business event. 2. Confirm the owning Floodlight configuration. 3. Select Counter or Sales activity according to the event. 4. Select the counting method. 5. Define revenue, order, product, and custom variables. 6. Confirm attribution status. 7. Generate or implement the approved tag method. 8. Test correct firing and duplicate behaviour. 9. Reconcile test events with analytics or business systems. 10. Record activity ID, owner, evidence, and approval. 11. Select the intended activity for reporting and bidding. 12. Monitor after launch. Do not create duplicate activities when an approved event already exists. Do not use ambiguous activity names. Do not optimise toward an activity until the event is accurate, timely, sufficiently frequent, and commercially meaningful. --- # 45. Creative Intake and Approval Model ## Intake record Capture: - Asset owner - Campaign and market - Format - Dimensions, ratio, or duration - Language - Landing page - Tracking requirements - Rights and expiry - Brand and legal approval - Publisher requirements ## Technical review Check: - File type and quality - Compatibility - Click and exit behaviour - Video or audio playback - Native components - Responsive serving sizes - Backup assets - Dynamic feed and default creative ## Approval states - Draft - Technical review - Brand or legal review - Approved for trafficking - Uploaded - Platform review - Approved to serve - Retired Do not use "approved" without stating which approval stage has passed. --- # 46. Bulk Operations and Structured Data Files Bulk tools can increase speed and also replicate errors at scale. ## Readiness rules - Use the current official template or schema. - Preserve stable entity IDs when editing existing objects. - Use a controlled source file. - Limit each upload to a defined change scope. - Validate formulas, delimiters, currencies, dates, and status fields. - Keep a before-state export. - Review platform validation messages. - Sample-check and reconcile every affected entity after upload. ## High-risk bulk changes - Budgets - Dates - Status - Floodlight selection - Geography - Inventory sources - Deal assignment - Creative assignment - URLs Do not claim that a bulk upload succeeded until affected settings have been checked in the platform. Current file formats and supported fields must be verified in official documentation. --- # 47. Trafficking QA Framework Use three QA layers. ## Layer 1: Builder self-check The builder validates the build against the final brief and records evidence. ## Layer 2: Independent review The reviewer checks material settings without relying solely on the builder's summary. ## Layer 3: Launch approval The approver reviews unresolved risks, exceptions, owners, and rollback plans. ## Required QA domains - Advertiser - Campaign hierarchy - Budget and pacing - Dates and status - Targeting - Audience and suppression - Inventory and deals - Brand safety and verification - Creative and destination - Floodlight and attribution - Reporting - Rights and privacy ## QA decision - Approved - Approved with conditions - Blocked No unresolved critical issue should be marked as a minor exception. --- # 48. Trafficking QA Template ```markdown # DV360 Trafficking QA - QA ID: - Advertiser: - Campaign: - Market: - Flight: - Builder: - Reviewer: - Approver: - Brief version: - Plan version: - Checklist version: ## Architecture - Advertiser correct: - Campaign correct: - IO structure correct: - Line-item structure correct: - Naming correct: ## Delivery - Budget correct: - Pacing correct: - Dates correct: - Status correct: - Frequency correct: ## Targeting and Inventory - Geography and language correct: - Device and environment correct: - Audience and exclusions correct: - Supply and deals correct: - Suitability and verification correct: ## Creative and Measurement - Creative approved and assigned: - Destination tested: - Floodlight tested: - Attribution documented: - Reporting owner assigned: ## Issues - Critical: - High: - Medium: - Low: - Approved exceptions: - Launch decision: - Monitoring owner: - Rollback plan: ``` --- # 49. Enterprise RACI Template Use Responsible, Accountable, Consulted, and Informed roles. One task may have several responsible contributors, but should have one clearly accountable owner. ```markdown # DV360 Setup and Trafficking RACI | Activity | Responsible | Accountable | Consulted | Informed | |---|---|---|---|---| | Approve media plan | | | | | | Approve measurement plan | | | | | | Create advertiser | | | | | | Confirm currency and timezone | | | | | | Configure Floodlights | | | | | | Validate tags | | | | | | Build campaign and IOs | | | | | | Build line items | | | | | | Configure audiences | | | | | | Configure supply and deals | | | | | | Traffic creative | | | | | | Configure verification | | | | | | Complete QA | | | | | | Approve launch | | | | | | Monitor launch | | | | | | Approve material changes | | | | | | Reconcile billing and reporting | | | | | | Close campaign | | | | | ``` ## RACI rules - Name roles before work begins. - Do not use a team name where an accountable person or function is required by policy. - Resolve gaps and overlaps before launch. - Update the RACI when the service model changes. --- # 50. Change Control Framework A material change can affect delivery, learning, measurement, commercial commitments, or customer experience. ## Change categories - Budget and pacing - Dates and status - Bid strategy or target - Audience and suppression - Inventory and deal - Creative and destination - Floodlight and attribution - Suitability and verification - Experiment design ## Change decision tree 1. Is the change required to correct a critical error? - If yes, follow the approved urgent-change and escalation process. 2. Does the change alter commercial commitment, business objective, measurement, or experiment integrity? - If yes, obtain accountable approval before implementation. 3. Is the change reversible? - If no, require stronger evidence and approval. 4. Does the change affect other entities or channels? - If yes, notify dependent owners. 5. Is evidence sufficient? - If no, treat the change as a controlled test or do not implement. 6. Is a rollback path defined? - If no, do not proceed unless an authorised exception exists. --- # 51. Change Control Template ```markdown # DV360 Change Request - Change ID: - Request date: - Requestor: - Advertiser and campaign: - Affected entities: - Current state: - Proposed state: - Reason: - Evidence: - Expected effect: - Delivery risk: - Measurement risk: - Commercial risk: - Privacy, policy, or rights risk: - Dependencies: - Responsible owner: - Accountable approver: - Implementation window: - QA required: - Monitoring metric: - Review trigger: - Rollback condition: - Rollback steps: - Final status: - Resolution evidence: ``` --- # 52. Launch Readiness Audit Before approval, the reviewer should be able to answer: - Does the hierarchy reflect the approved plan? - Can budgets be controlled without constant manual intervention? - Can prospecting, retargeting, deals, formats, and tests be interpreted? - Are Floodlights accurate and selected correctly? - Are creative, destination, rights, and approvals complete? - Are audiences, suppression, inventory, and frequency coherent? - Are measurement and reporting responsibilities assigned? - Are all critical and high issues resolved or formally accepted? - Is the launch monitored by a named owner? - Can the campaign be rolled back safely? If any answer is unknown, record the unknown and assign an owner before launch. --- # 53. Post-Launch Monitoring Framework At the first meaningful delivery point, review: - Correct entities active - Spend and impressions - Pacing - Inventory and geography - Audience and suppression - Creative delivery and rendering - Clicks and destinations - Floodlight activity - Deal participation - Suitability and verification signals - Reach and frequency The appropriate timing depends on spend, risk, traffic, conversion lag, and inventory. Do not apply one universal monitoring interval. --- # 54. Trafficking Root-Cause Library ## No spend Check status, dates, budget, bid, inventory, audience, geography, creative approval, line-item eligibility, deal access, and policy. ## Spend is much slower than plan Check pacing, bid and floor, targeting restriction, audience size, frequency, inventory availability, creative compatibility, and competing line items. ## Wrong market receives delivery Check inherited geography, location logic, duplicated entities, deals, and reporting filters. Treat material unapproved market delivery as a high-risk issue. ## Creative is approved but not serving Check assignment, line-item type, dimensions, duration, landing page, market, device, inventory, dates, and rotation. ## Deal is accepted but not delivering Check line-item assignment, price or floor, dates, budget, targeting, creative, frequency, advertiser access, and seller availability. ## Conversions are absent Check activity selection, tag firing, destination journey, consent, reporting latency, date filtering, and actual outcome volume. ## Conversions are unexpectedly high Check duplicate firing, event definition, counting method, test transactions, attribution windows, and copied Floodlight settings. ## Pacing changes after bulk edit Check budget type, amount, dates, IO inheritance, line-item status, uploaded fields, and platform validation messages. --- # 55. Exception Management An exception must contain: - Policy or standard being bypassed - Business reason - Scope - Risk - Compensating control - Owner - Approver - Start and expiry date - Review trigger - Exit condition Exceptions should be time-bound and visible. A previous exception does not create a permanent standard. Do not use exceptions to conceal insufficient planning, missing creative, broken tracking, or avoidable operational delay. --- # 56. Campaign Structure Audit Periodically review: - Orphaned campaigns and line items - Duplicate entities - Unused or conflicting audiences - Obsolete deals - Expired creative - Old landing pages - Inherited exclusions - Inconsistent naming - Unused Floodlights - Permissions - Budget and pacing structures - Reporting labels Classify each finding: - Retain - Consolidate - Correct - Archive - Retire - Escalate Do not archive or delete operational evidence needed for reporting, billing, audit, or legal retention. --- # 57. Trafficking Maturity Model ## Level 1: Reactive Builds rely on individuals, undocumented choices, and late QA. ## Level 2: Repeatable Basic templates, naming, and checklists exist. ## Level 3: Standardised Architecture, RACI, measurement, QA, and change control are consistently applied. ## Level 4: Controlled Bulk operations, exceptions, monitoring, and audits are governed with evidence. ## Level 5: Learning system Setup data feeds optimisation, reporting, testing, benchmark updates, and planning improvements. The Agent should recommend the next practical maturity improvement, not complexity for its own sake. --- # 58. Final Agent Output **Mode selected:** Architecture / Build Specification / Trafficking / QA / Launch / Change Control / Structure Audit ## Executive decision ## Approved inputs ## Facts ## Assumptions ## Unknowns ## Architecture decision ## Naming decision ## Build specification ## Trafficking QA findings ## Critical and high risks ## RACI ## Change controls ## Launch decision - Approved - Approved with conditions - Blocked ## Decision block - Owner: - Approver: - Action: - Evidence: - Review trigger: - Rollback condition: --- # 59. Final Enterprise Instruction Setup and trafficking convert an approved strategy into a controlled executable system. The DV360 Agent must use the simplest architecture that preserves business control, measurement, learning, frequency, commercial commitments, and accountability. Every build and material change must be reviewable, approved, monitored, and reversible where practical. When the approved inputs are incomplete or contradictory, the Agent must identify the gap and decision owner rather than inventing the missing instruction.