After more than ten years of Google Tag Manager, Google finally built a tool that lets you click an element on a page and turn it into a tracked event. No writing CSS selectors first. No data layer to set up before you start. You point, you click, you get a tag.
Google calls it Visual tagging. You launch it from inside Google Tag Manager, and it opens the Tag Assistant extension to let you click elements on your site.
The best thing about this tool is not how it works. It is that Google built it at all.
For years, the answer to "why is tagging so hard" was basically "because it is." Marketers were told the mess of selectors, variables and triggers was just the cost of doing measurement right. Now Google has shipped a point-and-click helper. You do not put engineering years into a problem you think is imaginary. Visual tagging is a real need, and the old manual way was a barrier worth removing.
We have believed that from day one. It is the whole reason TagCompanion exists. So when the biggest player in the space builds the same idea, we do not feel threatened. We feel right.
Now let me tell you where they got it wrong.
They built it backward
The tool starts at the wrong end. The first thing it asks for is a Google Ads conversion. You create the conversion, copy the ID, and then the tool helps you build the tags to feed it.
That is not how the job works.
A marketer answers to the business, not to the platform.
You start with the thing that happened on the site. A purchase. A form. A demo button. That event belongs to the company, and your job is to make sure you can track it. Then you send it wherever you want: GA4, Google Ads, Meta, LinkedIn, your CRM. The event comes first. The ad platform is just one place you send it.
Design your tracking around a vendor's conversion instead, and you pay for it every time you grow. Open a new channel and you are not adding a destination, you are rebuilding the measurement from scratch. Build it around business events you own, and a new channel is just one more place to send the same event.
Google flipped that. It starts from the ad platform and works back to the website. That is backward because it starts from the destination instead of the business event.
Business events outlive tools. Google Ads is a destination. A purchase is not. Build your measurement around the thing that lasts.
They put it in the wrong place
This is the part that bugs me the most, and it has nothing to do with our product.
GTM was sold as neutral. It sits above all your tools so you are not tied to any single one. That is the whole reason teams trust it.
So why is a Google Ads helper buried inside GTM instead of inside Google Ads?
Pick one. Either GTM is neutral, and a tool for one ad platform does not belong in it. Or GTM is slowly turning into a front door for Google's own products, and the "neutral" label was never the full story. You cannot sell neutral and ship the opposite in the same box.
They barely started
Look at what the tool actually covers. Right now it does one thing: purchase conversions for Google Ads. One destination. One event type. That is the whole beta.
Now look at how it captures data. You place a test order, land on the order confirmation page, and the tool scans that finished page for the values it needs: the order ID, the amount, the currency. It reads them off the page exactly as it sits in that one moment.
That is the entire trick, and it does not even handle clicks. What looks like clicking is just you pointing at a value to scrape off a page that has already loaded. There is no interaction tracking here at all.
And here is the deeper problem. A selector built by pointing at a rendered page is tied to how that page looked at that exact moment. Some of those selectors hold up fine. Plenty do not. Sort a list, load a row late, drop in a promo banner or a notification that was not on screen when you set it up, and the selector can end up pointing at the wrong thing, or at nothing. The method is coupled to the DOM by design, which makes it more fragile than tracking that reads from a data layer the page feeds on purpose. You are building a rule against a snapshot of a page that does not hold still.
So calling this the "easy part" is generous. It is one destination, one event, one page, read once, on a page they are treating as static when it never is. The people who cover this tool for a living are saying the same thing. Simo Ahava, reviewing the builder, pointed out that it only handles Google Ads purchase conversions for now, and that pulling business-critical data off a rendered page runs against everything he believes about tagging a site. Julius Fedorovicius, walking through the tool himself, ends by warning that CSS selectors break and that a solid setup still means going back to the data layer.
But they said they will roll out the rest
True. Google has said more event types and use cases are coming through the end of the year. So let me hand them the full rollout and ask one simple question: does it fix the problem?
It does not, for two reasons.
One, more coverage is not the same as being neutral. Rolling this out to more use cases still keeps it aimed at Google's own destinations. A tag manager was supposed to sit above every platform, not funnel you toward one company's products. A bigger Google-only tool is still a Google-only tool.
Two, and this is the one that matters: a rollout adds reach, not a better foundation. The engine underneath still reads values off a page frozen at a single moment. Adding more event types does not change that. It just takes the same frozen-in-time approach and points it at more of your tracking. You do not fix a cracked foundation by adding rooms on top. You spread the cracks.
So the end-of-year promise is about how much they cover. The DOM problem is about how the thing works underneath. Those are two different problems, and shipping more of the first one never touches the second.
The hard part is the one they skipped
The hard part is not a detail. It is the whole job. Reading the right data from the right element, and keeping it working after the page changes, is the difference between a demo and something you can run real money through.
This is where we did the work. TagCompanion builds the full ecommerce data layer for you, for both click and display events, not a single value scraped off whatever page happens to be loaded. That is the exact part Google left out, and it is the part that decides whether your tracking survives a real, moving site.
This is that principle made concrete. A purchase is a purchase whether you send it to Google Ads today or to something that does not exist yet next year. Build around one ad platform, and your setup lives and dies with that platform. Build around the event, and it keeps working no matter where you send it. That is why TagCompanion gives you a clean, portable container that you own. If a subscription ever lapses, your tracking keeps running.
We are not making tags easier
Here is the difference that matters most, and it is the easiest one to miss.
Google's builder makes one thing easier: creating a Google Ads tag. That is a friction fix. The tag, the trigger and the selector are all still there. They are just quicker to set up.
TagCompanion is not trying to make tags easier. It is trying to remove the need to think in tags at all. You say what happened on the site. The tags, triggers and selectors get built underneath, in a place you never have to look.
Those are not two versions of the same improvement. They are different layers. Google reduced the friction on the old model. We are taking away a whole layer of it. One makes the plumbing faster. The other means you stop thinking about plumbing.
Who this is really for
Here is the part Google keeps missing. Point-and-click tagging is not a toy for beginners or a shortcut for developers. It is for marketers.
A marketer's job is strategy and campaign optimization. It is not spending an afternoon fighting CSS selectors to confirm that a button click fired. Every hour you lose to plumbing is an hour you are not spending on the work that grows the business. The right tool should hand that time back to you, not hand you a slightly faster way to do the plumbing.
That is the bet we made when we built TagCompanion. Google just proved the need is real.
The takeaway
The easy thing to say is "Google took over ten years and still shipped something buggy." That feels good and changes nothing.
Here is the version worth keeping. After more than a decade of the manual way, Google put real engineering into a visual tagging tool. That alone tells you visual tagging matters. Then it did it backward, put it in the wrong place, and left out the hard part that counts.
That is not a reason to gloat. It is a map of the work still left to do. The need is proven. The best part is still wide open. And that is exactly the part we built.
