Standing service gtm-container-changes-tested-before-each-publish · revised 11 October 2026
Standing service
Have each Tag Manager change tested in preview before you publish it
Each container change you request is built in a workspace and tested against your event list before you publish, with a monthly change log.
This starts a conversation by email. Nothing is charged, and nothing is checked, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Edits to a Tag Manager container are published by whoever has access, often without testing the events that were already working. A change to one trigger can disable or double another tag, and without a log nobody can say which version caused it.
Who it’s for: A marketer or agency that changes tags often and wants every change tested and documented before it goes live.
Usually starts when: A tag edit once broke an unrelated event, or no one can say which change introduced a problem.
The result: Each change you request in a month is built in a workspace, tested in preview against your agreed event list with before and after results, saved as a named version, and handed to you to publish, with a monthly change log.
What stays true, and what we do about it
No turnaround guarantee is published for this new service. A target is agreed in writing before it starts.
Turnaround hours are agreed in writing before the service starts. At launch the service is not staffed round the clock.
What must remain true
- Every change we prepare has been tested in preview against the agreed event list before it reaches you
- Every change has a version note saying what changed and what was tested
What we watch
- Your change requests, sent by email or the agreed route
- The Tag Manager workspace and preview for the container
- The version history of the container
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| You send a change request. | We build it in a workspace, run the agreed events in preview before and after, and send you the evidence and a named version to publish. |
| A month ends. | We read the container's publish history for the month and mark any version that was published outside this process. If one is found, we run the agreed events against the live container and report what changed. We send the change log: requested, tested, published, declined. We do not watch the container between these reads. |
We do on our own
- Build and preview-test changes in a workspace
- Save a named version without publishing, using the Approve role
- Run the agreed events against the live container when the monthly read of the publish history finds a version published outside this process
We ask you first
- Publishing any version
- Changing the agreed event list
- Removing a tag that another team owns
We escalate to you when
- A requested change would break an agreed event and the request cannot be reshaped
- Requests pass four in a month
- A live version breaks an event and no one on your side can publish a fix
How you know it held. Each change comes with before and after preview evidence, and each month's log lists every change and what was tested.
How we keep it true
This service is never finished. Each month's log shows what changed and what was tested, and it continues until you end it.
Clean up one Google Tag Manager container so every tag has a reason Job Optional
One Tag Manager container is inventoried, stripped of unused and duplicate tags, and saved as a named version for you to publish, with a before and after test.
Once, if the container needs it
A clean container is easier to test; the clean-up is the same job you can buy on its own.
What is included, and what is not
- For each change: a prepared workspace, preview evidence before and after, and a named version note
- A statement of what was not tested
- A monthly log of requested, tested, published and declined changes
Included
- One container and one site, with up to four change requests a month. A change request is one edit to the container's existing tags, triggers or variables, such as changing, pausing or removing one; building a new event or repairing a broken one is the matching one-off job
- A workspace for each change, tested in preview against up to ten agreed test events before and after
- A named version with a plain-language note for each change
- A monthly change log
Not included
- New measurement plans, new platforms or large rebuilds, which are projects
- Publishing: you publish every version
- Changes to the site code, the consent tool or the server container unless added in writing
- Round-the-clock cover or a guaranteed turnaround
- Any promise about ad performance, revenue or rankings
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For each change, the agreed events fire in preview after the change exactly as they did before it, except for the events the change was meant to alter.
Evidence: Before and after preview screenshots attached to the version note.
Every version we prepare has a note naming the change, the tags and triggers touched and the events tested.
Evidence: The version list in the container.
The monthly log lists every request with its outcome.
Evidence: The written monthly log, comparable with your own request emails.
Sign-off. You review the evidence and publish each version yourself. A change counts as delivered when you publish it.
If it fails. If we cannot make a change without breaking an agreed event, we say so, explain what it would take and it does not count against the four. You can end the service at the end of any month.
When it fits, and when we stop
It fits when
- You can grant Approve access to the container, the level that can create versions but cannot publish
- You can agree a list of up to ten events that must keep working
- A person on your side requests changes and publishes
We stop and tell you if
- Many people publish to the container without going through the workspace process
- Requests regularly exceed four a month
- No test route exists for the events that matter
What could go wrong
Each change is a named version, so you can republish the previous version at any time. Ending the service leaves the container as it is.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A tested change still breaks something that is not on the event list. | Each note states what was and was not tested, and the event list can be extended with your approval. |
| Someone publishes an untested change in parallel. | The monthly read of the publish history lists any version published outside this process, and the agreed events are run against the live container when one is found; we do not watch the container between those reads. |
Each prepared version is checked by a reviewer separate from the work that produced it. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You publish every version
- You approve any change to the test event list
Access we would need
- Approve access to the container (no publish rights)
- Read access to the GA4 property
Questions
Why do I publish rather than you?
Publishing changes what your site sends. That decision and the account access stay with you.
What if I need a bigger change?
A larger rebuild is a project with its own scope and price.
Send an enquiry
Send us
- The site address and how many people edit the container today
- The list of events that must keep working, up to ten
- No logins and no container export.
Later, once you agree
- Approve access to the container (Google describes Approve as able to create versions, workspaces and make edits but not publish) and read access to the GA4 property, granted to the identity we agree with you before work starts
- The agreed test event list and a safe test route
- The person who requests changes and the person who publishes
Your site, accounts, containers and data stay yours. We read results with a read-only role on the GA4 property and work in the container with the Approve role, both granted to an identity we agree with you in writing before work starts. We prepare changes in a Tag Manager workspace and save them as named versions that you review and publish. We never ask for passwords, and you can remove access at any time.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “gtm-container-changes-tested-before-each-publish” as the subject.