Google Tag Manager Inside Google Ads: How the New Embedded Setup Changes Conversion Tracking

Google Ads is quietly embedding a Google Tag Manager setup interface directly inside its own UI. Advertisers can now create a container, drop in a conversion tag, and fire it on a button click, all without ever opening tagmanager.google.com. On the surface it looks like a minor UX convenience. In practice, it changes who can touch your tags, how versions get published, and where the source of truth for your conversion tracking actually lives.

I’ve been migrating clients onto this embedded flow for a while now, and the gap between “this is convenient” and “this is safe to deploy across an agency book of business” is wider than the launch coverage suggests. Below is the practitioner’s walkthrough nobody has written yet: what the embedded interface actually exposes, where it breaks, and how to govern it before a well-meaning paid search manager publishes a tag that overwrites your carefully built workspace.

What the embedded GTM interface inside Google Ads actually does

When you open Google Ads and navigate to Goals → Conversions → Summary → New conversion action, and then choose a website conversion, you’ll see an option to set it up via Google Tag Manager. If you have edit permissions on a GTM container associated with the Ads account, the next screen is essentially a stripped-down GTM editor running inside the Ads chrome.

Here’s what’s actually exposed inside that embedded view:

Tag creation for Google Ads Conversion Tracking tags and the Google Ads Remarketing tag
The Conversion Linker tag (auto-added if missing)
Basic triggers, page view, all pages, and click triggers based on a CSS selector or URL match
Container selection, you can pick which existing container the tag goes into
Workspace targeting, defaults to the Default Workspace; this is the part most people miss
Publish flow, a “Save and publish” button that creates a new container version

What it does not expose:

Custom HTML tags
Custom JavaScript variables
Data Layer variables (you can reference them, but not create them through this UI)
Server-side containers
Any non-Google tag templates (Meta, TikTok, LinkedIn, etc.)
Folders, tag sequencing, tag firing priority, or built-in variable configuration
Trigger groups, exception triggers, or regex-based triggers beyond a simple match
Preview mode in any meaningful debugging capacity (you get a “test” but not the full Tag Assistant flow)

Think of it as GTM Lite for Google Ads conversions specifically. It’s the same backend, the tags it creates appear in your normal GTM interface, but the surface area is intentionally narrow.

Connecting an existing container and configuring a conversion without leaving Ads

Here’s the actual flow I use when onboarding a small client who already has a GTM container running on their site.

Step 1: Confirm container access at the right level

The Ads user attempting the embedded setup needs Publish permission on the target GTM container, not just Edit. If they only have Edit, the embedded flow will let them build the tag but silently fail at publish, and you’ll get a support ticket two days later asking why conversions aren’t firing. The user also needs at least Standard access on the Google Ads account.

Step 2: Trigger the embedded flow

Inside Google Ads:

Goals → Conversions → New conversion action
Select Website
Enter the domain, Ads will scan it and try to detect existing tags
When prompted for setup method, choose Use Google Tag Manager
The embedded picker appears: select your existing container ID (e.g., GTM-XXXXXXX)

Step 3: Configure the conversion

You’ll define the conversion action (purchase, lead, etc.), category, value, and counting method inside Ads as normal. Then the embedded GTM panel asks how the tag should fire. For an e-commerce purchase, you typically want it on a /thank-you or /order-confirmation route. The trigger picker accepts:

Page URL contains
Page URL equals
Click element matches CSS selector

If you need to fire on a dataLayer event like purchase, you cannot configure that from the embedded UI. You’ll be sent to the full GTM interface, which is the first major gotcha.

Step 4: Inspect what got created

After publishing, open the full GTM UI and look at the new version. You’ll find:

{
  "tag": {
    "name": "Google Ads Conversion - Purchase",
    "type": "awct",
    "parameter": [
      { "key": "conversionId", "value": "AW-1234567890" },
      { "key": "conversionLabel", "value": "abcDEFghiJKL" },
      { "key": "enableConversionLinker", "value": "true" }
    ],
    "firingTriggerId": ["<auto-generated-trigger-id>"]
  },
  "trigger": {
    "name": "Page View - Order Confirmation",
    "type": "pageview",
    "filter": [
      {
        "type": "contains",
        "parameter": [
          { "key": "arg0", "value": "{{Page URL}}" },
          { "key": "arg1", "value": "/thank-you" }
        ]
      }
    ]
  }
}

Note the naming: Ads will auto-name the tag and trigger using a convention like Google Ads Conversion - <action name>. If you have a naming convention in your container (and you should, see our GTM service for how we structure these), the embedded flow will break it. Plan to rename after publish.

Workspace and version-control implications

This is the section that matters most to anyone running a serious tagging operation, and it’s the part the launch coverage skipped entirely.

The embedded GTM interface inside Ads publishes directly to the Default Workspace unless you explicitly pick another one, and the workspace picker is buried. What this means in practice:

If you’re mid-development in the Default Workspace, an Ads user editing a tag from inside Ads can publish your in-progress changes alongside their conversion tag.
The version note in GTM will say something like “Created from Google Ads” with no detail about which Ads user did it or what conversion action it relates to.
Workspace conflicts that would normally appear in the full GTM UI as a merge prompt are handled silently, the Ads UI doesn’t expose conflict resolution.

The way I deal with this on managed accounts: create a dedicated workspace called ads-embedded and instruct all Ads users to publish into it. Then I review and merge it into Default on my schedule. This adds a step but prevents the worst failure mode, an Ads manager publishing untested experiment code because their conversion tag happened to share a workspace with my staging tags.

Version rollback still works normally. If an Ads-published version breaks something, you can roll back from the full GTM UI. The embedded interface inside Ads does not surface version history at all, which is another reason to keep the full GTM admin role with a small group of trusted users.

When to use the embedded setup vs. when to stay in full GTM

Here’s a decision matrix I use with clients. This is based on actual implementations, not theory:

Scenario	Use embedded GTM in Ads	Use full GTM UI
Single Google Ads conversion, simple URL trigger	✅ Yes	Overkill
E-commerce purchase tracking with dataLayer	❌ No	✅ Required
Multi-destination tags (Ads + Meta + GA4 from one event)	❌ No	✅ Required
Server-side container	❌ Not supported	✅ Required
Enhanced Conversions with user-provided data	Partial, depends on UI version	✅ Recommended
Phone call conversion via website click	✅ Works	✅ Works
Conversion firing on a custom event (e.g., `form_submit_success`)	❌ No	✅ Required
Client who wants self-serve conversion edits	✅ With governance	Risk of breaking things
Agency-managed container with version discipline	Use cautiously	✅ Preferred

The honest rule of thumb: if your conversion can be triggered by a URL or a button click, and you have exactly one destination, the embedded setup is fine. Anything more complex, dataLayer events, multiple destinations, server-side, consent mode customisation, dynamic conversion values, and you need to be in the full GTM UI. Trying to force the embedded flow to handle those cases produces tags that look correct but fire on the wrong page state.

Permission and governance risks

The permission model is where this feature gets dangerous in agency environments. Let me lay out the actual relationship:

Google Ads access is granted per-account (Admin, Standard, Read-only, Email-only).
GTM container access is granted per-container (No access, Read, Edit, Approve, Publish).
Linking Ads to GTM for the embedded flow requires the linking user to have Admin on Ads and Publish on the container.
Once linked, any Standard-or-higher Ads user can invoke the embedded GTM editor for that container, they don’t need to be added to GTM separately. This is the part most people miss.

Read that again. The act of linking effectively delegates a slice of GTM publish authority to anyone with Standard access on the Ads account. That’s fine for a one-marketer SMB. It’s a real problem for an agency managing 40 client containers, where junior media buyers have Standard Ads access but shouldn’t be touching tags.

How to lock this down

I do three things on every container before enabling the link:

Restrict the link to a single workspace by setting up the ads-embedded workspace described earlier and using container access controls so the linked Ads role can only publish from that workspace if your governance setup supports it.
Audit the linked account quarterly. GTM’s container change log shows the publishing user. Anything with a googleads source identifier gets reviewed.
Document a “no Custom HTML from Ads” policy, irrelevant in practice since the embedded UI doesn’t support it, but you want this written down for when Google expands the surface area.

If your client setup involves multiple stakeholders, this is exactly the kind of thing we build governance frameworks around in our GA4 setup engagements, the same principles apply to GTM.

Migrating from legacy Google Ads tag or gtag.js

If you’re still running the legacy AW-XXXXX gtag snippet directly on your site, the embedded setup is actually a reasonable migration path. Here’s how I sequence it:

Step 1: Inventory existing conversions

Pull a list of every Ads conversion action and where it fires. A quick way to audit your live site:

# Check for gtag.js Google Ads conversions on the site
curl -s https://example.com/thank-you/ \
  | grep -oE "gtag\('event', 'conversion'[^)]*" \
  | sort -u

# Check for legacy conversion.js
curl -s https://example.com/thank-you/ \
  | grep -oE "google_conversion_id\s*=\s*[0-9]+"

You want a spreadsheet with columns: Conversion Action, Conversion ID, Conversion Label, Trigger Page/Event, Value Source.

Step 2: Stage parallel firing

Don’t cut over cold. Add the GTM-managed tag first while the legacy tag is still firing, and let both run for at least 7 days. Compare the conversion counts inside Ads, they should match within a few percent. If they don’t, the trigger conditions in GTM aren’t equivalent to the legacy snippet. Common culprits:

Legacy snippet fires on document ready; GTM tag fires on DOM Ready or Window Loaded, different timing on slow pages
Legacy snippet was hardcoded with a static conversion value; GTM tag is pulling from a dataLayer that doesn’t exist on that page
Consent Mode v2 is gating the GTM tag but the legacy snippet was ungated

Step 3: Remove the legacy snippet

Only after counts reconcile. Remove the hardcoded gtag from the site, deploy, and watch conversions for another week.

Shopify-specific note

If your store is on Shopify, the embedded GTM flow won’t help you for purchase tracking, the order status page has its own constraints and Shopify’s checkout extensibility model affects how tags fire. For those projects we typically build a Shopify-native integration alongside the GTM container; details in our Shopify development service.

Common mistakes and troubleshooting

A list of every avoidable problem I’ve seen with this feature:

1. Conversion fires twice. The most common issue. Usually because the legacy gtag is still on the site and the GTM-managed tag is also firing. Check the page source. Also check that you don’t have two GTM containers loaded, surprisingly common after a CMS migration.

2. Conversion Linker missing. The embedded UI is supposed to auto-add it, but if you have a Conversion Linker tag with custom configuration already in the container, the embedded flow may skip adding a second one and then your new tag fires without proper GCLID stitching. Always check that Conversion Linker is firing on All Pages.

3. Tag fires but Ads shows zero conversions. Almost always a Conversion ID / Label mismatch. The embedded UI populates these automatically, so this happens more often when someone manually edits the tag afterward in the full GTM UI and fat-fingers a character.

4. “Cannot link container” error. Means the user doesn’t have Publish on the container. Edit isn’t enough. Grant Publish or have someone who has it do the initial link.

5. Tag published to wrong workspace. Embedded flow defaulted to Default Workspace and merged in changes you weren’t ready to ship. Roll back from the GTM version history. Then set up a dedicated workspace for Ads-published changes.

6. Enhanced Conversions not capturing user data. The embedded UI exposes a simplified Enhanced Conversions toggle, but it doesn’t always wire up the user data variables correctly if your site uses non-standard form field names. Verify in Ads under “Diagnostics”, if it says “Enhanced conversions: not detected,” go into the full GTM UI and configure the user-provided data variable manually.

7. The embedded UI shows different containers than I expect. It only shows containers where the linking user has Publish permission. If you expect to see a container and don’t, check GTM user access.

8. Test events fire in preview but not in production. Often a consent mode issue. If your CMP blocks Ads tags by default and the user hasn’t consented, the tag waits indefinitely. Either configure Consent Mode properly in GTM or test from an incognito session with consent granted.

Where this fits in the broader tagging stack

The embedded GTM interface is a wedge. Google is gradually moving conversion configuration out of standalone GTM and into each product’s own UI, you see the same pattern in GA4’s “Tag Settings” area and in the way Floodlight is configured inside Campaign Manager. The destination state, several years out, is probably one where the full GTM UI is for engineers and the embedded flows handle 80% of marketer-driven tag changes.

For now, the practical advice is: use the embedded flow for simple Ads conversions, keep the full GTM UI as the source of truth, enforce workspace discipline, and audit publishes. If you’re running server-side tagging, integrating with Amazon SP-API for marketplace conversion data, or building AI-driven attribution workflows (our AI agents service handles a lot of this), the embedded UI isn’t relevant, you’ll be in the full GTM and likely in server-side container code anyway.

Key Takeaways

The embedded GTM interface inside Google Ads exposes a narrow surface: Google Ads conversion tags, remarketing tags, Conversion Linker, and simple URL/click triggers. Anything involving custom JavaScript, dataLayer events, server-side, or non-Google destinations still requires the full GTM UI.
Linking Ads to GTM effectively grants Publish-level tag access to anyone with Standard access on the Ads account. Treat this as a governance decision, not a UX convenience, restrict via a dedicated workspace and audit quarterly.
The embedded flow publishes to the Default Workspace by default, which can silently merge in-progress changes. Create an ads-embedded workspace and route all Ads-initiated publishes through it.
For migrating off legacy gtag or conversion.js, run both tags in parallel for 7+ days before removing the legacy snippet. Reconcile conversion counts before cutting over.
Common failure modes are double-firing conversions, missing Conversion Linker, ID/Label typos after manual edits, and Enhanced Conversions silently not capturing user data. All are catchable with a pre-launch checklist.
Treat the embedded interface as a tool for small, simple setups and self-serve marketer workflows. Keep the full GTM UI as your source of truth, and don’t let “convenient” become “ungoverned.”