KEYWORD INSERTION IN GOOGLE ADS EDITOR: ETAS VS RSAS

The first time I set up keyword insertion google ads editor side, I did it the wrong way: I trusted that what worked in expanded text ads would carry over unchanged into responsive search ads. The tag was identical, the syntax saved without complaint, and the ads went live, then half of them started serving the default text instead of the keyword. That experience is the whole reason for this article. When DKI moved from the old ETA world to RSAs, the code stayed the same but the container changed completely, and Editor is where that gap shows up most clearly, because it gives you the raw tag with no guardrails. Below is what I learned across that transition and exactly how I handle insertion in Editor today. If you want the broader picture first, our guide on how keyword insertion works in Google Ads covers the fundamentals before you get into the bulk workflow.

A quick framing before the detail: dynamic keyword insertion DKI is not a growth lever on its own, it is a relevance tool. When the inserted term matches what people typed, the ad reads as more relevant, which is the mechanism behind the higher click through rates advertisers report. But that lift only materializes when the structure underneath it is sound. Across the google ads campaigns I manage, the accounts where insertion helps have tight ad groups and clean keyword lists, the ones where it hurts bolted insertion onto a messy structure hoping to improve performance without fixing anything else.

From ETAs to RSAs: what changed in keyword insertion

Expanded text ads gave you fixed positions. You wrote Headline 1, Headline 2, Headline 3, and you knew where each one would land. When I dropped a google adwords dynamic keyword insertion tag into Headline 1, I knew precisely where the inserted keyword would appear and how it would read next to the rest of the copy. That predictability was the quiet superpower of DKI in ETAs, you were inserting into a known slot.

Responsive search ads removed that certainty. Now you supply up to fifteen headlines and four descriptions, and Google assembles combinations at serve time. An insertion tag dropped into one of those headlines can appear alongside any other headline, in positions you never tested. The keyword still inserts the same way, but the context around it is no longer something you control. The first thing I learned is that the tag survived the transition untouched, and the second is that everything around the tag stopped being predictable.

It helps to remember what insertion is actually doing under the hood, because that did not change either. The feature pulls one of your ad group keywords, not the raw search query, into the dynamic text of the ad. So even when broad match surfaces wildly different search queries, what gets inserted is still your keyword, capitalized the way you specified. That distinction is the whole reason insertion stays grammatical when it works: you are inserting a term you chose, not whatever the user typed. Understanding how dynamic keyword insertion work at this level is what stopped me from blaming the tag when the real problem was an ad group that was too broad to insert anything clean.

The default text went from nice-to-have to load-bearing

In ETAs, the default text rarely fired, because headlines were short and you could eyeball the fit. In RSAs, where combinations vary and the character budget is tighter in practice, the default text shows far more often. I now treat it as the real headline, not a fallback, if the default text reads badly, the ad reads badly a meaningful share of the time. That single shift accounts for most of the "why is my insertion showing the default" questions I get.

Setting up keyword insertion in Google Ads Editor

Here is the practical difference that matters. In the web interface, you type a brace, a dialog opens, you pick the default text and capitalization, and Google writes the syntax for you. In Editor there is no dialog inside the ad field , you type the raw tag yourself. According to Google's documentation on dynamic insertion tags in Google Ads Editor, the tool reads anything in the form {A.B.C:text} or {A.B.C} as a dynamic insertion or ValueTrack tag, which is exactly why a small typo in a brace can quietly turn into something Editor never warns you about.

The reason I do this work in Editor anyway is bulk. When I build a responsive search ad with the insertion tag already written, I can duplicate it across ad groups, paste it into dozens of ads, or push the same headline through the "Make multiple changes" tool in seconds. The web UI cannot match that speed at scale. The trade-off is that Editor will happily save a malformed tag, a missing default, or a default text that overflows the field, and you only find out when the ad serves. So my rule is simple: write the tag once, verify it once in the preview, and only then bulk-apply it. Knowing how the syntax and default text behave before you replicate is what keeps a bulk paste from becoming a bulk mistake.

One more Editor-specific habit worth naming: I keep the insertion tag out of the final landing page URL entirely. Customizers cannot be used in the Final URL field, and trying to force dynamic terms into the destination is a reliable way to break tracking. The insertion belongs in the ad headline and descriptions, where it does its job, and the URL stays static and clean. When I am implementing DKI across a new build, I write the headline containing the tag, leave the URL fields fixed, and only then move on to replicating the ad, that order has saved me from a lot of avoidable cleanup.

The syntax I type by hand

The manual tag is {keyword:default text}. The capitalization of the word "keyword" controls how the inserted term is capitalized, and the text after the colon is what shows when no eligible keyword fits. This is the same syntax I used in ETAs, and it is documented in Google's guide on setting up keyword insertion for your ad text.

Capitalization codes

Lowercase {keyword:...} inserts the term in lowercase. {Keyword:...} applies sentence case, only the first word is capitalized. {KeyWord:...} applies title case, capitalizing every word. In headlines I default to title case because it reads as deliberate ad copy rather than a raw query; in descriptions I match whatever case the surrounding sentence already uses. Getting this wrong is the single most visible insertion error, because a headline reading "buy dark chocolate" instead of "Buy Dark Chocolate" looks broken at a glance.

The default text rule that catches everyone

Editor calculates the character count of your ad using the default text, not the longest possible keyword. That means a tag can look like it fits in Editor and still serve the default when a longer keyword would push the headline past 30 characters or the description past 90. My habit is to keep the default text short and to keep the static copy around the tag short too, so there is genuine room for most keywords to insert. If the default fires constantly, the problem is almost never the tag, it is that nothing in the ad group is short enough to fit. This is the part of google adwords dynamic keyword insertion that no dialog protects you from, and it is exactly why working in Editor forces you to understand the mechanics instead of trusting the wizard.

What I actually use today

After the transition, I stopped using insertion everywhere and narrowed it to the cases where it still earns its place. I use it most in accounts with tightly themed ad groups where the keywords are genuinely short and consistent, a services account targeting a clear set of product or location terms, where the inserted keyword almost always reads cleanly. There, keyword insertion google ads editor workflows let me build relevant ads across many ad groups fast, and the default text rarely needs to fire.

I leave it out where the keyword list is broad or messy, because RSA assembly plus an unpredictable inserted term produces copy I cannot stand behind. I also never use it on competitor or trademark terms, those simply will not insert, and relying on them just serves the default. The honest summary of everything the ETA-to-RSA move taught me is this: the tag did not change, but the discipline around it did. In ETAs you could be sloppy and get away with it because you controlled the slot. In RSAs, and especially when you write the tag by hand in Editor, you have to earn the relevance with tight ad groups, short defaults, and a preview check before you replicate. That is the entire difference between insertion that lifts CTR and insertion that quietly serves your fallback to half your traffic.

Where does this fit in a broader ads strategy? I treat insertion as one relevance signal among several, not the centerpiece. The keywords in your ad copy matter, but so does the match between the ad and the page behind it: an inserted term that promises something the landing page does not deliver wins the click and loses the conversion. So when I evaluate whether insertion is earning its place, I do not stop at click through rates, I look at whether it moves conversion rates and supports higher quality scores, because relevance that Google rewards shows up in Quality Score over time, not just in a short-term CTR bump. If those downstream numbers do not move, the insertion is decorative, and I pull it.