Your marketing coordinator sends a message on a Tuesday afternoon. There is a banner in the Google account offering to upgrade something, it mentions Tag Manager, and she wants to know whether she should click it. It looks like housekeeping. Nobody has asked you to approve a change to the website, because as far as anyone can tell this is not a change to the website.
It is not, technically. It is a change to who can change the website, which on most association sites is a larger question, and on one specific page it is a compliance question.
What Google Actually Announced
On August 20, Google documented three changes to its tagging products on its own Tag Manager help pages. Two are cosmetic or narrow. One is not.
- A redesigned overview screen. Container-wide settings gathered into one place, with triggers, variables, templates and folders moved into a collapsible advanced section.
- A visual tagging tool. Point-and-click event and conversion setup, choosing elements on the page rather than writing configuration. It is in beta and currently limited to purchase conversions in Google Ads, expanding to more cases through the year.
- Existing Google tags upgraded into full Tag Manager containers. A property running nothing but a hardcoded gtag snippet gains the whole Tag Manager interface: tag creation, version control and debugging.
Two corrections to how this is being described. First, Google states that the upgrade is not automatic, that no changes will be made on your behalf, and that you can choose whether to adopt the new configuration. Second, Google states that the upgrade does not change the in-page behavior of your existing tags. Nothing breaks and nothing starts firing differently. If you have read that this is being done to you on Google's schedule, that is not what the documentation says.
Google has not published a rollout date, and we are not going to invent one. There is no per-account schedule we could find, so treat this as something that will appear when it appears rather than as a deadline. What follows is worth doing before the banner shows up, which is a different kind of urgency from a countdown.
Why an Opt-In Still Matters
Plenty of association sites run a bare gtag snippet on purpose, and the reason is rarely written down anywhere. It is that adding a script to the site requires a developer. That is not a security control anybody designed. It is a side effect of the setup, and it has been quietly doing the work of one for years.
The upgrade removes that side effect, and it does so through a button in a marketing account. The person deciding is not deciding what they think they are deciding. They are answering a question that looks like "do you want the newer interface" when the actual question is "should the people with access to this account be able to put third-party JavaScript on any page of the website without a code review." Those are both reasonable questions. Only one of them is being asked.
For most pages, the honest answer is that it is fine. A container that lets your team add a heat-mapping tool to the events section without opening a ticket is a genuine improvement, and Tag Manager has version history so you can see what changed and roll it back. There is one page where the calculus is different.
The Page Where This Costs Money
Your donation page, dues renewal, or event registration. What applies there depends entirely on how card data reaches your processor, and the three models are treated very differently. Find yours before reading the other two.
A full redirect to the processor. Your site links out, the visitor enters card details on the processor's own domain, and comes back afterward. Per the Council's FAQ 1588, the script-related eligibility criterion does not apply to you. Adding tags is a marketing decision, not a compliance one.
An embedded payment form in an iframe. This is where most association donation pages sit. Since the January 2025 revision of SAQ A, effective March 31, 2025, requirements 6.4.3 and 11.6.1 were removed from that questionnaire and replaced with an eligibility criterion: you confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems. That is an attestation you sign. A container that lets somebody add a script to that page without a record is precisely what makes it harder to sign honestly, and a merchant who cannot confirm it does not stay on SAQ A.
Card fields hosted in your own page. You are not eligible for SAQ A at all. Requirements 6.4.3 and 11.6.1 apply to you in full and have been mandatory since March 31, 2025: an authorized inventory of every script on the payment page, written justification for each, and tamper detection. An unlogged script here is a finding, not an annoyance.
The consequence of losing SAQ A eligibility is the part that gets underestimated. It is not a fine. It is dropping to SAQ A-EP or SAQ D, which brings well over a hundred additional requirements into scope for an organization that budgeted for none of them.
Three Things Worth Doing First
None of these require the upgrade to have arrived, and all three are worth doing regardless of what you decide about it.
- Audit who has access to the Google account. Not who should have access. Open the account and read the list. Former staff, a previous agency, a contractor from a campaign that ended, a personal address somebody used once. Publish rights in a container that can reach the payment page is the permission that matters here.
- Turn on two-step publish approval before anyone adopts a container. Tag Manager supports requiring approval before a change goes live. Enabling it costs nothing, and it converts the new capability from a risk into what it should have been: a faster path with a human check at the end.
- Inventory what already runs on the payment page. Do this now, while the list is short and nobody has added anything. Every script, what it is, who asked for it, and whether it is still needed. If you are in the iframe or hosted-fields case, this list is not optional housekeeping, it is the evidence behind an attestation you have already made or are about to.
When You Can Ignore This Entirely
If your site already runs Tag Manager, nothing here is new to you; the container you have is the container being described, and the access audit is still worth an hour. If you take no payments on your own domain and never intend to, the compliance half does not apply and the rest is a governance preference rather than a risk. And if you decline the upgrade, your tags keep working exactly as they do today, which is a legitimate answer that nobody at Google will hold against you.
Have Us Look Before Anyone Clicks
Send us access to your Google Tag Manager and Google Ads accounts, or just the URL of your donation page. You will get back a written page. It names who currently holds publish rights and which of them should not, and which of the three payment models your page actually uses, which settles which PCI requirements apply to you. It lists every script currently loading on that page with a note on what it is doing there, and says whether approval workflow is on. If your setup turns out to be a full redirect with three people on the account and nothing to fix, the page will say that in a paragraph. For organizations that would rather not revisit this every time Google ships a change, the same review is where an ongoing arrangement starts.