The Google Ads API now requires multi-factor authentication on every new OAuth 2.0 refresh token, with rollout starting April 21, 2026 and full enforcement over the following weeks (Google Ads Developer Blog, 2026). Existing refresh tokens keep working. New ones do not.
That distinction is the entire story. Your WooCommerce tracking plugin will not break on April 21. It will break on whichever Tuesday your plugin needs to reconnect — plugin reinstall, account migration, agency rotation, employee offboarding, or token revocation — at which point the Google account holder needs 2-Step Verification enabled, or the new token never mints.
What April 21, 2026 Actually Changed
Google’s Ads Developer Blog announced the change on April 17. Existing refresh tokens continue to work without interruption — only new authentications generating new OAuth 2.0 refresh tokens require MFA (Search Engine Land, 2026). Most coverage of the announcement either skipped this distinction or buried it. It matters because it tells you whether your store has a problem today (no) or a lurking maintenance debt with an unknown trigger date (yes).
The scope is broader than raw API access. The requirement extends to Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer, and Looker Studio (formerly Data Studio) (Shopifreaks, 2026). Anywhere a WooCommerce store touches Google Ads through user credentials — directly or via a plugin — the same rule applies once the user re-authenticates.
One critical exemption: service account workflows used for automated/offline use cases are NOT affected by the change (Google Ads Developer Blog, 2026). Service accounts are non-human credentials authenticated via a JSON key file rather than the OAuth consent screen. They have no 2-Step Verification dependency because they have no person attached.
The Five Scenarios That Force a WooCommerce Plugin to Reconnect
Existing tokens last until something invalidates them. WordPress runs approximately 43.5% of websites globally (W3Techs, 2024), and the most popular Google Ads tracking plugins — Conversios (60,000+ stores), Google for WooCommerce, FunnelKit Pro, Pixel Manager Pro, and similar — all rely on user-OAuth refresh tokens. Any of the following forces a re-auth.
1. Plugin Reinstall or Major Update
Every plugin maintainer eventually ships an update that requires re-authorisation — schema migration, vendor library upgrade, bug fix to the OAuth handshake itself. When the plugin update notice asks “reconnect to Google Ads,” that is a new-token mint event. If the original Google account does not have 2SV enabled by then, the reconnect fails.
2. Google Account Migration
The store owner moves to a new Google Workspace, the agency-of-record changes, or the original setup used a personal Gmail that needs to be migrated to a business account. Account migration is a token-rotation event by definition — the new account mints the new token, and the new account needs 2SV.
3. Agency Rotation
The previous agency disconnects, the new agency connects. New OAuth grant, new refresh token. The new agency’s Google account now holds the credential, and that account needs 2SV before the connection completes.
4. Employee Offboarding
The team member whose Google account originally authorised the plugin leaves. Their account is suspended or deleted. The refresh token sitting in your plugin’s database now points to a credential that no longer exists, and the next API call fails. The fix is a re-authorisation by a current employee — and that employee’s account needs 2SV.
This scenario is the one most stores discover only when conversion tracking suddenly stops, weeks after the offboarding.
5. Token Revocation or Admin Policy Change
Three enforcement scenarios exist with different effects on existing tokens (Google Ads API documentation, 2026). If a Google Workspace admin enforces 2SV at the org level, existing tokens may be invalidated when the admin policy changes. If a user manually revokes the token via myaccount.google.com, it dies immediately. Either case forces a fresh token mint, which forces 2SV on the user.
What to Audit Today
Two questions, fifteen minutes.
First: which Google account currently holds the OAuth token for every plugin connecting your WooCommerce store to Google Ads? Open each plugin’s settings page — Conversios, Google for WooCommerce, FunnelKit, whatever you run — and read the connected account name. Write it down.
Second: does that Google account have 2-Step Verification enabled? Sign into that account at myaccount.google.com → Security → 2-Step Verification. If it says “On,” you are protected against the next forced re-auth. If it says “Off,” enable it before the next plugin update.
This audit is the same shape as the one we recommended after the April 1 Customer Match upload break — see Google Ads Customer Match Uploads Broke on April 1. Your Lists Are Going Stale.. Same theme: silent Google Ads API surface area changes hitting WooCommerce stores via plugins they do not audit.
The Service Account Alternative
The architectural answer is to stop depending on user OAuth for production tracking. Service accounts authenticate via a JSON key file, have no human attached, and are explicitly excluded from the April 21 MFA requirement. The credential lives on your server. Re-authorisation is a configuration change rather than a person-and-phone event.
This is the broader pattern we covered in Why You Should Never Start With GTM for Your New WooCommerce Store in 2026 and the practical setup in The Clean Start: How to Set Up WooCommerce Tracking in 2026 Without GTM. Depending on the user-OAuth plumbing for production conversion tracking is a structural fragility — the MFA change is one of many calendar-triggered failure modes that flow from it.
How Server-Side First-Party Sidesteps the User-OAuth Cycle
Transmute Engine™ is a dedicated Node.js server that runs first-party on your subdomain (e.g., data.yourstore.com); the inPIPE WordPress plugin captures WooCommerce purchase events server-side and sends them via API to Transmute Engine, which authenticates to Google Ads using service account credentials where applicable. The user-OAuth re-auth burden moves off the WordPress plugin and into a credential pattern Google’s MFA requirement does not touch.
Key Takeaways
- April 21, 2026 did not break your tracking. Existing OAuth refresh tokens still work. The break is whichever Tuesday your plugin reconnects.
- Five forced-reconnect scenarios trigger the MFA requirement: plugin reinstall, account migration, agency rotation, employee offboarding, token revocation.
- Audit today: Which Google account holds each plugin’s OAuth token? Does that account have 2SV enabled?
- Affected plugins include Conversios (60,000+ stores), Google for WooCommerce, FunnelKit Pro, Pixel Manager Pro — any plugin using user-OAuth for Google Ads.
- Service accounts are immune. The cleaner architectural path for any production WooCommerce-to-Google-Ads pipeline.
Frequently Asked Questions
No, not on April 21. Existing OAuth 2.0 refresh tokens continue to work without interruption. The MFA requirement only triggers when a new refresh token needs to be minted — which happens whenever the plugin is reconnected, the original Google account is migrated, the token is revoked, or admin policy changes invalidate it. The break is not on April 21; it is on whichever future Tuesday your plugin happens to need a fresh token.
Any plugin that connects WooCommerce to Google Ads via the user-OAuth flow — which is virtually all of them. That includes Conversios (60,000+ stores), Google for WooCommerce, FunnelKit Pro, Pixel Manager Pro, and similar. The plugin itself is not the problem; the authorization flow is. Until the underlying Google account holder enables 2-Step Verification, any forced re-auth on these plugins fails to mint a new token.
User OAuth grants a plugin access using a human’s Google account credentials via the OAuth consent screen. Service accounts use a non-human Google Cloud service account with a JSON key file. The April 21, 2026 MFA requirement applies only to user-based authentication. Service account workflows are explicitly excluded from the change and are the architecturally cleaner path for any production WooCommerce-to-Google Ads pipeline.
Two questions. First, which Google account currently holds the OAuth token for every plugin connecting your WooCommerce store to Google Ads? Open each plugin’s settings page and check the connected account. Second, does that account have 2-Step Verification enabled? If the answer to either is unclear, treat it as a maintenance debt with an unknown trigger date and resolve it before the next forced re-auth.
If you operate at any scale where WooCommerce-to-Google-Ads connectivity is production-critical, yes. Service accounts remove the human-2SV dependency entirely — the credential is non-human, the JSON key file lives on your server, and re-authorisation is a configuration change rather than a person-and-phone event. The architectural pattern is the same one used by every server-side tracking system that does not depend on a user OAuth grant.
Audit which Google account holds your plugin’s OAuth token. Enable 2SV on that account today, or move the credential off user OAuth before the next forced reconnect. Start at seresa.io.
