Approval is a decision, not just a design review
A responsible approval confirms that the work matches the objective, offer, audience, destination, measurement plan, and agreed limits. Visual review matters, but it is not enough. A button can work and lead to the wrong page; a correct ad can point to an untracked form; and a tag can collect more than the approved purpose allows.
Separate who produces, reviews, approves, and publishes. A business owner validates scope and claims; a technical reviewer checks function and security; and the media operator confirms configuration and authorized spend. One person may hold several roles in a small organization as long as that is documented. Silence should never be treated as automatic approval.
- Identify content, technical, media, data, and business reviews.
- Name the producer, reviewer, approver, and publisher.
- Document combined roles and responsibility conflicts.
- Never treat silence as approval.
Design a repeatable workflow
The workflow can be simple: request, brief, production, review, revision, approval, publication, and verification. What matters is that each transition has an exit condition and a record. The request includes the objective and deadline; the review points to a specific item and evidence; approval identifies a version; and verification checks the live destination and signals.
Do not approve changes through screenshots disconnected from the real destination. Review a page in the published environment or an equivalent staging environment, inspect campaign settings and assets, and run a controlled tracking test. If the scope changes, return the work to briefing or document the exception.
- Define states and exit conditions for every stage.
- Connect reviews and approvals to an identifiable version.
- Verify the destination and tracking after publication.
- Record scope changes as exceptions or new requests.
Access and assets need governance
The process fails when a reviewer lacks access or when a critical account belongs to one individual with no backup. Inventory the domain, hosting, analytics, tag manager, ad platforms, social profiles, and working files. Use institutional accounts, least-privilege access, and appropriate authentication. Review access does not need to equal publishing access.
For higher-risk changes, include backups, staging, and rollback. Before granting a vendor access, define its duration, purpose, and removal process. Do not share passwords in a spreadsheet or chat. Security is part of approval, not a task postponed until after launch.
- Inventory accounts, assets, owners, and permissions.
- Use institutional, minimal, and revocable access.
- Maintain backups, staging, and a rollback path.
- Never distribute credentials in spreadsheets or messages.
Record decisions and learn from exceptions
The record does not need to preserve the entire conversation. It should keep the approved version, date, owner, scope, accepted risks, and reason for a material change. If something launches with an open issue, identify who approved it and when it will be reviewed. This history keeps the team from reopening decisions without context and helps investigations after publication.
Use exceptions to improve the workflow. Repeated rejection for a missing offer may indicate an incomplete brief; post-launch failures may reveal missing QA; blocked access may expose an institutional dependency. Review the process in cycles without turning every mistake into a heavy rule. Controls should remain proportionate to real risk.
- Keep the version, date, owner, scope, and accepted risk.
- Record open issues, authorization, and review dates.
- Classify exceptions by cause, not by blame.
- Simplify controls that do not reduce material risk.
Reference sources
- Google Ads — account access levels — accessed September 6, 2026.
- Google Analytics — access management — accessed September 6, 2026.
- Google Tag Manager — user permissions — accessed September 6, 2026.