Get access to a client's Google Tag Manager

Confirm the Tag Manager account and its containers, with production and test containers identified clearly. Ask the client to identify the account they actually use for the work in scope, rather than choosing from a familiar-looking name. Also agree whether the immediate objective is assessment, configuration or ongoing delivery. These details determine which permission is reasonable and what your team will check afterward. If the client is unsure which asset belongs to the project, resolve that ownership or account-selection question before they approve access to an unrelated account.

The request needs an Administrator of the client Tag Manager account. Send the instructions to that person or ask the client to involve them. A staff member who can read a dashboard may still lack permission to invite an agency. Repeating the same request with the same insufficient role will not fix that distinction. The authorized person should review the requested asset, recipient and permission before proceeding, and retain their own independent access after the agency is added.

Read permits inspection, Edit supports building changes, Approve supports approval, and Publish supports release. Account access is User rather than Administrator. Start by naming the actions the agency must carry out, then match the role to those actions. If the team only needs to inspect Google Tag Manager, explain why a viewing role may be sufficient. If a later task requires more authority, make that a deliberate scope decision with the client. Avoid requesting the broadest available role simply to prevent a possible future question; the current engagement should explain the permission being requested.

Agency Pilot adds the agency as a User on the selected account with the chosen permission on its containers. The permission is not an instruction to publish a tracking change. Read the status in the context of that workflow. An invitation, a client confirmation and usable Google Tag Manager access are related milestones, but they do not always happen at the same moment. Assign responsibility for the next step before marking delivery as ready. This prevents an agency teammate from arriving at a scheduled task and discovering that a required acceptance or platform action is still outstanding.

Use the agency Google login that will inspect or work on tracking configuration. Verify it before creating or sending the onboarding request, especially when the agency works through more than one account. Ask the actual recipient to confirm the identity they will sign in with. A forwarded email or a similar display name is not reliable proof that the correct account has been added. For a staffing change, arrange the replacement person’s appropriate access and remove obsolete assignments through the relevant platform process.

After the platform action, compare the account and container IDs with the containers actually installed on the client website, and confirm which container serves production. Record who performed that check and whether any required work remains blocked. Prefer a harmless viewing check over an unnecessary live edit. If a teammate cannot reach the asset, compare the actual recipient and role with the original request before asking the client to start again. Completion should mean the right person can reach the intended asset with the agreed capability, rather than only that a message or notification was received.

The connection arranges access rather than importing a tag inventory or changing tags. Measurement becomes a separate implementation task carried out by the people with the appropriate container permissions. Keep the client’s reporting expectation explicit in the service brief. If a metric is needed for a report, identify its source, date range and definition before promising that it will appear. A successful access step establishes only the capabilities described for this particular integration. It should not be used as evidence that another platform, a separate dataset or an unrelated source of business results has also been connected.

If a container is missing, first check the selected account and the client administrator. If publishing is unavailable, compare the granted role with the release responsibility instead of treating it as a broken connection. Start with account identity and authority because those determine what the client can share. Write down the exact stage where the flow stopped rather than repeatedly recreating the same request. If Google Tag Manager shows an account-specific restriction, the appropriate platform administrator may need to resolve it first. Avoid broadening permissions or switching to another asset just to make a completion indicator appear; verify the intended account instead.

No. The documented permission model separates editing from publishing. An agency can prepare changes with Edit while a client developer retains responsibility for release. Agree who will perform the publication step before promising a deployment date. If publication is required, review the appropriate permission with the client instead of assuming that a successful account connection grants that capability.

The connection described here adds the agency user; it does not import or modify tags, triggers or versions. Once authorized, the agency can inspect the configuration directly within the permissions it received. Keep those two activities separate in the scope: arranging access is onboarding, while auditing or changing measurement is delivery work that needs its own objective and validation.

The selected account can contain several containers, and the flow applies the chosen container permission across that account. Confirm the account scope with the client before requesting access. Afterward, identify which container actually serves the production website and which belongs to another environment or project. That prevents a technically successful grant from directing work toward an unrelated or unused configuration.

The product supports using a Custom HTML tag for the tracking script. Treat installation as a deliberate measurement change: use the correct client script, confirm the intended firing scope, check the existing site for duplicate installation and validate the result before relying on captured data. Publication still requires the appropriate container permission and the client’s agreed approval for that release.

No. User access and published website tags are separate. During handover, decide which delivered tags should remain, who maintains them and whether any connection needs changing. Remove obsolete user access independently. Do not assume that disconnecting an onboarding tool cleans up a live website implementation; review the actual container and client requirements before changing tracking behavior.

Remove the user in Tag Manager User Management and end the Agency Pilot connection. Decide separately which tags should remain after handover; removing a user does not remove published website tags. Agree a handover point before removing access that is still needed to finish approved work. Confirm the business retains the people and permissions it needs after the agency leaves. Keep permission removal separate from decisions about delivered work or historical reporting data; those are different questions. Record which Google Tag Manager assignments were removed and which, if any, remain for an explicitly agreed support period, with a clear owner for the final review.

Inspect the intended container and existing tags before preparing new tracking. Identify the expected event, trigger and destination, then agree who reviews and publishes the change. If installing the Agency Pilot script, use the correct client script and check for an existing installation before adding another copy. Verify measurement after an authorized publication. The next step should produce a controlled tracking change with understandable evidence, rather than a test edit made merely to demonstrate that the account connection works.