Google Ads Conversion Tracking with GA4 and GTM: The Complete Implementation Guide

The short answer

Google Ads is not measuring your business. It is measuring whatever signal you send it, and then buying more of that. Every argument about bidding strategy, budget pacing and campaign structure sits downstream of one question: is the signal the account optimizes toward actually the thing the business gets paid for?

For that to be true, four conditions have to hold at the same time. Very few accounts satisfy all four, and the ones that do rarely have a bidding problem.

1. The conversion actions marked primary correspond to outcomes the business genuinely values — not the easiest events to fire.
2. Each of those actions is counted once per real occurrence, with no duplicate tag fires and no double path into the account.
3. Each carries a value that reflects what the outcome is worth, so bidding can distinguish a large order from a small one.
4. The signal survives the gap between click and outcome — including the part that happens in a CRM days later, off the website entirely.

Decide the architecture before you touch a tag

Almost every implementation guide starts at tag installation. That skips the decision that determines whether the whole thing works: a conversion can reach Google Ads through several genuinely different routes, and they are not interchangeable. Picking the route is the engineering decision. Installing the tag is the easy part that follows from it.

Route one — the Google Ads tag firing on the site

The shortest path. A conversion action is created in Google Ads, which produces an identifier pair — a conversion ID for the account and a label for that specific action. A snippet on the site fires with those values at the moment the action completes, and the conversion is recorded against whichever ad click the browser can still associate with that visitor.

The advantage is directness. There is one hop, one place for it to break, and no dependency on another product's configuration. The limitation is that it only ever sees what happens in that browser session, on that site. Anything that happens later, elsewhere, or to a person who cleared their cookies is invisible to it.

Route two — importing conversions from GA4

GA4 collects events from the site, certain events are designated as the ones that matter, and those are imported into Google Ads as conversion actions. The appeal is reuse: the measurement work already done for analytics becomes available to advertising without rebuilding it, and the definitions stay consistent between the two reports.

The cost is a longer chain and a second owner. The conversion now depends on GA4's event collection being correct, on the property being linked to the ads account, on the event still being marked as a key event, and on whoever administers GA4 not renaming things. It also introduces a processing delay relative to the direct tag, which matters when someone is watching same-day performance. And GA4 applies its own attribution before the import, which is a large part of why the two products disagree — covered further down.

Route three — offline conversion import

The click identifier is captured when the visitor lands, stored with the lead record, and later — when a human decides that lead was qualified, or when a contract is signed — the conversion is uploaded back to Google Ads matched to that original click. Nothing about this happens in the browser at the moment of conversion, because the conversion did not happen in a browser.

This is the only route that lets bidding optimize toward an outcome that occurs off the website. For any business where a person judges lead quality, it is the difference between an algorithm buying form fills and an algorithm buying customers. It also has the most moving parts and the most human dependencies, which is why so few accounts run it.

Route four — server-side tagging

Instead of the browser talking directly to each measurement vendor, the browser sends one request to an endpoint you control, and a server-side container distributes events from there. The reasons to do it are real: fewer third-party scripts on the page, more control over what data leaves and to whom, resilience against browser-level restrictions on client-side storage, and the ability to enrich an event with data the browser never had.

The reasons not to are equally real. It is infrastructure — it costs money to run, it needs monitoring, and when it fails it fails silently for every vendor at once rather than for one tag. It also does not fix a bad measurement design; it faithfully forwards whatever you decided to send. Server-side is an upgrade for an implementation that already works, not a rescue for one that does not.

Most mature accounts are not on one route. They run the direct tag for in-session outcomes, offline import for the outcomes that matter commercially, and GA4 alongside for context — with strict discipline about which of them is allowed to be primary. The failure is not running several routes; it is running several routes into the same outcome and counting it more than once.

What actually counts as a conversion

The first thing I check in any account is not whether tracking fires. It is the list of conversion actions and which ones are marked primary. That list is a statement about what the business wants more of, and it is wrong more often than the tags are.

The instinct when setting up an account is to track everything measurable — page views on the pricing page, PDF downloads, scroll depth, video plays, phone clicks, chat opens, form starts, form completions. Tracking all of that is fine. Telling the bidding algorithm that all of it is a conversion is not, because the algorithm cannot tell that one of them is a signed contract and another is somebody's cursor happening to reach the bottom of a page.

The distinction that matters most in the account

Google Ads separates conversion actions into primary and secondary. Primary actions are what bidding optimizes toward and what fills the headline conversions column. Secondary actions are still recorded and still reportable, but they are excluded from bidding and from that headline column. This is one setting per action and it is the highest-leverage setting in the entire measurement stack.

The reason it matters is that automated bidding treats every primary action as a comparable outcome to acquire, weighted by whatever value it carries. Add a low-friction action to the primary set and the algorithm will find the cheapest way to generate it — which is usually traffic that does the easy thing and never does the valuable one. The account gets better at the metric and worse at the business, and every dashboard says it is working.

A workable default

• One primary action for ecommerce: the purchase, with its value. Add-to-cart and checkout-start are secondary — useful for diagnosing where a funnel leaks, dangerous as bidding targets.
• One primary action for lead generation: the qualified lead, imported from the CRM, not the raw form submission. The form submission stays secondary so you can still see the ratio between the two.
• Phone calls treated with the same discipline as forms. A call connecting is not the same outcome as a call that produced a qualified opportunity, and only one of those is worth bidding toward.
• Everything else secondary by default. The burden of proof sits on promoting an action to primary, never on leaving it secondary.

There is a legitimate exception. Accounts with genuinely low volume of the real outcome may not give an automated bidding strategy enough data to model anything, and a higher-volume proxy action can be the pragmatic primary while volume builds. That is a deliberate, documented, temporary trade — and it belongs inside the same written decision rules that govern bid and budget changes. The bid governance framework covers how to write that threshold down before the account launches, so the temporary proxy does not quietly become permanent.

GTM as the implementation layer

Tags can be pasted into a site's template. They work. The reason to put a tag manager in between is not that hardcoding fails immediately — it is that hardcoding fails later, invisibly, at the worst possible time, and nobody who could notice is looking at the template.

Container structure that survives handover

A container that a second person can understand six months later has a naming convention and sticks to it. Prefix every tag with its destination, every trigger with the condition it represents, and every variable with its source. Nobody enjoys this and everybody is grateful for it during the first incident.

• One configuration tag per destination, fired once, on a trigger you can name. Duplicated configuration tags are among the most common causes of doubled numbers.
• Event tags that do exactly one thing, triggered by exactly one condition. A tag doing double duty across two situations will eventually be right for one and wrong for the other.
• Triggers scoped as tightly as the real condition. A trigger set to all pages because it was faster to build is a phantom conversion waiting for a URL change.
• Constants — account identifiers, conversion labels — stored as variables, not typed into each tag. When one changes, it changes in one place.
• Version notes on every publish that say what changed and why. This is the closest thing tag management has to a commit message, and it is what makes a rollback a decision rather than an archaeology project.

The data layer is a contract

This is the concept that separates an implementation that lasts from one that has to be rebuilt after every site change. The data layer is a structured object the website pushes facts into: an event name, and the parameters that describe it — the order identifier, the value, the currency, the form type, the plan selected. Tags read from that object. They do not read the page.

The alternative is tags that infer meaning from the rendered page — a trigger that watches for a specific CSS class, a URL containing the word thanks, a button whose text reads Submit. Every one of those is a guess about markup that exists for design reasons and will change for design reasons. The redesign ships, the class name changes, the trigger stops matching, and conversions quietly stop being recorded. Nobody gets an alert, because nothing errored. A number simply got smaller, and by the time somebody notices, several weeks of bidding decisions were made on a signal that was decaying.

With a data layer, the site's responsibility is explicit: when a real purchase completes, push an event with these named parameters. That is a contract a developer can honor through any redesign, and it can be checked in a test suite. Measurement stops depending on what the page looks like and starts depending on what the application knows.

What belongs in the data layer

Everything a tag would otherwise have to infer. The event name in past tense, because it describes something that happened. A unique identifier for the transaction or the lead. The monetary value and its currency, taken from the server-side truth rather than parsed out of formatted text on the page. Enough classifying detail to segment later — product category, form location, plan tier — because adding a parameter after the fact means waiting for new data, and the report you want will always be about the period that has already passed.

Deduplication and the arithmetic of double counting

Inflated conversion counts damage an account more than missing ones, because missing conversions make performance look worse than it is and someone investigates. Inflated conversions make performance look better than it is, and nobody investigates a good number. Bidding then chases a phantom, budgets follow the phantom, and the correction arrives as a business problem rather than a measurement one.

The counting rule

Each conversion action carries a setting that decides whether every conversion following a click is counted, or only one. The choice is not stylistic — it encodes what the outcome means.

• Count every conversion for ecommerce purchases. If somebody buys twice after one click, that is genuinely two outcomes and the account should know about both.
• Count one conversion per click for lead-generation actions. A prospect who submits the contact form, then the callback form, then the brochure form is one lead having one intent, not three. Left on every, that one person becomes a triple weight in the bidding model, and the campaigns that attract indecisive form-fillers will look like the best campaigns in the account.

Transaction identifiers

Sending a unique order identifier with each purchase conversion is the mechanism that makes duplicate fires harmless. When the same identifier arrives twice, the duplicate is discarded rather than added. This matters far more than it sounds, because there are entirely ordinary reasons for a confirmation page to be loaded more than once: a customer refreshes, an email receipt links back to it, a slow connection makes somebody hit the button again, a payment provider redirects through the page twice.

The identifier has to be genuinely unique per order and it has to come from the order system. A timestamp is not an identifier. A session identifier is not an identifier. The order number that appears on the invoice is.

Duplicate paths and duplicate tags

The third source is structural and the hardest to see, because each half of it is individually correct. The same real action is configured as a Google Ads conversion action fired by the site tag, and also imported from GA4 as a key event, and both are marked primary. Nothing is misfiring. The account is simply being told twice about one thing.

The related version is a container with two configuration tags, or a site that has both a hardcoded snippet from a previous build and a tag manager firing the same tag. This is extremely common after a migration or an agency handover, and it is worth explicitly checking for rather than assuming, because the previous implementation was usually removed from the documentation without being removed from the site.

Enhanced conversions, and what they actually solve

Browser-based conversion measurement rests on the browser retaining something that links this visitor to an earlier ad click. Storage restrictions, cross-device journeys, privacy settings and long consideration windows all erode that link. The conversion still happened, and the click still happened, but nothing remains to connect them, so the conversion is recorded as unattributed or not at all.

Enhanced conversions address that gap using data the customer already provided to you — most often an email address given during checkout or on a form. That value is normalized and hashed before it leaves the browser or server, and the hash is sent alongside the conversion. Google can compare that hash against its own signed-in data to recover a match the browser could not supply. The raw value is never transmitted; only the irreversible hash is.

What it requires from you

1. First-party data actually collected at the point of conversion. If your checkout does not capture an email address, there is nothing to hash, and the feature has nothing to work with.
2. The data available to the tag in a reliable form — either present in the data layer at the moment the conversion fires, or readable from a stable field. Guessing at a form field by its position on the page is the same fragility described earlier.
3. Correct normalization before hashing. Whitespace, casing and formatting all change a hash completely, so the same email formatted two ways produces two unrelated hashes and no match at all.
4. A defensible basis for using the data this way, disclosed to the people it belongs to.

That last point deserves care rather than confidence. Sending customer-derived identifiers to an advertising platform carries obligations that differ by jurisdiction and by the nature of your relationship with the customer, and the specifics change. Treat it as a question for whoever is responsible for privacy at the business, disclose the practice in the privacy policy, and respect the consent state the user chose. Enhanced conversions are a measurement improvement, not a reason to move faster than your own privacy commitments.

Offline conversion import — the loop most accounts never close

For a lead-generation business, this is the single highest-value thing in this guide, and it is the thing least likely to exist in any account you inherit. The reason is not that it is conceptually hard. It is that it spans three systems and requires a person to keep it running, which means it needs an owner, and ownership is where marketing implementations go to die.

The loop, in four steps

1. Capture. With auto-tagging enabled, Google appends a click identifier to the landing page URL. A script reads it on arrival and stores it — typically in a first-party cookie so it survives the visitor browsing several pages before converting.
2. Persist through the form. The stored identifier is written into a hidden field on every lead form, so it is submitted along with the name and email. This step is where implementations fail most often, particularly with embedded third-party forms whose fields you do not fully control.
3. Store in the CRM. The identifier lands on the lead record as a real field and stays there through every stage change, merge and reassignment for the whole length of the sales cycle. A field that gets wiped during a merge breaks the loop for exactly the leads that got the most attention.
4. Upload the outcome. When the lead reaches the stage that matters — qualified, or closed with revenue — the conversion is sent back to Google Ads with the click identifier, the conversion action name, the time it occurred, and its value. Scheduled and automated, not a monthly spreadsheet somebody remembers.

Why this changes what bidding can do

Without the loop, the best signal available to the algorithm is a form submission. Every form submission looks identical to it: the tire-kicker, the competitor, the student doing research, and the buyer with budget and authority. The algorithm optimizes for volume of an event that contains all four, and it will reliably find more of whichever is cheapest to acquire — which is never the buyer.

With the loop, the algorithm sees which clicks produced leads a human judged worth pursuing, and — if you send values — which produced the largest ones. Now the same optimization machinery is pointed at something the business recognizes. Nothing about the bidding strategy changed. What changed is what it was aiming at.

This is also where measurement work and pipeline work stop being separate projects. The qualification decision has to be consistent enough to be worth sending, which means the definition of a qualified lead has to be written down and applied the same way by everyone. Building that scoring layer is its own piece of work — the post on building lead scoring automation covers how to define and operationalize it, and offline import is what turns that score into something an ad platform can act on.

Where it breaks

• The identifier is lost on a redirect or a landing page that strips query parameters before any script runs. Capture as early in the page lifecycle as you can.
• The lead form is a third-party embed that silently drops unknown hidden fields. Test this specifically; the form will submit successfully and simply arrive without the field.
• The CRM field is not on the layout the sales team actually uses, so an automation that touches the record overwrites it with an empty value.
• The upload runs, reports success, and matches almost nothing — usually a formatting problem with the conversion timestamp or a mismatch between the conversion action name in the file and in the account.
• The conversion is uploaded after the click has aged past the conversion window configured for that action. Long sales cycles need the window set to match reality, and this has to be decided before the leads that need it are generated.

The variant that does not need a click ID

There is a second form of offline import that matches on hashed customer data instead of a click identifier — the same hashing principle as enhanced conversions, applied to leads. You capture and hash an identifier the customer gave you at form submission, and later upload the outcome keyed to that same hashed value. It is a genuinely useful alternative when the click identifier cannot be made to survive the form, which is a common situation with embedded forms and third-party booking tools. It carries the same first-party data obligations described above.

Attribution, and why two reports disagree

This section prevents more pointless client arguments than anything else in this guide. Somebody opens Google Ads, sees one conversion number, opens GA4, sees a different one, and concludes the tracking is broken. It usually is not. The two products are answering different questions, and both answers are correct within their own frame.

Four reasons the numbers differ

1. Different date basis. Google Ads credits a conversion back to the date of the click that led to it. GA4 records it on the date it happened. When there is a lag between click and conversion, the two reports are attributing the same event to different days, and every period comparison inherits that offset.
2. Different credit rules. Google Ads only distributes credit among Google Ads interactions. GA4 distributes credit across every channel it can see — organic search, direct, referral, email. A conversion where a paid click was one of several touchpoints will be counted more fully in Google Ads than in GA4's channel reporting.
3. Different models. The two products can be running different attribution models at the same time, and the models are not required to agree. Reading a data-driven number against a last-click number and calling the gap an error is a category mistake.
4. Different conversion windows and different definitions. If the imported GA4 key event and the native conversion action were configured separately, they may not even be measuring the same thing despite sharing a name.

What to do about it

Pick one system as the reporting source of truth for each question and stop comparing raw totals across systems. Google Ads is the right place to judge whether a campaign is buying good outcomes, because it is the system making the buying decisions and it sees them in the frame it decides in. GA4 is the right place to understand how channels contribute to each other. The CRM is the right place to know what the business earned. Those three will never produce the same number and do not need to.

The one comparison worth making regularly is directional rather than absolute: does the trend in platform-reported conversions move with the trend in CRM-recorded outcomes? When those two diverge — platform up, pipeline flat — you have a real problem. When they move together at different absolute levels, you have two systems working correctly.

Values, not just counts

A conversion count tells the bidding algorithm how many outcomes it produced. A conversion value tells it which ones were worth having. Without values, every conversion is worth exactly as much as every other, and the algorithm has no way to prefer the large order over the small one — so it prefers the cheap one, which is usually the small one.

Static values

The simplest version: one fixed value per conversion action, based on what an outcome of that type is typically worth to the business. It is crude, and it is enormously better than nothing. Even an approximate value gives the algorithm a way to distinguish between two conversion actions, which is the whole point — the ratio between them carries most of the information, and the ratio can be roughly right even when neither absolute number is precise.

Deriving it is a business exercise, not a marketing one. What proportion of leads of this type become customers, and what is a customer worth over the period the business plans in? Those are numbers the business either knows or should. If nobody can answer them, that is a genuine finding and it should be escalated rather than papered over with a guess nobody documented.

Dynamic values

For ecommerce, the value is the actual transaction amount, passed through the data layer with its currency, taken from the order rather than scraped from the page. This is unambiguously the right approach and the only real work is making sure the number sent is the one the business would recognize — before or after tax, before or after shipping, and net of discounts, decided once and applied consistently.

For lead generation, dynamic values come from the pipeline. The offline import can carry the actual value of the opportunity, or a stage-weighted approximation of it. This is where the earlier work compounds: once the loop exists, sending a value costs nothing extra and converts the account from optimizing toward lead volume to optimizing toward pipeline value.

Value rules

Value rules adjust the value of a conversion based on conditions you specify — such as location, device or audience membership — without changing the underlying tracking. They are the right tool when you know something the tracking cannot see: that leads from one region close at a different rate, or that an existing-customer audience is worth less to acquire again.

They are the wrong tool for compensating for a measurement gap you could actually fix. A value rule applied because the real values are not being sent is an assumption encoded as a number, and it will keep applying long after the person who reasoned about it has left. Fix the measurement first; use value rules for genuine business knowledge that measurement cannot reach.

Consent and privacy, handled deliberately

I am going to stay general here on purpose. What is required of you depends on where you operate, where your users are, and the nature of your relationship with them, and it changes. Anyone who tells you the universal answer in a blog post is selling something. What follows is how the mechanism works, not what any law requires.

Consent mode is a way for a site to tell tags what the visitor consented to, rather than simply preventing tags from loading. The tags then adjust what they do — whether they may write or read advertising identifiers, whether they may use the data for personalization. The design goal is graceful degradation: when consent is denied, measurement becomes less precise rather than disappearing entirely, and Google can apply modeling to partially fill the gap.

• When advertising storage consent is denied, the identifiers that link a conversion to a click are not written or read, so that conversion cannot be attributed the ordinary way.
• Separate signals govern separate purposes — analytics storage, advertising storage, and whether user data may be used for personalization are distinct decisions with distinct effects.
• Consent state has to reach the tags before they fire, which makes the ordering of the consent tool and the tag container a genuine implementation detail rather than a formality.
• A consent tool that is installed but sends nothing to the tags is the worst of both outcomes — the appearance of compliance with none of the measurement behavior it implies.

The practical instruction is short: verify what your consent tool actually transmits, rather than trusting that installing it configured anything. Then get a decision from whoever owns privacy at the business about what you are permitted to collect and send, and build to that decision. Do not let the measurement architecture make that call implicitly through what happens to be easiest to implement.

Testing before trusting

No budget decision should depend on a number that has not been deliberately validated. Testing an implementation is not the same as glancing at the account and seeing conversions appear — conversions appearing is compatible with almost every failure mode described in this guide.

1. Test in preview or debug mode first, with the tag manager attached to a live session. Perform every conversion action by hand and watch what fires, in what order, with what parameters.
2. Deliberately try to break it. Submit an invalid form. Abandon a checkout at the payment step. Refresh the confirmation page. Load the confirmation URL directly without buying anything. Any of these producing a conversion is a defect, and each is a defect I have seen ship.
3. Verify the parameters, not just the fire. A tag that fires with an undefined value, an empty order identifier or the wrong currency is a tag that is failing quietly while looking healthy in a debug panel.
4. Check the payload actually leaving the browser, not only what the tag manager claims to have sent. These are different layers and they can disagree.
5. Confirm the conversion arrives in the account, with the value attached, against the intended conversion action.
6. For offline import, run one real lead end to end — click through an ad, submit the form, find the identifier on the CRM record, run the upload, and confirm the match. Do this once with a real lead before trusting the automated version.
7. Wait a full reporting cycle and reconcile against the source system. Same-day numbers are provisional in ways that hide exactly the errors you are looking for.

That last step is where implementation hands over to verification, and verification is a separate discipline with a separate sequence — reconciling events against real business records, checking container hygiene, mapping every conversion action back to revenue, and reconciling against the CRM for a full sales cycle. The conversion tracking audit sequence is the right next step once this build is complete, and it is what should run again before any significant budget increase — including on tracking you built yourself and are inclined to trust.

Failure modes

These are the ones that recur, in rough order of how often I find them in an account somebody else set up.

• Everything is primary. Fourteen conversion actions, all feeding bidding, several of them micro-events. The account is optimizing toward an average of unrelated things and nobody can say what it is buying.
• The conversion is a page view of a thank-you URL. It works until the URL is shared, bookmarked, indexed by a search engine, or reachable by anyone who types it — at which point conversions arrive that no human caused.
• The tag fires before the action completes. A conversion recorded on button click rather than on confirmed submission counts every failed validation, every timeout and every payment decline as a success.
• Two paths, one outcome. The direct tag and the GA4 import both marked primary for the same real event, doubling the count with no error anywhere.
• A trigger tied to page markup that a redesign changed. Nothing errors; a number simply becomes smaller, and the account keeps bidding on the remains of a signal.
• The offline loop that stopped. The upload has been failing for six weeks, the notification goes to an inbox nobody reads, and bidding quietly reverted to optimizing toward whatever else is still primary.
• Values that were correct once. A static value set from figures that were true two years ago, never revisited, now systematically misdirecting the bidding across the whole account.
• Conversion windows that do not match the sales cycle. A business with a long consideration period running a short window discards its own best conversions before they can be recorded.

The metric that lies

Conversion count rising while revenue stays flat. It is the single most common pattern in a degrading account, and it is almost never read as a warning, because the conversion count is the number on the dashboard everybody looks at and it is going up.

There are only a few explanations and none of them are good. A new conversion action was added to the primary set and is now inflating the total with a cheaper, less valuable event. A counting rule change turned one lead into three. A duplicate path was introduced during a migration. Or the algorithm, doing exactly what it was told, found a cheaper source of the tracked event — traffic that fires the conversion reliably and buys nothing.

The second number that catches it is the ratio between platform-reported conversions and outcomes recorded in the source system for the same cohort. Track that ratio over time as a first-class metric, not as a quarterly reconciliation exercise. A stable ratio means the count can be trusted as a proxy. A ratio drifting in either direction means the relationship between the signal and the business has changed, and the count stopped meaning what it meant last month — regardless of which direction it is moving.

A realistic implementation sequence

This is the order I work in. It deliberately puts the arguments before the engineering, because every one of those arguments will otherwise resurface as a technical problem after the tags are built.

1. Agree the single outcome the account exists to produce, with someone who has commercial authority. Write it down. Everything else is downstream of this and it takes a conversation, not a tool.
2. List every candidate conversion action and assign each one primary or secondary, with a reason. Expect this list to be shorter than the one you started with, and expect that to be uncomfortable.
3. Choose the architecture for each action using the four routes above. Decide explicitly which system owns which conversion, so nothing has two owners.
4. Specify the data layer contract with whoever builds the site — event names, parameters, when each fires. This is a written specification, not a conversation, because it has to survive the next developer.
5. Implement the data layer pushes in the application, at the point where the application knows the action genuinely completed. Server-confirmed, not fired hopefully on click.
6. Build the container: variables first, then triggers, then tags. Name everything to a convention from the start rather than intending to tidy it later.
7. Set counting rules, conversion windows and values on each conversion action, matched to the real sales cycle rather than to the defaults.
8. Test in preview against every path, including the deliberately broken ones, before publishing anything.
9. Publish, then verify in the live account with real traffic. Watch it for a few days before anything depends on it.
10. Build the offline loop if leads are qualified by a human — capture, hidden field, CRM field, scheduled upload — and prove it with one real lead end to end.
11. Add enhanced conversions once the underlying tracking is verified correct, with the privacy decision made and documented first.
12. Run the full audit sequence before the first budget increase, and put it on a recurring schedule after that.

Where to start if the account already exists

Almost nobody builds this from nothing. The usual situation is an account with tracking of unknown quality, and the temptation is to rebuild everything. Do not — you will lose conversion history the bidding strategies depend on, and you will spend weeks reconstructing decisions that were mostly fine.

Instead, do the cheapest high-value thing first: open the conversion actions list and fix which ones are primary. That is a settings change, it takes an afternoon, it requires no developer, and on most accounts it changes what bidding is aiming at more than any tag work would. Then fix duplicate paths, then set values, and only then consider architectural changes. If leads are qualified by a human and no offline loop exists, that is the project worth funding — everything else is refinement by comparison.

This whole sequence is the measurement stage of the Signal-to-Revenue Framework, documented in full on the Authority page. It is the stage everything else in an account depends on, and the one most often assumed rather than verified. I build these systems for clients through Arcetis, and the pattern holds across every account: the bidding problem people ask about is nearly always a measurement problem they have not looked at yet.

Related reading