Delegating Paid Media Operations: Access Levels and Change Guardrails

Published September 18, 2026.

The decision this research supports

A founder or small team that wants to delegate paid media operations faces a specific buying decision: how much access should the person doing the work receive, and what stops an ordinary mistake from becoming an expensive or policy-relevant event? This research supports that decision. It does not argue for or against delegation. It sets out what the official platform documentation actually establishes about access levels, conversion reporting, advertising policy, and multi-account structure, then translates those facts into guardrails a small team can adopt before handing over any account.

The practical question is narrow. Which operations can be performed with read-only visibility, which require the ability to modify campaigns, and which changes should always remain with an accountable owner? A useful paid media arrangement answers those questions in advance. If the answers are improvised after an incident, the team is treating access design as an afterthought. This study treats it as the core of the engagement.

What the primary sources establish

Four sources inform the analysis. The Google Ads API documentation on access levels and permissible use describes distinct tiers of access. Documented levels include standard access, basic access, and read-only access, each carrying different permitted operations. The same source notes that use of the interface is bounded by permissible use rules, so holding a technical access level does not grant unlimited freedom to act. This distinction matters for delegation because it separates what an account holder can technically reach from what they are permitted to do with it.

The Google Ads API conversion management documentation describes how conversion actions are configured and how conversions are reported back. Conversion actions are the measurable outcomes a campaign is optimized toward, and their configuration determines what the reporting represents. This is the factual basis for insisting that whoever reports on paid media describe the setup that produced the numbers, not just the totals.

Google's advertising policies govern what may be advertised and how. They define categories of restricted or prohibited content and set expectations for the ads themselves. They are not a technical access control, but they bound the space of legitimate changes. An operator who does not know the policy boundary can create a compliance problem while making an otherwise routine edit.

Microsoft Advertising documents a customer and account hierarchy used to manage multiple accounts. The hierarchy separates an administrative layer from the individual advertising accounts beneath it, which allows access to be granted at different levels and scopes. That structure is the practical mechanism for giving a delegated operator reach into specific accounts without control over the whole organizational container.

These sources are official and descriptive. They tell us how platforms are built to be used. They do not provide performance benchmarks, and none of them prescribes a vendor or service model. Any operating recommendation below is inference drawn from that structure and from general operational reasoning, not a claim the sources themselves make.

Findings

Access levels are a spectrum, not a switch

The first finding is that access should be granted in graduated tiers rather than as a single permission. Read-only access supports auditing, reporting, and diagnosis without any ability to change a live campaign. Basic or standard access supports editing, depending on the documented tier and the operations permitted. Because the levels are distinct, a team can match each operator to the smallest level their tasks require. A delegated specialist who builds reports and drafts proposed edits does not need the same reach as an owner who authorizes spend changes.

Conversion configuration is part of the report

The second finding is that conversion reporting cannot be separated from conversion configuration. The conversion management documentation makes the chain explicit: conversion actions are defined, then activity is attributed and reported against them. A report that presents cost per acquisition without describing which conversion actions were active, and how they were configured, is not self-explanatory. Delegation therefore includes an obligation to document the measurement setup alongside any performance summary.

Policy compliance is a constraint on every change

The third finding is that advertising policies apply to the work itself. Access determines what an operator can touch; policy determines what is acceptable to publish or promote. These are independent constraints, and passing one does not satisfy the other. A change can be fully within a granted access level and still violate an advertising policy. That is why change review must consider the content and the claim, not only whether the operator had permission to press the button.

Multi-account structure enables scoped delegation

The fourth finding is that the customer and account hierarchy provides a built-in way to scope access. A team managing several advertising accounts can grant an operator entry to a subset of accounts rather than to the entire organizational structure. This lets a small business delegate routine work in one account while keeping sensitive or experimental accounts separate. The hierarchy is the structural reason least privilege is achievable in practice rather than merely aspirational.

Operating model

A workable operating model follows from those findings. Start with read-only access for any new operator. Reporting, auditing, and diagnostic work almost never require the ability to mutate live campaigns. Use that read-only period to establish what the account currently contains and what its conversion setup looks like. If the source material shows that read-only is a documented level, then defaulting to it costs nothing and removes a large class of risk during onboarding.

Promote access only when a defined task requires it. Write the task down, name the specific account or accounts it touches, and confirm that the higher tier is genuinely necessary. When the hierarchy permits scoping to individual accounts, use that scoping instead of a broad grant. Access that is not needed for a named task should not be granted in anticipation of future convenience.

Separate the authority to propose from the authority to publish. An operator can prepare a proposed change, including the reasoning and the affected entities, while a named owner authorizes the change that alters spend, targeting, or public copy. This preserves speed for analysis while keeping irreversible or expensive actions with someone accountable. A simple change register, kept alongside the account, records what changed, when, why, and who authorized it. The pattern is described in the change register discussion, and the broader service model for delegated paid operations is outlined in the related service overview.

Make reporting verifiable by tying it to the conversion configuration. Before a performance summary is trusted, confirm which conversion actions were active and how they were defined. If the setup changed during the period, the report should say so. A reviewer who can trace from the summary back to the configuration can judge the result; a reviewer who sees only a total cannot. This is also where cost assumptions should stay honest, since the economics of delegation depend on scope and effective hours, a topic examined in the cost benchmark analysis.

Route uncertain cases rather than resolving them silently. When a requested change touches a restricted category, an ambiguous policy edge, or an outcome the operator cannot verify, it should leave the routine path and wait for a decision. The exception handling discipline is directly applicable: preserve the observation, state the uncertainty, and hand the decision to the accountable owner instead of guessing. A short queue of genuine exceptions is evidence that the guardrails are working.

Finally, revisit access at a fixed interval. Access granted for a project tends to persist long after the project ends. A periodic review that removes unused grants, confirms that each operator still needs their tier, and checks that the change register has kept pace with actual edits keeps the arrangement honest. Least privilege is a practice, not a one-time setting.

Boundaries and limitations

Several limits apply. The sources are platform documentation, not independent performance research, so nothing here quantifies the benefit of delegation or the frequency of errors. The access-level categories and their names are defined by Google for the Google Ads API; other platforms and interfaces organize permissions differently, and a team should verify the current model for each platform it uses rather than assume the same tiers exist.

The customer and account hierarchy is documented by Microsoft Advertising for its own system. Its usefulness as a scoping mechanism is an inference about how a small team can apply the structure, not a claim that the documentation recommends a particular delegation policy. Likewise, the finding that policy compliance is independent of access level is a logical consequence of what the two sources govern, not a statement that any specific change is permitted or prohibited.

The operating model is general guidance. It does not substitute for legal, contractual, or platform-specific review, and it assumes the accountable owner retains decision authority over spend and external communication. Conversion configuration changes over time, so any reporting claim is only as current as its documentation. All sources were checked on September 18, 2026, and platform documentation can change after that date.

Evidence-led conclusion

The official sources establish four facts that a small team can build on. Access comes in distinct levels with different permitted operations. Conversion actions are configured before they are reported. Advertising policies constrain what may be promoted regardless of access. And a customer and account hierarchy allows access to be scoped across multiple accounts. Together these facts support a simple conclusion: delegate paid media operations with the least access the task requires, document the conversion setup behind every report, route policy-sensitive or uncertain changes to a named owner, and review access on a schedule. Access design is a buying decision. A team that settles it before onboarding gets the benefit of delegation without surrendering control of the account.

Sources

• Google for Developers, Google Ads API, Access levels and permissible use
• Google for Developers, Google Ads API, Conversion management
• Google, Google Ads policies
• Microsoft, Microsoft Advertising, Customer accounts