Google Tag Manager Audit: Inspect the Container and Clean Up Safely

A useful Google Tag Manager audit starts with the published container, follows important tags through their triggers and variables, and tests what they actually do on the website. It should tell you which components work, which need repair, which are genuinely redundant and which still need an explanation before anyone changes them.

This guide covers auditing the Tag Manager container itself. If one GA4 event is being counted twice, see how to find and remove duplicate GA4 events, and for measuring completed enquiries from start to finish, see how to set up and test GA4 lead form tracking.

Begin with one important journey, such as an accepted quote request. Identify the installed container and published version, open the tag responsible for that outcome, check its destination, follow its trigger and variables, and inspect the journey in Preview. Once you can explain that chain, expand the same inspection across the agreed container scope.

The aim is a configuration the next person can understand and maintain. A smaller tag count is not automatically a better result. Removing an unfamiliar tag without checking its purpose can be more damaging than leaving a clearly documented question open.

Start with one tag that deserves your attention

Imagine inheriting a supplier’s website with three tags named “Quote conversion,” “Quote conversion new” and “Vendor script.” The supplier has English and French quote forms. Marketing wants to count accepted enquiries once and distinguish their service categories.

For the first tag, the intended chain is simple:

1. The application accepts a quote request.
2. It pushes quote_accepted with the approved service_code.
3. A Custom Event trigger matches quote_accepted.
4. A data-layer variable supplies service_code to the event tag.
5. The tag sends the agreed event to the intended destination, subject to the approved consent behaviour.

Now inspect the hypothetical configuration. The trigger is named “Quote accepted,” but its actual event-name expression is a wildcard. Its label sounds precise while its matching rule is broad. The tag’s service parameter also points to a lookup that covers the English form value but has no reviewed French equivalent.

Those are two different findings. The trigger deserves a matching-rule correction against the approved event requirement. The shared lookup needs a mapping review across all its consumers. Renaming the tag would solve neither problem.

This is an original fictional audit example. No connected GTM container or Google account was inspected for it. The walkthrough tells you where to inspect and what evidence should appear; its illustrative results are not fabricated Preview screenshots or a claim that a real container passed.

A compact record of the example is enough to keep the work focused:

The rest of the audit should produce decisions with this level of clarity. Detailed exports and registers support those decisions; they should not become the main thing the business receives.

Establish which configuration is live

Open the intended GTM account and container. Record the container ID and confirm that it belongs to the website you are auditing. Then inspect Versions and the publication history. Separate the version published to the relevant environment from any unfinished workspace changes.

This distinction prevents a surprisingly consequential mistake: reviewing a draft as though it describes current website behaviour. A tag paused in a workspace may still be active in the published container. A repaired trigger may be waiting for release. Conversely, a colleague may have published a new version while your workspace still reflects an earlier baseline.

Google’s versions and publication guidance explains that a version is a configuration snapshot and that creating one differs from publishing it. Use the history to establish what was active and when, rather than relying on a workspace called “Final” or “Production.”

Record the website release as well, if the team has one. A form provider, theme or application deployment can change the signal a tag expects without any GTM edit. The container’s history cannot show that external change.

Ask about environments at this point. A GTM workspace is a place to develop configuration changes. A website staging environment is a different running website. A custom GTM environment controls which container version is loaded through its relevant installation or preview route. None of those labels guarantees that the destination is a test account.

For a practical baseline, write one sentence: “This audit covers the published web container on the English and French public website, including quote forms; the independently managed booking portal and server container are excluded.” Replace that scope with the actual site boundaries. Any excluded dependency that affects a core journey should remain visible in the findings.

Preserve a usable baseline

An authorized owner can export the relevant container version or workspace from Admin, Export Container. Keep the file and identify exactly what was exported. Google’s export documentation explains both full and partial exports.

Partial exports need special care. If dependencies are omitted and the export continues, references to missing tags and triggers can be removed while variable references remain. A file with an absent trigger reference may therefore describe the export process rather than the original configuration.

Use a complete relevant baseline before making conclusions about missing dependencies. Store it as configuration evidence with restricted access where appropriate. An export can contain destination details and implementation information; it is not a public appendix or a complete backup of the website, consent platform and every vendor account.

Confirm how the container reaches the website

A correct container in GTM does nothing for a page that never loads it. Conversely, a site can load another container or tag through a plugin or theme even when the container you opened looks tidy.

Inspect representative pages from each implementation type: the main landing-page template, the contact or quote form, the French version, and any embedded or external flow within scope. Confirm the installed container ID and installation route. Ask the developer whether it comes from theme code, a CMS integration, a site-builder setting or another supported mechanism.

Compare what is installed with what the team intended. An old container retained after an agency change can coexist with the new one. That is a finding to investigate, not automatic proof of duplicate events. Each container may serve a distinct purpose or audience.

Also identify Google tags installed outside GTM. Google’s Analytics setup guidance for Tag Manager describes the Google tag within GTM. If a plugin already provides the same destination’s base tag, understand that arrangement before adding another copy.

Do not treat the appearance of a familiar identifier as the whole installation check. Verify that the intended pages and journey steps load the correct configuration under the approved consent arrangement. An embedded provider can create a boundary that the main site’s container does not cross.

For a bilingual site, compare the actual forms. One may use a different plugin, page template or field identifier. An English test does not establish French coverage simply because both pages share the same header and footer.

Your output here should be a small installation map: website area, loading mechanism, container or Google tag, relevant owner and any uncertainty. That is enough to expose an unexpected deployment path without turning the audit into a catalogue of every script on the internet.

Read a tag from purpose to destination

Choose the tags that support the most important decisions first. Accepted enquiries, purchases and critical advertising outcomes usually deserve attention before a low-use scroll event. Importance comes from the business use and exposure, not from a universal tag-ranking score.

Open a tag and ask its business owner what the resulting measurement means. “Quote conversion” may mean a button click, attempted submission, accepted request or qualified sales opportunity. If the meaning is unclear, agree the intended outcome before describing the tag as correct or broken.

Inspect the tag type and destination. Check the actual Measurement ID, advertising conversion identifier, vendor account or endpoint against the approved destination. A working tag can still send to the wrong account. Keep sensitive details in controlled evidence and use readable aliases in the audit summary.

Next inspect the values it sends. Which parameters are fixed? Which come from variables? Which are inherited from a shared settings variable? Do any values originate in free text, form answers, page titles or URLs that might contain personal information?

For each important tag, you should be able to explain its purpose in a sentence: “After the receiving application accepts a quote request, this tag sends the approved lead event and service category to the business’s web stream.” That sentence gives the technical inspection something to test.

Avoid confusing an event tag with the complete customer outcome. GTM can react to a signal, but the application decides whether a request was actually accepted. The lead-form tracking guide covers that boundary in detail. A container audit checks whether the configured tag follows the agreed signal correctly.

Also record who can explain the tag when the current implementer leaves. A campaign owner may know why the measurement exists; a developer may know how it works. Those can be different people, and both forms of knowledge matter during cleanup.

Follow the trigger, including its exceptions

Read the trigger configuration rather than trusting its name. Confirm the trigger type, event-name matching, page conditions, exclusions and any dependent variables. A tag called “Accepted enquiry” can still fire on all button clicks if its configuration says so.

Check the meaning of multiple triggers. GTM firing triggers act as alternatives: a tag can fire when one is satisfied. An added success trigger beside an old click trigger does not require both conditions. Google’s trigger and exception guidance explains this behaviour and the separate effect of sequencing.

For the fictional quote tag, the correct question is whether the Custom Event trigger matches only the intended quote_accepted signal under the approved conditions. A regular expression of .* is much broader. It can react to unrelated events, including events created by the tagging system itself.

There is a current reason to inspect this carefully. Google’s 8 October 2026 release note says configuration commands now surface as visible gtag.config events and warns that wildcard Custom Event triggers can fire as a result. This does not establish the cause of any particular site’s issue; it makes broad matching a concrete audit check.

Google’s Custom Event trigger documentation also cautions against unrestricted wildcard matching. For one known application event, exact matching is easier to reason about. A regular expression can be appropriate for a reviewed family of events, but its boundaries need examples that should match and examples that should not.

Inspect blocking triggers too. A tag that stays quiet may be correctly excluded on an internal tool or a restricted page. Removing an exception to make the tag fire can violate the intended scope while appearing to solve the technical symptom.

Finally, review advanced firing settings and sequencing. Once-per-page behaviour can suppress a valid later interaction in a single-page application. A setup or cleanup tag can execute through a sequence rather than its ordinary triggers. Record the actual path before changing it.

Trace the variables that influence the result

Variables can decide whether a trigger matches and supply the information a tag sends. That makes them part of the audit’s decision path, not a housekeeping list at the end. Google’s variable overview describes these two uses.

Start with the variables used by your first important tag and trigger. Follow each reference back to its source. Is it a built-in page value, a data-layer field, a lookup table, a constant or custom code? What happens when its input is missing, unexpected or differently capitalized?

In the fictional supplier’s setup, the application supplies a service value and the shared lookup converts it to an approved service_code. The English form supplies equipment_service. The French form might supply the same stable code, a translated label or something else. Inspect the actual agreed input vocabulary rather than assuming translation is handled automatically.

A default lookup value can hide an error. If every unmatched value becomes general, a report may look complete while losing the distinctions the business wanted. Decide whether an unmatched value should be reported as a controlled unknown category, withheld for review or handled another documented way. That choice should serve the reporting requirement.

Check every consumer before changing a shared lookup. The same variable may supply a GA4 event, an advertising tag and a vendor integration. Fixing one route can change all three. A small field edit can therefore need several tests even when the code change itself is brief.

During Preview, inspect the variable at the specific event where the tag evaluates. A value that appears later in the session may have been absent when the tag fired. Google’s data-layer documentation explains message processing and the value of supplying needed fields with the relevant event message.

For example, pushing quote_accepted first and service_code in a separate later message can create a timing problem. The better application contract supplies the event and its approved values together. The audit should identify that interface problem and hand it to the developer rather than patching a plausible value into GTM.

Use GTM’s variable picker when configuring a tag value. Typing the display label “DLV service_code” as ordinary text is different from selecting the variable reference. A tag can fire successfully while sending the literal label instead of its resolved value.

Inspect custom code and templates with the right owner

Custom HTML and custom JavaScript deserve an explanation of their purpose, inputs and destinations. An auditor does not need to rewrite every snippet, but should identify code that cannot be safely understood by the people responsible for it.

Look for external scripts, broad page access, form-field reads and hard-coded identifiers. Check whether the code relies on an old element selector or a vendor endpoint that has changed. If a library is loaded by several tags, establish whether those copies are needed and how their lifecycle is managed.

GTM offers native and custom templates. Google describes custom templates as a permission-focused, sandboxed way to define tags and variables. That makes the template’s permissions and implementation relevant audit material; a template label alone is not a guarantee that its behaviour matches your requirements.

Record the template source, version and maintained documentation. Review what it can read or send and which tags use it. If a proposed update changes permissions or behaviour, treat that as a substantive change rather than a cosmetic version bump.

Avoid assuming a gallery listing certifies every business or privacy use. The implementation still needs to be appropriate for the site, the data and the destination. Where the code is beyond the audit team’s expertise, assign a qualified technical review and state the unreviewed boundary.

For Google tags, prefer the documented native setup instead of wrapping equivalent gtag calls in Custom HTML. Google’s data-layer guidance specifically directs implementers toward native templates for supported products. This simplifies inspection and reduces the number of hidden installation paths the next owner has to reconstruct.

Check consent at the moment tags evaluate

A visible banner cannot establish which consent state a tag received. The audit should connect the organization’s approved collection behaviour to the state available when each relevant tag evaluates.

Open the tag’s Advanced Settings and Consent Settings. Inspect built-in consent checks separately from additional consent checks. Google’s consent support documentation explains the distinction and the Consent Overview grouping.

“Not set” means additional checks have not been configured. “No additional consent required” is an explicit configuration choice. Neither label establishes that the organization has met its legal obligations. Determine what the particular tag already does and what the approved policy requires before changing the setting.

Consent-setting components have a dedicated Consent Initialization trigger so their state can be established before other triggers. That trigger is for managing consent; it should not become a general shortcut for making unrelated marketing tags run earlier.

Build a small set of scenarios around the actual banner and policy: a fresh visit before a choice, declined consent, granted consent, a changed choice and a returning visit with a saved choice. Include meaningful regional or language variants where the implementation differs.

Do not use zero network requests as a universal expectation. Google’s consent-mode overview distinguishes basic and advanced modes, including cookieless activity in advanced operation. The required observation depends on the approved implementation and the destination.

Equally, do not remove blocking merely because a reporting feature would gain more data. The audit’s job is to show whether actual behaviour matches the organization’s approved requirement. If that requirement is missing or unclear, involve the responsible privacy reviewer before changing collection.

Inspect third-party tags individually. A Google tag’s built-in behaviour does not establish what an unrelated vendor script does. Record the relevant vendor documentation and verify the scope of any consent integration rather than applying one unexplained setting to every tag.

Use Preview to investigate one fault

After configuration review, test a bounded journey in an approved environment. In the GTM workspace, choose Preview, enter the test page URL and connect through Tag Assistant. Google explains the workflow in Preview and debug containers.

Preview can run the draft configuration and send data. Before starting, confirm the website, intended destinations, allowed synthetic inputs and operational effects. A workspace named Test does not isolate a real enquiry form from email notifications or a production analytics destination.

For the fictional quote journey, inspect the event timeline in this order: initial page load, invalid submission, accepted submission and confirmation revisit. Select each event and inspect the quote tag, its trigger conditions and the service-code value available at that point.

The illustrative failure trace would look like this:

• Page load produces a system event.
• The broad Custom Event trigger matches it.
• The quote tag becomes eligible before any request has been accepted.
• Its service variable is missing or falls back to a generic value.
• A later real acceptance can trigger another dispatch.

That trace explains why the configuration deserves correction. It is an expected diagnostic pattern for the fictional example, not an observed GTM session. A real audit should capture the actual event names, matching conditions and resolved values instead of copying this pattern into a findings report.

After changing the trigger in the approved test workspace, the expected result is no quote-completion dispatch on unrelated system events, one on a qualifying acceptance and none on a failed submission or confirmation revisit without a new acceptance. A genuinely new accepted request should still produce its own event.

If the tag does not fire at acceptance, inspect the earliest failed condition. Did the website emit the signal? Was the expected variable present? Did the trigger match? Did an exception or consent setting deliberately block it? Did tag execution fail? Each answer points to a different repair.

A fired tag is evidence about execution, not proof that the destination processed the event correctly. Verify destination receipt separately with the relevant tool and owner. For GA4 reporting assurance across the property, use the GA4 data-quality audit guide.

Separate duplicate candidates from proven duplicates

Similar tag names are a reason to compare configurations. They are not enough to justify deletion. Two tags can intentionally send different information, serve separate destinations or run under different consent conditions.

Compare the suspected pair’s business meaning, event name, destination, trigger boundary and actual execution. Then reproduce one defined action. For an accepted-enquiry measure, confirm whether one accepted request produces two representations in the same destination.

Also inspect installation routes outside the container. A CMS plugin or vendor integration may send the same event even when GTM contains only one tag. The audit should note that external dependency and involve its owner. Cleaning the container alone cannot prove the website has only one sender.

In the fictional supplier’s inventory, “Quote conversion new” and a legacy confirmation-page tag share the same destination. They are candidates until the execution trace establishes that both represent the same accepted request. If the legacy tag also covers another form, retiring it wholesale could remove valid measurement.

Choose the maintained path that satisfies the approved definition and test coverage. The oldest component is not necessarily wrong, and the newest is not necessarily correct. A narrow trigger change may be safer than removing a tag that still has another valid purpose.

The duplicate-events guide goes deeper into repeated callbacks, legitimate repeats, purchase identifiers and browser/server overlap. Keep those incident-specific details in that investigation rather than making every container audit repeat the whole diagnostic.

Decide what to keep, repair or investigate

By this point, your inventory should support decisions. For each reviewed component, write its purpose, current finding and next action. Use everyday labels that the responsible team can act on.

Keep a component when its purpose is current, its dependencies are understood and its observed behaviour meets the tested requirement. Repair a component when you have evidence of a specific mismatch. Investigate a component when its purpose, owner or behaviour remains uncertain. Retirement needs its own evidence that the function is unnecessary and that dependencies have been addressed.

Avoid scoring every item with a manufactured number. A privacy-related unknown on every page and an untidy tag name are different kinds of concern. Explain the exposure: which journeys, destinations or decisions could be affected, and how strong the evidence is.

For the supplier, a broad completion trigger is a high-priority measurement defect candidate because it could treat unrelated events as quote activity. The missing French service mapping affects interpretation of a specific journey. The unowned vendor tag may have wider exposure, but its uncertainty calls for investigation before an irreversible cleanup decision.

An audit can finish with open questions if those questions have accountable owners and clear next evidence. “Unknown vendor tag, delete” is weak. “Vendor purpose unresolved; marketing operations will confirm the service relationship and dependencies before retirement” is a useful handover.

Keep housekeeping separate where practical. Renaming tags, reorganizing folders, updating a shared lookup and retiring a vendor in one release makes the meaningful change harder to review and recover. Group changes that depend on each other; avoid bundling unrelated work simply because the container is open.

Review access without confusing it with ownership

Container access tells you what a person can do in GTM. Business ownership tells you whether a measurement is still needed. An agency publisher may be technically able to remove a tag while the organization’s campaign team knows it supports a current program.

Review account-level and container-level access with the authorized administrator. Google’s permissions documentation distinguishes Read, Edit, Approve and Publish. Read supports inspection; Edit allows configuration changes; Approve adds version creation; Publish permits release.

Confirm that the organization retains control and has more than one active administrator, as Google recommends. Use identifiable individual accounts rather than shared credentials. Check direct and inherited permissions, especially when a person changes role or an agency relationship ends.

Do not turn an audit finding into an unrequested access change. Name the specific issue and have the authorized owner decide the correction. Removing the only knowledgeable implementer before another person understands the container can create a different operational risk.

The handover should identify a business contact, technical maintainer and authorized release owner. In a small team one person may hold several roles. What matters is that the responsibility is explicit and someone else can recover the context when needed.

Plan a change that can be reviewed

A repair proposal should explain what changes and why. “Fix tracking” leaves too much unstated. “Replace the quote trigger’s wildcard with exact quote_accepted matching, preserving the existing destination and reviewed service-code mapping” is specific enough to compare with the configuration.

Include the affected components and their dependencies. If a shared variable changes, name every consuming tag that needs regression testing. If a consent setting changes, include the approved behaviour and responsible review. If application code must change too, coordinate the two releases.

Use a focused workspace for the related work. Google’s workspace documentation describes keeping separate change sets and resolving conflicts when versions advance. Update an out-of-date workspace carefully, inspect the merged result and repeat any tests affected by conflict resolution.

A test of yesterday’s draft does not automatically cover today’s merged configuration. This is especially important when two teams edit the same shared trigger or variable. The eventual release should be the configuration that was actually reviewed and tested.

Check the complete pending change list before publication. A colleague’s unfinished remarketing tag should not ride into production alongside the quote repair. Review the diff for unexpected additions, removals, destination changes and consent changes.

GTM 360 includes a built-in approval workflow. Smaller teams can still record a review in their ordinary issue or change system. The important thing is a clear requirement, a bounded diff, evidence for the tested cases and an authorized publication decision.

Test normal behaviour and the cases that stay quiet

Write expected outcomes before running the test. A broad instruction such as “check form tracking” allows too much room to declare success after one convenient event appears.

For the supplier’s quote tag, include one accepted enquiry, invalid input, a receiving rejection, a confirmation reload, a second accepted enquiry and both language routes. Inspect the destination and values for each. The English path passing cannot compensate for an unresolved French mapping.

For a consent-sensitive tag, test the approved states as separate cases. A declined-consent case needs an expectation grounded in the actual mode and policy. If nobody can define that expectation, it is a decision dependency rather than a test ready to mark passed.

Test shared dependencies through their different consumers. If one lookup serves three tags, verify the relevant outputs rather than assuming one correct GA4 parameter proves the other destinations are correct. If a trigger is reused, inspect each tag it controls.

Include an unrelated event to challenge the matching rule. In the wildcard example, the repaired quote trigger should stay quiet on a system configuration event and an ordinary page interaction. That proves the boundary that motivated the change.

Record three possible results honestly: passed for the stated context, failed against the expectation, or not run because evidence is unavailable. Keep blocked tests visible with their blocker. A spreadsheet full of green cells is unhelpful if several rows merely describe what someone hopes will happen.

Publish to the intended environment and verify again

After review, the authorized publisher should confirm the selected environment, container version and included changes. Use a version name and description that explain the business purpose and important differences. An automatically suggested summary, if available, still needs human review against the actual change.

Google’s verification and publication instructions distinguish publishing from saving a version. A saved snapshot is useful evidence, but does not by itself mean visitors are using it.

For custom environments, check the relevant installation and publication target. Google’s environment documentation explains how versions relate to environments. A staging success is useful only within its tested context; production may use another snippet, website build or destination.

After publication, verify the intended version and repeat representative journeys in the approved production arrangement. Check the repaired fault and at least one important legitimate path that might have been affected. Then arrange the destination or processed-report checks that cannot be completed immediately.

Keep the observation period tied to the change. A low-volume form may need a controlled test rather than waiting for an unknown visitor to submit. A reporting check needs appropriate processing time. Do not substitute an arbitrary number of hours for the evidence the release actually requires.

Prepare recovery before you need it

Identify a previous container version that could be used for recovery and confirm that it still fits the current website. A recent form redesign may have removed the element IDs or application signals that the old version expects.

Publishing an earlier container changes future behaviour. It cannot remove information already sent, recreate events that never arrived or restore external application, consent-platform or vendor settings. The recovery plan should name those boundaries so a rollback is not mistaken for a complete reversal of the incident.

Define the symptoms that would stop the release or trigger recovery: missing valid enquiries, unexpected destinations, a broader consent mismatch or another concrete failure. Name the person who will decide and the tests that will verify the recovered state.

Sometimes a narrow forward correction is safer than an old version. If the earlier configuration contains the very defect the audit was meant to remove, returning to it may be a temporary containment choice rather than a full solution. Explain that trade-off and retain the incident timeline.

Hand over a result the business can use

Lead the final audit with the findings that affect decisions: what was inspected, what is confirmed, what is still uncertain, what should change and what tests remain. Include links to the relevant configuration and evidence within the authorized team, rather than attaching unfiltered exports to a broad distribution list. Accurate tags are what Google Ads management relies on to count calls and form enquiries as conversions.

The existing Google Tag Manager audit kit provides optional inventory, change-review and scenario-plan templates, with fictional examples and an offline checker. These are planning aids. Running the checker verifies the supplied files and local teaching logic; it does not inspect a real container, execute consent behaviour or approve a release.

Keep the short purpose-and-action sheet at the front. Use the larger register when a finding spans shared variables, multiple environments or several owners. Preserve unknowns and give each important one a next step. The business should not have to understand every column before knowing what needs attention.

Return to the relevant tests when the website, form provider, consent configuration or vendor integration changes. Periodic ownership review also helps prevent abandoned tags and inaccessible accounts. Choose a cadence that fits the team’s release activity rather than auditing by calendar alone.

A good audit ends with fewer unexplained decisions. The team knows why its important tags exist, what makes them run, which information they send and how a safe change is verified. If you need help tracing an inherited container, contact Canada Create with the website and the measurement you need to trust.

Frequently asked questions

What is Google Tag Manager used for on a business website?

Google Tag Manager is a container that loads and manages tags, such as analytics and advertising measurement, without editing site code for each change. Each tag runs on triggers and draws values from variables. An audit follows that chain from purpose to destination.

Is Google Tag Manager a tracker in itself?

Tag Manager is a delivery tool; the tags it fires are what send data to analytics or advertising destinations. That is why an audit checks each important tag's destination, trigger, variables and consent behaviour. A clear record of what each tag does is more useful than its name.

What is the difference between Google Tag Manager and Google Analytics?

Google Analytics collects and reports measurement data, while Google Tag Manager decides which tags load on the website and when. A GA4 tag in a GTM container is one common link between the two. Auditing the container checks what is sent; the analytics property shows what was received.

What belongs on a Google Tag Manager audit checklist?

Confirm the published container and version, preserve a baseline, and check how the container loads on the site. Then follow important tags through their triggers, variables, custom code and consent behaviour, and test them in Preview. Finish with clear decisions on what to keep, repair or investigate.

Which tools help with a Google Tag Manager audit?

GTM's own Preview mode and its Versions history do much of the work. Versions show which configuration was published and when, which matters because an unfinished workspace is not what the website runs. Record the website release as well, since a form or theme change can break a tag without any GTM edit.

How should user access be reviewed in a Google Tag Manager audit?

List who can edit and publish, and confirm each person still needs that access. Access and ownership are different questions, so record the business owner of the account and container separately. Remove access only through an agreed, reviewable change.

How do I find my Google Tag Manager ID during an audit?

Open the GTM account and container; the container ID starts with GTM- and appears in the interface. Record it and confirm it matches the snippet on the website you are auditing. This avoids reviewing the wrong container.

Is Google Tag Manager good or bad for a website?

It depends on how the container is configured and maintained. A clearly documented container is easier to trust than a tidy one with unexplained changes, and fewer tags is not automatically better. Removing an unfamiliar tag without checking its purpose can do more harm than leaving a documented question open.