Google Ads Security and Conversion Infrastructure Runbook

Your Google Ads stack can fail in two opposite ways: access becomes too loose to trust, or security controls become so brittle that the people and automations responsible for measurement are locked out. Meanwhile, a conversion tag can deploy cleanly and still measure the wrong action.

The practical goal is not merely to enable multi-factor authentication or create a Google Tag Manager tag. You need a traceable path from an authorized identity to a tested conversion event, with an owner and a recovery route at every handoff. This runbook shows you how to build that path without turning an access change or tagging shortcut into a campaign outage.

Key takeaways

• MFA enforcement matters most when someone creates a new OAuth 2.0 refresh token. An integration that works now can still fail during reconnection, onboarding, or credential replacement.
• Service accounts remain the better fit for supported automated or offline workflows, but they still need explicit ownership, limited access, and a tested handoff process.
• A pre-filled Google Tag Manager configuration can remove transcription work. It cannot decide whether you selected the right container, conversion action, trigger, or counting logic.
• Never revoke a working credential or remove a working conversion tag until its replacement has passed a controlled test. Otherwise, your rollback path disappears at the moment you need it.
• Security and measurement should share one release record: identity owner, authentication method, Ads account, conversion action, GTM container, test evidence, publisher, and rollback decision.

Map authentication before MFA exposes a hidden dependency

Google’s announced rollout made MFA mandatory for new user-based Google Ads API authentication from April 21, with enforcement expanding over the following weeks. The important boundary is token creation: OAuth 2.0 refresh tokens that were already in use were not invalidated by the change, but fresh authentication requires the additional identity check.

That boundary explains why an account can look healthy until a routine maintenance task causes a failure. A scheduled process may continue using its existing refresh token, while a new employee, replacement integration, revoked credential, or reconnection attempt reaches the MFA gate. Passing today’s automated run is therefore not proof that your recovery workflow is ready.

Start with an authentication inventory. Do not begin by changing credentials. For every connection that can read from or act on a Google Ads account, record:

• Workflow: the API job, reporting transfer, desktop tool, script, dashboard, or application that depends on access.
• Authentication pattern: user-based OAuth or a service account.
• Named owner: the person responsible for approving access, completing MFA, and handling recovery.
• Operational owner: the person who can prove the workflow still runs correctly after an authentication change.
• Credential event: what would force a new authorization flow, such as onboarding a user, replacing a connection, or rebuilding an integration.
• Recovery route: who can restore access if the primary owner is unavailable, without sharing a personal password or MFA prompt.
• Evidence: the last successful controlled authentication and the workflow result it enabled.

For user authentication, make the MFA rehearsal realistic. Use the same consent and token-generation path that the production workflow expects. Confirm that the designated person can complete the second factor, which may be a phone prompt or an authenticator app. Then verify that the resulting credential reaches the intended account and supports the intended workflow. A successful Google sign-in alone is not enough.

Choose user authentication or a service account deliberately

Keep user-based OAuth when the workflow is genuinely tied to a person’s authorization and an interactive sign-in is acceptable. Use a service account for a supported automated or offline workload when the connection should survive staff changes and should not depend on a person responding to an MFA prompt. Google left service-account workflows outside the new MFA requirement and recommends them for automated or offline scenarios.

Do not migrate to a service account merely to avoid MFA. A service account is a machine identity, not an exemption from governance. Confirm that the application supports it, grant only the access the workflow needs, document who owns that identity, and test what happens when its permissions or connection must be replaced.

Expand the inventory beyond custom API code. The same security change reaches authentication used by Google Ads Editor, Scripts, BigQuery Data Transfer, and Data Studio. If those tools are owned by different teams, give one person responsibility for the complete dependency map. Otherwise, each team may believe another team owns the failing sign-in.

Most importantly, do not revoke the working refresh token while you are only testing its replacement. Prove the new path first, record the result, and then retire the old credential through a reviewed change. Revoking first can stop reporting or automation without leaving you a quick way back.

Use direct GTM setup to remove copying, not judgment

Google Ads has tested a Set up in Google Tag Manager option inside the conversion setup flow. Where the option is available, you can select a GTM container and open a suggested, pre-filled tag configuration instead of manually carrying the conversion ID and label between products.

Treat this as a safer handoff, not an automatic implementation. It reduces opportunities for transcription errors, but it does not know whether your chosen website action represents a qualified lead, a completed sale, an internal test, or an accidental page view. It also cannot resolve a poor container naming convention or decide whether an existing tag will overlap with the new one.

The integration is described as a test, so do not make a launch deadline depend on the button appearing in your account. If it is absent, continue with the established manual setup and apply the same review process. Availability and implementation correctness are separate questions.

1. Confirm the conversion definition. Write down the user action that should count, where it occurs, and what must not count. Do this before opening GTM.
2. Match the account and container. Verify the Google Ads account, conversion action, website, GTM account, and container as one set. Similar client or environment names are not proof of a match.
3. Inspect the pre-filled values. Check the conversion ID and label against the intended conversion action even when Google populated them. Automation should reduce copying, not eliminate review.
4. Review the trigger separately. The tag configuration identifies where data should go; the trigger determines when it goes there. Confirm that the trigger represents the business event you defined in the first step.
5. Check for an existing implementation. Search the container for tags and triggers that already send the same action. Publishing a second path may produce duplicate events or conflicting behavior.
6. Test before publishing. Use GTM’s preview process and complete a controlled conversion path. Confirm that the tag fires on the intended action and remains silent on nearby actions that should not count.
7. Publish a traceable version. Record the conversion action, reason for the change, reviewer, test performed, and rollback instruction in the version description or release record.
8. Verify both ends. Confirm the expected firing behavior in GTM and then confirm that Google Ads recognizes the intended conversion setup. A passing browser-side test proves the trigger ran; it does not by itself prove that the account mapping is correct.

Avoid deleting the old tag before the new configuration has been verified. At the same time, do not publish two equivalent live paths and hope to compare them later. Modify the existing implementation when that is the cleanest route, or make the old and new triggers mutually controlled during the release. Your rollback should restore a known configuration, not create a second unknown one.

Operate access and tagging as one controlled release

Authentication and conversion tracking are often assigned to different specialists, but they meet at the same operational boundary. The person publishing a tag needs reliable account access. The automation consuming conversion data needs a stable identity. The campaign owner needs confidence that the event still means what its name claims.

Use one release record for both sides. In a larger team, assign an access owner, GTM implementer, independent reviewer, and business owner for the conversion definition. In a smaller team, one person may hold several roles, but the checkpoints should remain separate. Pause between configuring, reviewing, publishing, and validating so that familiarity does not replace evidence.

1. Freeze unrelated changes. Keep other credential, container, and conversion-action edits out of the same release so a failure has a narrow set of possible causes.
2. Capture the known-good state. Record which automation currently succeeds, which tag and trigger currently fire, and which conversion action they serve.
3. Prove recovery access. Confirm that the named owner can complete a fresh user-authentication flow with MFA, or that the supported service-account workflow can be restored by its documented owner.
4. Stage the measurement change. Build or review the pre-filled GTM configuration without publishing it. Confirm the account, action, ID, label, trigger, and duplication check.
5. Run the controlled path. Exercise the actual conversion behavior and preserve enough evidence for another person to understand what was tested.
6. Publish and validate. Confirm the container version, the live firing conditions, the Google Ads destination, and the next successful dependent automation run.
7. Retire only what has been replaced. Revoke an old credential or remove an old tag only after the new path is proven and the rollback decision is documented.

Use the failure layer to choose your first check

When something breaks, identify whether the failure occurs at identity, authorization, container configuration, trigger logic, publishing, or destination mapping. Rolling back everything at once can hide the actual defect.

At your next planned change window, exercise one fresh authentication flow and trace one controlled conversion from the user action through GTM to the intended Google Ads action. If either path lacks a named owner, test evidence, or a safe rollback, fix that gap before you scale the campaign or add another integration. Your infrastructure is ready when another authorized person can understand it, test it, and recover it without guessing.

References

• CrushPress.AI — Google Ads API: Embrace Enhanced Security with Multi-Factor Authentication
• CrushPress.AI — Streamline Conversion Tracking with Google’s New GTM Integration