MANUAL · B2B PAID SEARCH
Written for marketers rather than developers. Every click is numbered, and every step carries the reasoning behind it.
Then you wait, twice.
A few hours before your first test conversion appears in Google Ads reporting. Do not conclude anything is broken before this.
Two to four weeks before you have enough conversion volume to make decisions from. Do not change bidding strategy, judge keyword performance, or draw conclusions about campaign quality until the account has accumulated real data. Building the tracking is the fast part; earning the right to act on it is not.
These are estimates from a live build, not measured averages. Chapter 3 is the one that varies most, because it depends on somebody else's queue.
CHAPTER 0
What this manual covers, who it is for, and what you need in place before step one.
Get Google Ads to record a conversion every time someone completes a meaningful action on your website, so you can see which keywords and ads produced real leads, and so automated bidding has something worth optimizing toward.
Without it you can see clicks and cost, but not results. Every optimization decision becomes a guess, and Smart Bidding has nothing to learn from.
Google Ads does not watch your website. It sits and waits for a signal to arrive. Everything in this manual exists to build that signal, label it correctly, and deliver it to the right address.
Three consequences follow, and they explain most of the difficulty:
One symptom, many possible causes. That is why each chapter ends with a verification gate, and why Appendix A is organized by symptom rather than by cause.
Chapters 2 through 6 are the required path. Complete them and you have working conversion tracking.
Chapter 7 adds enhanced conversions, which improves how reliably Google matches your conversions but does not create conversions that would not otherwise exist. It is genuinely optional and it adds a website requirement, so it lives in its own chapter rather than being scattered through the others.
The only place the two paths touch before Chapter 7 is the request in step 3.1, which contains two extra points you include only if you intend to do Chapter 7. Decide now so you request the change once.
Confirm all four before starting, rather than discovering a gap in Chapter 4.
CHAPTER 1
Read this before touching anything. Every chapter that follows assumes you know these terms and how they connect. Skipping it is the main reason people find the steps confusing.
You will move between three environments, and knowing which one you are in at any moment removes most of the confusion.
GTM has four concepts of its own that are easy to mix up. Understanding them now makes Chapters 5 and 6 straightforward.
One per website. ID looks like GTM-XXXXXXX.
The container is a box of tracking code that sits on every page of your site. A developer installs it once, and from then on you can add, change, and remove tracking inside it without touching the website's code again.
My dream is for this part to be automated or for AI to be able to install it and QA it.
Everything you build in this manual lives inside your container: the triggers, the variables, the tags. When someone says "is GTM installed," they mean "is the container on the site."
Think of it as a plug socket your developer wires into the wall once. After that, you can plug things in and unplug them yourself without calling an electrician.
Your editing area inside the container.
When you add a tag or change a trigger, you are editing a draft. That draft is your workspace. Nothing you do there affects your live website.
This is why a change can look perfectly configured in GTM and do nothing at all on the site. It is still a draft.
A saved snapshot of the container.
When you finish editing, you submit your workspace, which creates a numbered version with a name and description. Versions are a history you can look back through, and roll back to if a change causes a problem.
Write a real description each time. Six months later, "Version 12" tells you nothing and "Added Google Ads conversion tag for contact form" tells you everything.
The act of making a version live.
Publishing takes a version and pushes it to your website. Until you publish, your visitors are running whatever was published last, no matter what your workspace contains.
Preview mode runs your draft. The live site runs the last published version. "It worked in Preview but not live" almost always means the container was never published.
These are the pieces you will build. Four of them live in GTM; one lives in Google Ads.
On your website — built in Chapter 3
A message board that sits on the page. Your website posts short messages to it, and GTM reads them. Neither side needs to know how the other works, which is the point.
Nothing appears there automatically. If your website never posts a message, GTM has nothing to react to. This is the piece most often missing.
In GTM, answers when — built in step 5.1
A condition GTM watches for. When the condition is met, anything attached to that trigger runs. A trigger does nothing by itself; it only decides the moment.
Types include: a page loads, a link is clicked, or, as here, a specific named message appears on the data layer.
In GTM, answers what — built in Chapter 7
A named container holding a value that GTM looks up at the moment a tag fires. You build one whenever a tag needs information that changes from visit to visit.
Variables can read from the data layer, from the page's own HTML, from the URL, or from a value you type in. The required path does not need one; enhanced conversions does.
In GTM, answers send it, and to whom — built in steps 5.2 and 5.3
The thing that actually sends data somewhere. A tag can send to Google Ads, GA4, LinkedIn, anywhere. The tag type determines the destination and which fields it expects.
Every tag needs at least one trigger, or it never runs.
In Google Ads — built in Chapter 4
The record on Google's side that receives the signal and counts it. It defines what kind of action this is, how many to count per click, and how long after a click you will still credit it.
Creating one produces a Conversion ID and a Conversion Label. Together they are the address the tag sends to. Without both, the signal goes nowhere.
The distinction people get wrong. A trigger is when. A variable is what. A tag is send it. A conversion action is receive it. Four separate objects across two products. Building three of the four gets you nothing at all.
Every box carries the step that builds it. When a later step is confusing, come back here to see where it sits in the chain.
Solid arrows are data moving. Dashed grey arrows are one thing reading another. Purple is the optional enhanced conversions path from Chapter 7. A break anywhere gives the same symptom: zero conversions, no error message.
CHAPTER 2 REQUIRED
Three decisions before any tool is opened: what action you are calling a conversion, whether the plumbing exists, and whether you have a consent obligation.
Where you work: Your website, Tag Manager, GA4Time: 20–30 minutes
A page view is not a conversion. Neither is a scroll, a session, or a click on your nav. Google will happily let you count any of them, and the moment you do, automated bidding starts optimizing toward people who browse rather than people who buy.
Start with one action rather than three. You can add more later, but the primary versus secondary decision in step 4.4 is what makes multiple actions safe, and you need to understand that first.
Step 2.1.4 exists because in B2B the conversion frequently finishes somewhere you do not control. Three versions of this, in increasing order of difficulty:
app.yourcompany.com or on a different domain entirely. That surface is owned by engineering, not marketing, and getting the GTM container installed on it is a different conversation from getting a change to your marketing site.There is a useful distinction inside that second case. If your app sits on a subdomain of the same domain as your marketing site, this is not technically cross-domain tracking, and the handoff is handled automatically provided the same measurement setup is installed on both. The barrier is access and cooperation, not configuration.
If the app sits on a genuinely different domain, you have a cross-domain tracking problem as well, which requires explicit configuration so the visitor is not counted as two separate people. Be aware that the standard cross-domain mechanism works by appending an identifier to links a visitor clicks. Signup flows that navigate by form submission or by a server-side redirect can drop that identifier, which means a working cross-domain setup on your marketing pages does not guarantee a working one through your signup flow.
Practical advice. If your primary action lives inside the product, do not start there. Pick a marketing-site action you fully control, get the whole chain working end to end, and open the engineering conversation about the app separately. Learning conversion tracking and negotiating access to the product codebase at the same time is how this stalls for months.
GTM-XXXXXXX.This confirms the container from section 1.2 is actually on the site. Everything in Chapters 5, 6, and 7 lives inside it, so a container that is not installed makes the rest of the manual unusable.
Preview mode is also the tool you will use to verify every later step, so getting familiar with connecting it now is worth the two minutes.
G-XXXXXXXXXX. Write it down.GA4 and Google Ads are separate systems that happen to share a tag manager. GA4 answers "what are people doing on my site." Google Ads answers "which ads produced results." They will not agree on numbers, and they are not supposed to.
Expect three or four numbers for the same thing, and expect the ad platforms to sit at the top. Directional guidance from published tracking audits puts Google Ads roughly 10 to 30 percent above GA4 on form-fill conversions. Against a CRM the gap is often wider still.
The reasons are structural, not faults:
The useful framing: your CRM is the source of truth for how many real leads you got. The ad platforms are the source of truth for which channel produced them. Neither is trying to answer the other's question.
That said, do not assume the CRM is automatically the clean one. Failed integrations, deduplication rules, and lead-routing logic all remove records that were genuine conversions. A large unexplained gap is worth investigating on both sides.
Read the Measurement ID off the Data Streams panel, not from a document or your memory. A wrong Measurement ID produces a site that looks perfectly tagged and reports nothing. It is the most common tracking bug there is, and it can go unnoticed for months. The whole point of the check is that your records may be wrong.
Consent mode passes each visitor's cookie-banner choice to Google, so Google tags adjust their behavior according to what that person agreed to. This is a compliance question, not an optimization one, and it has to be settled before you build rather than after.
To keep using Google tags for measurement, ad personalization, and remarketing, you must collect consent from end users based in the EEA and share those consent signals with Google. Since March 2024, Google has required websites and apps serving visitors in the EEA and UK to use Consent Mode v2 through a Google-certified consent management platform, regardless of where your company is based.
Consent Mode v2 added two signals to the original set: ad_user_data, governing whether data can be sent to Google for advertising measurement, and ad_personalization, governing remarketing. Google requires implementation for users in the EEA, UK, and Switzerland, though implementing globally simplifies your setup and prepares you for regulation elsewhere.
Implementing consent mode is a substantial piece of work in its own right and sits outside this manual. What matters here is that you decide whether you need it before building, not after.
Gate — before Chapter 3: one action chosen, confirmed it completes on your own domain, GTM container confirmed live, GA4 ID verified, consent question settled, and a decision made on whether you are doing Chapter 7.
CHAPTER 3 REQUIRED
The only chapter you cannot complete in a settings screen. Your website has to say "this just happened." It is a small job, but it has to be specified precisely, and it is the step most likely to be done subtly wrong.
Where you work: A request to a developer or an AI coding toolYour time: 15 minTheir turnaround: hours to weeks
contact_form_submit.Write it down. You will type it again in step 5.1.5, and it must match exactly.Most developers have wired up a conversion event before and will only need points 2 and 3. The remaining points exist so the three failure modes are written down rather than discovered later.
Right now we cannot see which ads and keywords produce real leads on [landing page], because nothing tells Google Ads when someone actually submits the form. This adds that signal. Nothing changes for the visitor.
Fire a conversion event when the form on [landing page] submits successfully, and not at any other point. Adjust anything below that does not match how the form is built.
<span id="conversion-email" hidden> works. Whichever ID you choose, send it to me. I need to reference it later.dataLayer.push({ event: 'contact_form_submit', form_type: '...' })Which files you changed, the exact element ID you used, and whether the element ends up written before the push. Also anything here that did not fit the setup, or that you would do differently.
You are asking for two things to happen the moment a submission genuinely succeeds. Not when the button is clicked. Not when validation fails. Only when the lead actually landed.
The reason behind each point sits inside the request itself, so the developer reads it in context rather than taking your word for it. If you trim the request for your own situation, keep the reasons attached to the points you keep. A bare instruction is the one most likely to get implemented in a way that technically complies and silently fails.
AI coding tools are fast, and they are also confidently wrong more often than you would like. The closing section asks the tool to report anything that did not fit, which most will answer honestly when asked directly. Then ask it these three follow-ups, which cost nothing and catch the common errors:
This step confirms the event exists and is clean. It cannot confirm the ordering requirement from point 4 of the request. That check comes in step 7.3, and if you are not doing Chapter 7 you do not need it.
@. It should return no results.Everything in Chapters 4 through 7 assumes this event exists and is visible to GTM. Building a trigger, two tags, and a conversion action on top of an event that never fires is the most expensive mistake available in this process.
The search for @ in 3.2.9 confirms no email address is sitting in the data layer message itself. It should only ever be in the hidden element, where a single variable reads it deliberately, rather than in a message every tag in the container can see.
Point 4 of the request asks for the hidden element to be written before the data layer push. Verifying that means reading the page's source code as it executes, which is a developer task, not a marketing one. This manual is not going to pretend otherwise.
You have two ways to close the gap. Do the first now, and the second in Chapter 7 if you are doing it.
Send to whoever made the change
"Can you confirm in writing that the hidden element containing the email is written into the page before the dataLayer.push runs, not after? And can you paste the two lines of code so I have them on record?"
If they answer "after" or "at the same time," or cannot say, the change needs revisiting. If they answer "before" and show you two lines where the element write comes first, you are covered.
The second and stronger check is step 7.3, which observes the result in Tag Assistant rather than trusting a written answer. It requires the variable from step 7.1 to exist, which is why it lives in Chapter 7 rather than here.
Gate — before Chapter 4:
☐ Your event name appears in the Tag Assistant event list
☐ The expected fields are in the payload
☐ Searching for @ returns nothing
☐ If doing Chapter 7: you have written confirmation of the element ordering
CHAPTER 4 REQUIRED
This comes before any tag work, because creating it produces the two values GTM needs. It also contains the two settings most likely to quietly damage an account: primary versus secondary, and conversion value.
Where you work: Google Ads → GoalsTime: 20–30 minutes
While the Analytics property remains attached as a data source, every route to creating a conversion loops you back into a list of GA4 events. That list is usually page_view, scroll, session_start, and user_engagement, none of which are conversions. Importing them makes your conversion count roughly equal your click count, which is worse than having no data at all.
There is a second reason to avoid the GA4 import path. Conversions measured by importing Google Analytics goals are not supported for enhanced conversions. Choosing that route closes off Chapter 7 entirely.
You may see a warning that no Google tag was found. This is expected. Nothing has fired yet because you have not built the tag. Continue past it.
Contact Form Submit.The category groups similar conversions together and helps Google's reporting make sense of what you are measuring. Pick the closest match; if none fits well, choose the next best rather than forcing an inappropriate one.
The name is what you will see in reports. "Contact Form Submit" beats "Conversion 1" when you return to this account in six months, or when someone else inherits it.
"Every" counts each submission separately. "One" counts a maximum of one conversion per ad click, no matter how many times the person submits.
For lead generation, One is correct. Somebody who fills in your form twice from the same click is still one lead, and counting them twice inflates your numbers and misleads bidding. "Every" is for ecommerce, where two purchases genuinely are two purchases.
This is the setting that decides what your budget chases, and it is routinely set wrong.
Primary actions are reported in the "Conversions" column and are used for bidding, as long as the standard goal they belong to is being used for bidding. Secondary actions are for observation only: they appear in the "All conversions" column, but are not used for bidding, even if the goal they sit in is used for bidding.
When you run Target CPA, Maximize Conversions, or Target ROAS, the algorithm needs a single north star. If your campaign optimizes toward a low-intent action, the algorithm will drive more of that behavior, even where it does not equate to revenue. Marking everything as primary means Google treats newsletter signups, contact form views, and ebook downloads with equal importance.
A demo request, a gated PDF download, and a newsletter signup are separated by an order of magnitude in value. Set all three primary and Smart Bidding will chase whichever is cheapest and most abundant, which is almost never the demo request. Your conversion count rises, your pipeline does not, and the reporting looks healthy throughout.
The exception people are caught by. Conversion actions included in a custom goal are used for both reporting and bidding regardless of whether they are set as primary or secondary. A secondary action placed inside a custom goal will influence bidding.
Be deliberate about keeping only one primary action per goal. Multiple primary conversions can cause double or triple counting for campaign optimization.
1 and treat it as a placeholder.Most guides tell you which button to click and move on. The choice determines whether value-based bidding is available to you later, so it is worth understanding.
Value-based bidding means strategies that optimize for total conversion value rather than conversion count. Target ROAS and Maximize Conversion Value are the two you will meet. They only work if your conversions carry meaningful, differentiated values.
If every conversion carries the same value, or no value, you are optimizing for volume. Maximize Conversions and Target CPA treat every lead identically. For a business where all leads genuinely are equivalent, that is fine. For most B2B, it is not.
This is how B2B marketers approximate revenue before revenue exists. Your CRM knows which leads became pipeline, but Google Ads does not, and the sales cycle is too long to wait. So you assign each conversion action a value reflecting its historical worth, and let the algorithm optimize for the weighted total rather than the raw count.
A worked example. Suppose historically your demo requests close at 12% with an average contract value of $40,000, your trial signups close at 4%, and your gated downloads close at 0.5%. Expected values are roughly $4,800, $1,600, and $200. You do not need those exact figures in the platform. What matters is the ratio, so you might set demo requests at 100, trials at 33, and downloads at 4. The algorithm now knows a demo is worth roughly twenty-five downloads, and bids accordingly.
Refinements once you have volume: value enterprise-segment leads above commercial, weight by firmographic fit if you can pass that at submission, or move to importing actual closed-won values from your CRM, which is the highest-leverage version and a separate build.
Why not to leave the default. "Use different values for each conversion" expects your tag to pass a value with every conversion. If it does not, Google records everything at the default of 1 unit of currency, and that fabricated figure will appear in your reports and can feed value-based bidding.
The close rates and contract value above are illustrative arithmetic, not benchmarks. Derive your own ratios from your CRM, and note the date you derived them, because close rates move.
The click-through conversion window is how long after an ad click you are still willing to credit a conversion to that click.
Record your choice. A change here shifts your reported numbers with no other cause, and it is a frequent source of "why did the data move" confusion months later.
The attribution model on the same screen controls how credit is divided when someone interacts with several ads before converting. Data-driven is the default and is right for most accounts. Attribution is a large topic in its own right and sits outside this manual, but you should know the setting exists.
These two values together are the address the tag sends to. The ID identifies your account; the label identifies which conversion action within it. Without both, the signal goes nowhere and Google Ads reports zero.
This is why Chapter 4 comes before Chapter 5. You cannot configure the tag until this address exists.
Skip this step if you are not doing Chapter 7.
Enhanced conversions sends a hashed version of the person's email alongside the conversion, so Google can still match it to a signed-in user when cookies fail. It improves match rates; it does not create conversions that would not otherwise exist. The email is hashed in the browser before it leaves, so Google never receives the real address.
This is an account-level setting, not a per-conversion one, which is why there is no toggle on the conversion action screen itself. Setting the method to Google Tag Manager is what tells Google to expect the data from your container rather than from a directly installed tag.
Gate — before Chapter 5: Conversion ID and Label written down, and deliberate choices made on primary versus secondary, count, value, and window.
CHAPTER 5 REQUIRED
Connect the announcement from Chapter 3 to the address from Chapter 4. Three things to build, in this order, because the last one references the first.
Where you work: Google Tag ManagerTime: 20 minutes
Contact Form Submit.contact_form_submit is not the same as Contact Form Submit. Capitalization and underscores matter.A Custom Event trigger means "watch the data layer message board for a specific message." When that exact message appears, anything attached to this trigger runs.
The exact-match requirement in 5.1.5 causes more failures than any other single thing in GTM. A trigger that does not match produces no error; the tag simply never fires, and you get zero conversions with nothing to diagnose.
"All Custom Events" means the trigger fires every time that event name appears, anywhere on the site, under any circumstances. That is correct here, because the event name is already specific to one action and your site only fires it in one place.
"Some Custom Events" adds further conditions on top of the event name. You reach for it when the same event name fires in more than one situation and you only want some of them. Common cases:
form_submit for the contact form, the newsletter form, and a support request, you would use Some Custom Events with a condition on a field in the payload, such as form_type equals Contact, so each form can feed a different conversion action.The general rule: if your event name uniquely identifies the thing you care about, use All Custom Events. If the event name is generic and you need to narrow it, use Some Custom Events and add a condition on a field the event carries. That is also a good argument for naming events specifically in the first place, since a precise name in Chapter 3 saves you conditions here.
Conversion Linker.When someone clicks your ad, Google appends an identifier to the landing page URL. The Conversion Linker's job is to capture that identifier and store it, so that when the person converts later, possibly on a different page, the conversion can be credited back to the click that produced it.
It fires on All Pages because you cannot know in advance which page a visitor will land on. Without it, attribution degrades and conversions may go uncredited.
Google Ads - Contact Form Submit.This is the tag that actually sends the conversion to Google Ads. The ID and Label are the address. The trigger decides the moment.
You may see a warning reading "No Google tag found in this container." Ignore it and do not click "Create tag." It refers to a separate Google Ads base tag you do not need, because the Conversion Linker from step 5.2 covers the linking requirement.
Gate — before Chapter 6: both tags appear in your Tags list, each showing its correct trigger in the Firing Triggers column. The Conversion Linker should show All Pages; the conversion tag should show your custom event trigger.
CHAPTER 6 REQUIRED
Everything so far exists only in your workspace. Publishing makes it live, and then you test the whole chain end to end on the version real visitors see.
Where you work: GTM, your live site, Google AdsTime: 15 min, then a wait
Contact form conversion tracking.This is where the workspace, version, and publishing concepts from section 1.2 become concrete. Submitting turns your draft workspace into a numbered version. Publishing pushes that version to your live website.
Until you publish, your visitors are running whatever was published last, no matter how correct your workspace looks. "It worked in Preview but not live" almost always means this step was skipped.
Write a real description. Six months from now, when a number moves and you are looking for what changed, "Version 12" tells you nothing.
Each earlier verification tested a single link. This one tests all of them together, on the version real visitors are running.
Step 6.2.7 matters more than it looks. A conversion that records without the lead actually arriving means you are counting something that did not happen, which is worse than counting nothing.
Always test on your production address. Spam protection services and some tag configurations check the page's hostname against a fixed list, and staging environments that generate a new URL on every deployment will be rejected every time. Chasing those addresses is a losing game.
Gate — conversion tracking is complete when:
☐ Both tags fired on your event
☐ The lead notification actually arrived
☐ The conversion is visible in Google Ads → Goals
CHAPTER 7 OPTIONAL
Improves how reliably Google matches your conversions when cookies fail. It does not create conversions that would not otherwise exist, which is why it is optional. It also contains the strongest check on the ordering requirement from Chapter 3.
Where you work: Google Ads, then Tag ManagerTime: 25 minutesRequires: points 2 and 4 of the step 3.1 request
Enhanced conversions sends a hashed version of the person's email alongside the conversion, so Google can still match it to a signed-in user when cookies are blocked or consent limits tracking. The email is hashed in the browser before it leaves, so Google never receives the real address.
What it improves: match rates, and therefore the completeness of your reported conversions. What it does not do: create conversions, change what a conversion means, or make bidding smarter on its own.
Skip this chapter if: your conversion volume is very low, in which case the measurable difference will be close to nothing; or your website change from Chapter 3 did not include the hidden element; or your conversion action was created by importing a GA4 event, in which case enhanced conversions is unavailable regardless of what you configure here.
This step assumes you completed step 4.8, which turns enhanced conversions on at account level. If you skipped it, go back and do it first.
DOM - Conversion Email.#. For example #conversion-email.This variable's job is to reach into the page, find the hidden element your developer created, and read the email out of it.
A CSS selector is an address for a specific piece of a web page. The # means "the element with this ID." Leaving Attribute Name blank tells GTM to read the element's text content rather than one of its HTML attributes, which is what you want here.
UPD - Contact Form.DOM - Conversion Email from the list.The variable from 7.1 produces a plain email address. This one wraps it in the structure Google expects, and handles the hashing before anything leaves the browser.
Choose Manual over Automatic deliberately. Automatic collection scans the whole page for anything resembling contact details, which can pick up your own address from the footer and send that instead of the visitor's.
This is the check that closes the gap left open in step 3.2. It observes the result rather than trusting a written answer, and it is the only marketer-accessible way to prove the ordering requirement was met.
DOM - Conversion Email in the list. It is alphabetical, so look under D.undefined or an empty value. The variable found nothing. Either the hidden element does not exist, the element is written after the event fires, or the selector in step 7.1.9 does not match the actual ID. Work through those three in that order.To whoever made the website change
"In GTM Preview, my DOM Element variable pointed at #your-element-id is returning undefined at the moment the your_event_name event fires. Can you confirm the element exists in the DOM at that point, and that it is written before the dataLayer.push rather than after? Paste the two lines so I can see the order."
That message is specific enough that a developer can act on it immediately, and it names the exact symptom rather than asking them to guess what is wrong.
Gate — before step 7.4: the variable resolves to the email you typed, not to undefined.
Google Ads - Contact Form Submit from step 5.3.user_data.UPD - Contact Form from step 7.2.The user_data parameter is what carries the hashed email to Google alongside the conversion. Without it, the two variables you built do nothing.
If you are following an older tutorial. Many describe an "Include user-provided data from your website" checkbox on this tag. That checkbox is no longer available for new setups in Google Tag Manager for individual events; you now add user_data manually to Event Parameters using a custom user data variable. That is what steps 7.4.2 to 7.4.5 do.
Gate — enhanced conversions is complete when: the variable resolves to a real email in Preview, user_data is on the tag, the container is published, and the tag still fires on the live site.
Work down each list in order. Stop at the first thing that is wrong, rather than checking everything at once, or you will not know what fixed it.
user_data event parameter is present and points at the User-Provided Data variable. See step 7.4.5.Terms appear in the order the manual introduces them, so you can read this alongside the chapters rather than hunting alphabetically.
CHAPTER 1 — TAG MANAGER'S OWN FURNITURE
GTM-XXXXXXX.CHAPTER 1 — THE FIVE MOVING PARTS
CHAPTER 2 — DECIDING AND CHECKING
G-XXXXXXXXXX. A wrong one silently reports nothing.CHAPTER 4 — THE CONVERSION ACTION
CHAPTER 5 — WIRING IT UP
CHAPTER 7 — ENHANCED CONVERSIONS
#conversion-email means "the element with the ID conversion-email."user_data is the one that carries the hashed email.Platform behavior changes. Verify anything that does not match your screen. Checked September 2026.
user_data event parameter — Google Ads Help and Search Ads 360 HelpI highly recommend checking out AnalyticsMania.com and/or lovesdata.com.
Analytics Mania, run by Julius Fedorovicius, is the most thorough free resource on Google Tag Manager specifically, with step-by-step guides that go well past what this manual covers. Loves Data, run by Benjamin Mangold, covers Google Analytics, Tag Manager, and Google Ads together, which is useful once you start caring how the three fit into one measurement picture.
The time estimates at the top are from a live build, not measured averages. The conversion value example in step 4.5 is illustrative arithmetic, not a benchmark; derive your own ratios from your CRM. The platform-versus-CRM percentage range in step 2.3 is directional guidance from published tracking audits, not a universal figure. The troubleshooting entries are drawn from a live implementation rather than from documentation.