Google Ads conversion-tracking audits for consultants: establish what the account actually measures

Define the client's measurement brief

A conversion-tracking audit needs a business question before a settings checklist. A consultant might be asked to review ecommerce purchase reporting, establish whether lead forms are measured, explain a discrepancy with Analytics or prepare a conversion-role change. Those requests have different evidence requirements and should not all become an automatic account cleanup.

Agree what the client wants to decide. If the concern is bidding toward low-value actions, review the relevant action and goal configuration. If a booking is missing, investigate the event and journey. If two totals disagree, establish their definitions and dates. A correct field inventory is valuable, but it does not independently settle every measurement problem.

Record the intended outcome and its commercial meaning. A purchase, an enquiry, a phone call and an attendance record are different stages. The client can decide which matters to the campaign, while the consultant establishes what the system actually measures. Keeping that agreement clear prevents a technical recommendation from silently redefining the client's business objective.

Define completion criteria for the engagement. A verified conversion-role change can close a configuration task. A website event test can establish behavior for the tested journey. A reconciliation can compare selected reporting measures. The client should know which of those was requested, which was performed and which remains separate work.

Map actions to actual business outcomes

Start by translating action names into the events they represent. A label such as “Lead” can mean a form submission, a qualified enquiry or a completed booking depending on the site. A name is useful for resolution, but it is not proof of business meaning. Confirm that meaning when it changes the recommendation.

Categories supply structured information, not a complete process map. An action classified as Purchase can represent a distinct product checkout, while another Purchase action can track the same checkout through a different source. Those are materially different situations. The consultant needs event or business evidence before treating them as interchangeable.

Retain the client's requested scope. All primary conversions can include several outcomes. Purchase-type conversions select a narrower category. Leads can aggregate primary lead types without forcing separate treatment of each category label. A named action request should remain named rather than broaden into a total simply because a wider figure looks more substantial.

A clear action map links each selected measure to the business decision it supports. It can identify who owns the implementation, what counts as completion and whether a value is actual sales revenue or an assigned estimate. This map gives the later field review a purpose and keeps the final recommendation understandable to someone who does not work with conversion enums.

For each important action, ask whether it represents a repeatable business event or an intermediate interaction. A completed repair enquiry and a click on the enquiry button are different even when their names sound similar. The button can be clicked without completing the form, while the form may be submitted through another route. The client should confirm which event the campaign is meant to pursue before the consultant prepares a role recommendation.

Keep that explanation concise enough to survive handover. A short description such as “successful submission of the public repair form” is more useful than a label copied from a tag manager with no business meaning. The technical owner can retain implementation detail separately. The action map joins those views without asking the client to understand every internal trigger name.

Read the available conversion inventory

The current audit analyses enabled conversion actions and their configuration, including category, origin, primary role and counting type. Its conversion-setup logic removes actions covered by the locked-conversion policy from the editable recommendation set. That filtered set is useful for remediation, but it is not a promise that every conversion source is freely writable.

A conversational inventory can answer a broader read question when requested. The client may want to list offline actions, calls or a specific named event even when the audit does not propose changing them. Reading availability and editing eligibility are different capabilities, and the response should preserve that distinction.

Use a narrow inventory for the question. There is no need to collect every ad and keyword to resolve one conversion action. The framework can use local resource and field metadata to determine structural capability, then request the current action evidence needed for the analysis or proposal.

Keep names in the client-facing output and identifiers behind the scenes. Two similarly named actions may require clarification through their source or relevant definition. The tool should resolve them precisely without presenting an unexplained account or action number as if it were useful business context.

Understand primary and secondary roles

Google's primary and secondary action guidance links primary reporting and bidding to the applicable goal. It also documents the custom-goal exception, where secondary actions can be used. A simple role label therefore needs goal context before it becomes a complete statement about campaign optimization.

For the app's requested primary-only reporting, include the selected primary actions and exclude secondary actions. If several primary actions contribute, their measured counts or values can be added within that definition. The tool should not silently discard one because an audit recommendation prefers a simpler ecommerce setup.

Changing a role is a configuration action, while answering a report is an analysis action. A client asking for total primary conversions has not asked to revise roles. The assistant should measure the requested definition and reserve changes for an explicit proposal with exact targets.

The consultant can explain the distinction in ordinary language: which actions are primary now, which outcome the client intends and which campaign goal applies. Avoid saying that every secondary action can never influence bidding under any circumstances. A bounded explanation prevents a useful shorthand from becoming an inaccurate universal rule.

Inspect goal scope separately from action roles

An action's primary flag is not the same field as an account-default goal or a campaign-specific goal. Google's account-default goal guidance explains that campaign-specific choices can change the applicable goal scope. The consultant should inspect that context when the client's question is what a campaign uses for optimization.

A role change can affect an action broadly, while a campaign-goal request concerns the selected campaign's measurement purpose. Do not substitute one for the other simply because both mention conversions. The shared capability framework should discover the resource and fields corresponding to the intended effect.

Different offers can legitimately use different outcomes. A retail campaign might optimize for purchases, while a consultation campaign uses enquiries. Making all goals uniform without reviewing those purposes can erase a useful business distinction. Consistency is appropriate when it reflects the client's intended policy, not merely because the account becomes easier to summarise.

The proposal should explain scope in readable terms. Name the action for a role change and the campaign for a campaign-goal change. If both are requested, show both steps explicitly. A technical object dump does not make the wider effect apparent to a client who needs to decide whether the changes match the brief.

Interpret the no-tracking finding carefully

The current no-tracking finding uses two conditions: the account status indicates no tracking or the analysed action set is empty, and the collected channel metrics contain zero recorded conversions. It appears only when those conditions coincide. The implementation does not flag every low-conversion period as an absence of tracking.

Its recommendation explains that conversion tracking is a setup flow rather than a toggle. Adding an action and implementing its measurement requires more than changing an account boolean. The consultant should identify the intended event and implementation owner instead of presenting an automatic universal tracking fix.

A rejected collection must remain unavailable evidence. Do not use a failed request as proof that the account has no actions or no outcomes. The audit's section failure handling exists to separate unknown state from a measured finding. That distinction is important whenever an apparent absence could lead to a live configuration change.

Ask whether the zero-outcome period is representative of the client's operation. A newly launched campaign, a closed season or a temporary booking outage can explain a period without recorded outcomes. Those explanations need evidence or owner confirmation; they should not be invented. The useful question is what the available configuration and reporting jointly establish, rather than whether one zero cell can support a dramatic diagnosis.

A reported finding can still require business confirmation. The client may have a measurement process outside the selected scope, an account relationship requiring review or an outcome not represented by the analysed set. The next step is to establish the intended setup, not to claim that the business has never measured any result.

Review the ecommerce recommendation

The current ecommerce audit recommends one non-app web Purchase action as primary, with app-source handling separate. It also highlights primary non-purchase actions for review. That is the product's preferred ecommerce baseline, rather than a Google requirement that every business must have exactly one valuable outcome.

The card's explanation acknowledges that a booking, subscription start or other non-purchase action can carry real business value and remain primary. The consultant should confirm the client's intent before applying a recommendation that changes such an action. A default cannot replace the business meaning established in the brief.

Several Purchase actions do not, by their category names alone, prove that they record the same orders. They can represent different checkouts or services. Conversely, two sources can record the same underlying transaction. Investigate that distinction rather than treat the count of Purchase labels as a completed duplication diagnosis.

Keep reporting separate from remediation. When the client requests all primary purchase value, include the selected primary purchase actions as configured. When the client requests a role review, explain the baseline and the evidence for the proposed change. This lets the tool follow the report definition without silently imposing the audit's preferred configuration.

Understand the recommended action selection

The audit's recommendation algorithm uses source priority when choosing among web Purchase actions. A native Ads website source ranks ahead of Analytics, with other sources following. Within the best-ranked source group, recorded value can select a leading candidate. A tie leaves the choice for manual review.

That algorithm is a product heuristic, not a forensic test of event correctness. Higher recorded value can arise from a broader event definition or overlapping measurement as well as useful business activity. Source ranking also does not prove that the highest-ranked implementation is functioning perfectly on the client's website.

Use the recommendation as a review prompt. Confirm which action represents the intended purchase, whether distinct actions represent distinct outcomes and who maintains each source. A genuine tie should remain a decision for the owner rather than a reason to pick whichever action happens to appear first.

The card's per-item recommendations and bulk proposal should remain aligned. The consultant should inspect the actual listed changes, not approve a vague instruction to optimise conversions. A readable proposal names the actions staying primary and those changing role so the client can verify that legitimate outcomes are preserved.

Keep lead review connected to the client's process

The lead-generation audit uses manual review rather than the ecommerce purchase-selection rule. It lists primary and secondary roles so the business can confirm which actions matter. That reflects the variety of lead processes: one client uses a form enquiry, another a booked consultation, and another a later offline outcome.

For reporting, treat the client's primary lead categories together when the request is simply leads. Do not force a separate qualified-lead distinction solely because a provider category exists. If the client asks for a particular stage or action, resolve that explicit definition and report it accordingly.

Lead quality is an operational question. A form submission can be valid measurement while producing an enquiry the client cannot serve. Geographic fit, price expectations, availability and follow-up can all affect later outcomes. The conversion action's category does not prove which factor caused an unsuccessful enquiry.

The consultant should identify the outcome the business can interpret consistently. If confirmed jobs are available, use them for the corresponding question. If only raw enquiries are measured, name them as such. A more detailed action taxonomy is not a substitute for knowing what the current event actually represents.

Include calls and offline outcomes where relevant

A conversion review should not assume every useful outcome happens in a website form. Primary calls can contribute counts and assigned values, and offline conversion actions can be present in the account. The client may rely on those outcomes even when the visible landing page appears purchase-focused.

Read them when requested and distinguish their source and definition. A call action is not automatically a completed sale. An offline action can represent a later stage than the initial enquiry. The assistant should not invent a direct GA4 pairing for either simply because it can compare two numerical totals.

Editing eligibility is separate. The current locked-conversion policy refuses certain managed types and origins for role or counting changes. A readable action can therefore be relevant to a report while unavailable for the requested mutation. Explain the exact limitation rather than pretending the action does not exist.

A practical handover records which outcomes are available, which were included in the requested primary scope and which need another implementation owner. That prevents the consultant from completing a website-only review while leaving the client's main business conversion invisible in the explanation.

Keep counting policy distinct from event behavior

The audit reviews conversion counting separately from roles. Its current recommendation uses Many per click for Purchase, Add to cart and Begin checkout categories, and One per click for other recognised counting settings. That is the product's default review policy, not a replacement for the client's outcome definition.

A counting setting does not prove how many times the website fires an event. An event can be implemented incorrectly, or several actions can record overlapping outcomes, even when each action's counting type matches the recommendation. Inspect the implementation when the client's concern is duplicate event behavior.

Likewise, a role change does not correct counting. Making an action secondary changes its role, while One or Many changes how the action counts within its configured measurement. A request to change both needs two clearly described effects rather than an ambiguous instruction to fix the conversion.

The consultant should retain evidence of the old and proposed counting policy for each selected action. If an action is locked or unsupported for mutation, explain that limit before approval. The dedicated counting guide provides a related owner explanation without claiming that a preferred setting alone validates the event implementation.

Distinguish assigned value from purchase revenue

A conversion can carry a monetary value without being a purchase. A lead, call or subscription-related action can use an assigned amount. Standard Ads conversion value can therefore include primary non-purchase contributions. The consultant must identify the selected definition before calling the output revenue.

A purchase-only report should select the relevant purchase actions. An all-primary-value report can include other primary actions as requested. Multiple primary contributions are counted within that scope; the tool should not silently discard them to enforce a one-purchase recommendation during an unrelated report.

Default values and dynamic values have different implementation questions. A configured default can show what the action is instructed to use, while actual recorded values show measured output. Neither automatically proves product margins, correct currency handling or the meaning of every website event.

If value appears unexpectedly large, investigate the definition, source and implementation before estimating lost profit or duplicate sales. The audit can highlight a configuration concern, but a financial conclusion needs business evidence. An honest label for assigned value often prevents a misleading return calculation before any live edit is needed.

Investigate overlap with outcome evidence

Separate conversion actions can record the same underlying business outcome. The fact that both are primary means their selected measured contributions can be added in a primary-only report. It does not establish whether those contributions represent different sales or overlapping recordings of one sale.

A consultant reviewing overlap needs implementation or transaction evidence appropriate to the client's setup. Category names, source labels and similar totals can identify candidates for investigation, but they do not conclusively establish the relationship. Do not report proven duplication solely because two actions are called Purchase.

Reporting and correction remain different tasks. If the user asks for all primary conversions, answer from that configured scope. If the user asks to investigate overlap, collect the relevant evidence. If the user then requests a role change, prepare the exact proposal. That sequence preserves the client's intent at each stage.

A remediation plan should state which outcome will remain represented and why. Demoting an action without understanding what it records can remove a distinct valuable signal. The client should be able to review the selected actions and their intended business meanings, rather than approve a generic deduplication promise the tool cannot verify.

Check implementation without claiming it from a field

An enabled action is configuration evidence. It does not certify that the relevant website event fires correctly, that a form completes or that a booking reaches the expected destination. The consultant should distinguish field review from an implementation test in the engagement record.

Identify the actual customer journey. A public page can lead to a third-party calendar, a payment step or a callback. The intended conversion may occur later than the first landing page. Select the test path that represents the client's requested outcome rather than assuming that a successful page load proves the whole process.

Auto-tagging and parameter preservation are supporting questions, not universal fixes. The account flag can be verified independently, while redirects and event handling need their own evidence. The consultant auto-tagging guide explains those separate layers and their handover responsibilities.

Assign implementation work to the appropriate owner. A Google Ads action change cannot deploy the client's website tag or rewrite a booking platform. Record the observed issue and required correction, then verify through the relevant workflow. The consultant can make concrete progress without overstating what an Ads API mutation accomplished.

Separate enhanced-lead settings and consent

The audit reads enhanced conversions for leads and customer-data terms as separate settings. Its message distinguishes an off feature from unaccepted terms. A client should not be told to accept terms again merely because another measurement setting is disabled.

The current audit does not offer an automatic fix for this output-only account setting. It explains that enabling the feature is only part of the setup and that the relevant tag or upload must also supply the required data. Human acceptance of data terms is not an action the assistant can silently perform.

Do not interpret an on flag as proof of recovered leads. The implementation and intended data flow need evidence, and a recent performance change can have several causes. The consultant should identify which state was read and which implementation task remains rather than promise a measured recovery amount.

Keep any implementation discussion at the appropriate level for the audience. The client needs to know which step requires their approval and which technical owner must test the data flow. They do not need personal customer values pasted into Slack as an example. The consultant can describe the required evidence and the observed result while preserving sensitive implementation material in its proper operational context.

This separation is useful in a handover. The account owner handles the required acceptance or UI setting, while the implementation owner establishes the supported data flow. The consultant can coordinate those responsibilities without turning a consent-related review into an unapproved automated mutation.

Select the corresponding GA4 event

A meaningful Ads and GA4 lead comparison needs the corresponding event selected. The assistant can inspect available event names and suggest the likely match, but it should ask the client to confirm when naming alone leaves the business meaning unclear. A universal assumption that every site uses the same lead event is unreliable.

A named action can be compared with a specific GA4 event when the user supplies both. “Contact Form” versus “form_submit_contact” is a clearer definition than total conversions versus an unspecified website event. Retain the selected names and traffic scope throughout the output.

Total primary conversions can also be compared with the selected total key-event measure when that is the requested aggregate. The assistant should not silently substitute purchases or leads. The compatible comparison framework needs to preserve the metric definition instead of choosing a pair based only on a familiar name.

Revenue comparisons need accurate labels. Standard Ads conversion value and GA4 purchase revenue can be deliberately compared while remaining different definitions. All-traffic GA4 revenue divided by advertising cost is blended ROAS or MER. State that broader scope when requested rather than present it as a Google-Ads-only return measure.

Use comparable periods and exact conditions

A current action read establishes configuration now, while historical performance measures activity over a date range. The current role cannot reconstruct every setting during the last month. If a role changed midway through the period, interpret the report with that timing in view.

Last thirty days and last month are distinct periods. Use the account time zone and actual requested boundaries, and avoid silently excluding recent dates. Delayed outcomes or imports can affect recent measurements, so the client should know when the period remains immature for the intended business process.

Conditions need their exact operators. Value above a threshold differs from value at least that threshold. AND and OR produce different populations. Undefined CPA or unavailable data should not be converted into zero to make a filter work. These rules belong in the shared reporting framework rather than a patch for one conversion question.

State ranking and preview scope. A count of matching actions differs from a limited list of examples. A low-volume action can have a fragile ratio without being invalid. Use the relevant evidence and business meaning to decide the next step instead of treating every sorted report as an automatic change request.

Display precision should not change the calculation. Fractional conversion credit can appear in provider reporting, so a displayed conversion count need not be a whole number. Retain the underlying measures for ratios and conditions, then format the output for readers. Rounding every action before summing can create a different total, especially when the account contains several low-volume contributions. A readable response and an accurate calculation can coexist without exposing six-decimal figures.

Follow an illustrative mixed-business review

This situation is invented. Consultant Theo Reed reviews Wren Workshop Supply, a business selling materials and taking repair enquiries. The client asks what its account measures and whether both purposes remain visible. Theo starts with the action definitions rather than applying a retail-only policy to every conversion.

Imagine two primary purchase actions representing distinct checkouts, with recorded values of 800 and 300. A primary repair enquiry action carries assigned value of 100, while a secondary brochure action carries value of 40. The selected all-primary-value total is 1,200, and the selected purchase-only total is 1,100. The secondary brochure value is outside the primary-only result.

Those totals do not establish a duplication problem. The client confirms that the two purchase actions represent different checkouts. The ecommerce audit baseline can still prompt a role review, but Theo should not demote a distinct outcome solely to satisfy a one-action preference. The enquiry's assigned value also should not be called product sales.

The client later requests a change to one named action after reviewing its purpose. Theo prepares that exact role proposal, waits for confirmation and verifies the resulting state. The handover preserves the business definitions and change date. The example illustrates deliberate reporting and approval, not actual customer data or guaranteed performance improvement.

If the client then asks for a purchase ROAS example using cost of 250, the selected purchase value of 1,100 gives 4.40. Using all-primary assigned value of 1,200 gives 4.80 instead. Both divisions can be calculated, but they answer different questions. The latter must not be called purchase-only ROAS because it includes the repair enquiry's assigned value. Clear selection prevents a small naming error from turning into a misleading performance conclusion.

Use Slack context and narrow evidence reads

A consultant can ask for the action inventory, then follow up with the same action's role or a comparison over another period. The assistant should retain the resolved account and names where appropriate. It should clarify genuine ambiguity rather than repeatedly ask for information already established in the conversation.

A presentation-only follow-up can reuse measured rows. A changed date range, new conversion selection or current-state question may need another read. Preparation for a live edit needs fresh relevant configuration because another person could have changed it. Those are specific reasons for requests, not a mandate to reread the whole account for every reply.

Creative or explanatory tasks can stay conversational. Drafting a client explanation, suggesting a form instruction or outlining questions for the developer does not automatically need keyword research or a performance call. Use confirmed context without inventing event behavior or unsupported product claims.

A reusable framework can discover local field capability and dependencies, then request the evidence needed for the actual task. That keeps the experience maintainable and avoids unnecessary provider, storage or model work. Client replies should focus on the answer, not expose internal query syntax or routing decisions.

Present measured comparisons clearly

A conversion inventory can use a concise table showing names, selected roles and relevant definitions. A chart needs measured values and the requested date segmentation. Configuration fields alone do not supply daily counts, and aggregate totals must not be copied across dates to create a synthetic trend.

The app limits chart metrics or segments to three for readability. Use one compatible chart for two or three requested measures where possible. If the user requests more, explain the limit and ask for a choice. Do not silently omit a series or split each metric by default.

Native Slack charts allow twenty points per series in this workflow. A longer period without explicit daily detail can use a stated weekly or monthly breakdown. Explicit daily requests beyond that limit need split native charts and an explanation. Do not substitute an image or discard dates without the requested basis.

Use readable dates and no more than two displayed decimal places. Recompute grouped ratios from summed base metrics. Put the user's mention before the feedback section so feedback remains last. A clear caption states the event, period and scope without a technical dump of provider metadata.

Discover supported edits and real dependencies

The requested effect determines the resource and operation. A conversion-role change, counting update, campaign-goal edit and website implementation are different tasks. The shared capability catalogue and dependency metadata should identify the valid target and fields rather than route every request through one generic tracking toggle.

Local structural definitions do not require a provider call merely to learn a parent relationship. Actual current actions, ownership and settings do need narrow evidence when they are prerequisites. This distinction reduces unnecessary requests without replacing live state with assumptions.

The focused role and counting builder checks the locked-conversion policy before mutation. Managed origins and read-only types can be visible while unavailable for that edit. Explain the specific restriction and preserve the account rather than preparing an invalid request because the action appeared in a report.

When dependencies exist, prepare them in the correct order through the framework. Do not request unrelated campaigns or assets for an action that belongs directly to a conversion resource. The proposal should describe the business effect clearly while the execution tool handles supported field names, ownership and verification checks behind the scenes.

Confirm exact steps before changing signals

A role change affects the intended measurement configuration and needs a reviewable proposal. Show the action name, current role and proposed role on clear separate rows. If a campaign-goal change is also requested, show its distinct target and effect instead of hiding it inside a wall of tracking terminology.

One confirmation can cover a supported sequence with every action clearly described. If the complete instruction needs narrower proposals for safe review, explain that requirement before writing. Do not apply an arbitrary subset and omit the rest. The client should approve the complete listed scope of the request being executed.

State “No changes have been made yet. This proposal expires in 15 minutes.” Only Confirm and Execute authorises that presented live edit. The earlier audit request or an unapproved recommendation does not cross the write boundary.

After the click, make the proposal controls inactive and show prominent progress immediately without mentioning the user. Recheck current settings and validate the prepared request before execution. These steps protect against stale context while clearly showing the client that confirmation registered.

Verify the result and hand over remaining work

The final result should prominently show execution and verification, then describe the actual changed action or goal using readable names. Internal identifiers and fictional parent chains do not belong in the client output. The client needs the precise effect and whether it was independently established.

Validation checks the prepared request, while verification reads the resulting state after the write. A successful configuration read does not prove that a website event works or that future bidding will improve. Keep the engagement's separate implementation and business checks visible in the handover.

If a sequence is partly verified or a write is ambiguous, reconcile the affected resources before repeating operations. Report established steps and remaining uncertainty rather than claiming complete success. Blind replay can create or remove resources again without solving the original evidence problem.

Record the verified configuration, application date, intended outcome and remaining owner task. The consultant audit guide provides broader review context. A useful conversion audit gives the client an honest measurement definition, a deliberate approved change where needed and a clear boundary between provider settings and the implementation work still required.

Leave the next consultant enough context to avoid undoing a deliberate choice. If a non-purchase action remains primary because it represents a separate valuable service, record that reason. If a tied purchase recommendation was left for manual review, preserve the unresolved choice rather than describe it as completed cleanup. A good handover makes the state understandable and keeps future work aligned with the client's actual measurement brief.