Google Ads conversion-tracking audits for agencies: establish the client's outcome signals and review exact corrections

Define the client's measurement brief

A conversion-tracking audit should begin with the outcomes the client actually values. A store may focus on purchases, a service business on enquiries and a course provider on paid enrolments. The agency needs that brief before interpreting a list of configured actions as suitable or unsuitable.

Clarify which stages the client wants observed and which stages should guide the advertising decision. A form submission, qualified enquiry and completed sale can all have business meaning while representing different points in the same journey. The agency should not collapse them into one outcome without the client's direction.

The account evidence establishes configuration and reported activity. The client supplies the business interpretation and any downstream facts unavailable in the advertising account. Both are necessary for a useful recommendation. A category name or action label is not proof of the organisation's operational definition.

Keep the engagement scope explicit. The audit can identify supported configuration concerns and prepare eligible exact corrections. Website tags, CRM imports and consent responsibilities can require another owner. A passing account card should not become a claim that the agency has tested every part of the measurement chain.

Read the no-tracking finding accurately

The current audit raises its no-conversion-tracking finding when the account is not marked conversion-tracked or has no configured actions, and the selected account performance records no conversions. These conditions matter. The finding is not a universal diagnosis produced whenever one campaign has a quiet day.

The selected performance evidence has its own reporting scope. Zero recorded conversions in that evidence does not establish that the client has never made a sale or received an enquiry. The agency should describe the account observation and ask for the business context needed to understand it.

The finding has no simple fix toggle. Establishing conversion tracking is a setup flow involving an appropriate action and its implementation. The assistant should not invent a button that creates and deploys a complete tracking system from the absence finding alone.

Unavailable evidence is different from established absence. A failed action or performance read cannot be silently treated as an empty inventory and zero conversions. Preserve the audit's read and completion limitations so the client understands which facts were actually established.

If the account already reports outcomes, investigate the client's specific concern rather than announce that all tracking is missing. The useful next question may involve action roles, event quality or a reporting mismatch. That focused question determines which additional evidence is justified.

Establish the action inventory

Review the relevant enabled conversion actions and their available names, categories, sources, roles and counting settings. These fields help the agency understand what the account is configured to measure, while preserving the difference between a configured action and a confirmed event implementation.

Names can be reused or misleading. A conversion called Purchase may have a different category or source, while an internal action name may not make sense to the client. Use the actual fields and recognisable business context when explaining the inventory.

The current setup analyser excludes locked types from its editable recommendation population. That does not mean those actions cease to exist for all reporting purposes. Keep the audit's eligible recommendation set distinct from a broader request to list account outcomes.

A short preview is not the full inventory. If the reply displays examples, state the complete established count separately where appropriate and retain any coverage limitation. Do not present a capped response as a definitive total across the account.

Historical and current scope can differ. An action no longer enabled may have contributed to an earlier report. The current configuration list does not automatically reconcile every historical result. Use the requested dates and status population for the actual reporting question.

Separate primary and secondary roles

Google's primary and secondary action guidance explains their reporting and optimisation roles and notes the custom-goal exception. The client should understand the applicable goal context before an agency changes a role.

The application's primary-only conversational measurements deliberately retain the selected primary population. Secondary actions should not be silently added to a request for primary conversions simply because they appear elsewhere in provider reporting. Keep the requested definition identifiable.

Changing a role is a business decision about the account's intended signals. It does not prove that the underlying event fires correctly, represents a unique customer or has a valid commercial value. Those facts need their own evidence.

The agency can recommend a supported role correction after understanding the client brief. The connected owner must still review the exact actions affected. A broad instruction to clean up tracking should not become unannounced changes to every primary action.

Retain legitimate exceptions. A non-purchase action can have genuine business value even in a store account. An audit recommendation should be interpreted under its assumptions rather than treated as a prohibition on every alternative measurement strategy.

Understand the ecommerce recommendation

The ecommerce setup check recommends a single web purchase primary and reviews other primary actions against that default. It is a configuration heuristic for the audit, not proof that any two purchase actions necessarily record the same transaction.

Where a purchase selection is needed, the current analyser ranks available sources, favouring the native Ads website source ahead of analytics and other sources. Within the best-source group, recorded value can resolve the recommendation; a tie requires manual review. These are explicit product rules, not independent validation of implementation quality.

The audit preserves an existing single web purchase primary rather than silently replacing it just because another action has an attractive name. App-origin purchase actions have their own handling. The agency should review the actual eligible population and business arrangement before proposing a correction.

A genuine non-purchase primary can be intentional. The client may value a booking, subscription start or another commercial outcome. The recommendation should explain that business exception instead of representing the default as a universal provider requirement.

The reporting tools still count the requested primary actions as configured. They do not repair duplication or rewrite the conversion setup before answering a performance question. Keep audit advice and measurement output separate so the agency does not change the client's facts merely to make a report fit a preferred heuristic.

Preserve the lead business's definitions

Lead businesses can have several meaningful enquiry actions. A form, call and later imported stage may represent related but distinct business outcomes. The agency should obtain the client's intended relationship before recommending which actions should remain primary.

Different lead categories are treated as leads in the requested aggregate rather than inventing separate business-quality tiers from category names. A qualified-lead label does not prove that this client uses a particular operational standard. The source field describes configuration, while the business supplies the meaning.

If the client asks for a named action, use that exact action's available reporting evidence. If the client asks to compare it with analytics, a corresponding event must be selected deliberately. The assistant can help discover plausible names where the current tool supports that flow, but should not silently confirm equivalence.

Call and offline stages can overlap with another lead population. Do not add every displayed count as though each represents a different customer. Explain the requested aggregation and retain the distinction between outcome occurrences and unique people.

Any role correction needs the actual business instruction and eligible action target. The client brief is more important than applying the ecommerce purchase heuristic to a service account with different goals.

Review counting as a separate setting

The current counting recommendation uses many per click for purchase, add-to-cart and begin-checkout categories, and one per click for other eligible categories. That rule is visible in the audit and can produce supported individual or bulk corrections.

Counting and primary role are separate fields. An action can have the desired role while using a counting option the agency wants to review. Changing one should not silently change the other. The proposal must describe the exact field effect.

The recommendation also does not deduplicate separate action implementations. If two actions record the same business event, changing their counting options is not proof that the duplicate event issue has been repaired. The relevant implementation evidence remains necessary.

Bulk work needs a complete readable target list and the current eligible scope. The owner should understand which actions receive which setting, including legitimate exceptions the business wants retained. A generic Fix All label is not a substitute for reviewing the actual effect.

After execution, field verification establishes the supported counting change. Later outcome quality and comparability require their own observation. Keep the technical correction distinct from any claim that the client now measures unique leads or orders perfectly.

Interpret conversion value without relabelling it

All-primary conversion value can include value assigned to non-purchase actions. The agency should not automatically call that total purchase revenue. Purchase-only value selects a narrower population, while a client's commercial sales ledger can have another scope entirely.

The ecommerce value-risk audit flags several value-carrying purchase primaries and eligible non-purchase primary actions carrying value outside fixed-default handling. Those configuration facts support review under the audit's ecommerce assumptions. They do not independently prove that every flagged action records the same order.

Lead businesses can deliberately assign values to several actions. The audit's ecommerce-only check should not be applied as a universal rule that lead value is invalid. Obtain the client's intended scoring or commercial interpretation before proposing any role correction.

A named action's reported value is another useful view when the user asks about a particular outcome. Keep the source, selected dates and role scope explicit. A concise report can show what was actually measured without treating every currency-denominated value as realised cash revenue.

The assistant should report the configured primary population faithfully. It should not silently remove actions from a performance answer because an audit heuristic recommends reviewing them. Advice about setup and the actual requested account measurement remain separate.

Separate summed actions and duplicate implementation

When several primary actions fall within the requested population, the reporting tool adds their recorded results. If two separate actions recorded the same purchase, both recorded values can enter the total. The reporting request does not repair the underlying implementation automatically.

That behaviour is appropriate for a question about the account's configured primary conversions. The agency can separately investigate whether the actions represent distinct outcomes or duplicate recording. It should not change the meaning of the report before the client has made that setup decision.

A category, source or similar name can identify a possible duplication risk. It is not sufficient evidence that two records represent the same transaction. Obtain the relevant event, import or transaction evidence when the client asks for that diagnosis.

Changing a role can alter the selected primary population, but it does not delete historical records or fix a website that sends duplicate events. The proposal should describe its actual configuration effect. Avoid saying duplicates were removed when the operation only changed an action's role.

Keep implementation repair, account configuration and later reporting comparability distinct in the client handoff. Each can be necessary, and each requires its own evidence of completion.

Keep call and offline outcomes available

Call conversions can be included in the appropriate primary-only outputs and can carry value. A click on a phone link is not automatically the same measurement as a recorded call action. Establish the client's actual action definition before explaining a count or value.

Offline conversion actions are available as account outcomes where the relevant evidence is exposed. The assistant can list and inspect them under the supported reporting framework. An offline source does not require an automatic GA4 pairing to be useful.

These outcomes can overlap with other aggregates. An offline qualified stage may relate to an earlier lead, and a primary call can already be included in all-primary conversions. Do not add those totals together as if every displayed category contained separate people.

The configured action does not establish that every expected import arrived. A missing CRM upload or delayed business process needs the relevant owner and diagnostic evidence. The agency should not infer complete import health merely because the conversion action exists and is enabled.

When the client asks for a specific offline or call action, use its actual name and available fields. Keep the requested scope precise rather than forcing the question into a purchase-only reporting template.

Read enhanced-lead and terms signals independently

The enhanced-conversions-for-leads audit displays two separate signals: whether the account setting is enabled and whether the customer data terms are accepted. One can be true while the other is false. The summary should retain that distinction rather than tell every client to accept terms again.

This is an informational setup check, not a complete proof that the implementation sends the required data. The account setting can be enabled while the client's tag or upload arrangement remains unfinished. The agency needs the implementation owner's evidence for that stage.

The current audit has no automatic fix for the output-only customer tracking message or human acceptance of terms. It directs the user to the appropriate account setup. The assistant should not promise to accept a business consent on the owner's behalf.

Keep this topic distinct from ordinary website conversion tracking and from a counting correction. They can appear in the same audit section while requiring different actions. A verified counting update does not establish enhanced-lead readiness.

Assign the missing stage accurately. If the terms are already accepted, the next setup discussion differs from a case where acceptance is absent. A specific handoff avoids sending the client through an unnecessary or inappropriate step.

Respect locked and unavailable operations

Some conversion types and origins are excluded from editable recommendations. The policy includes Google-hosted, YouTube-hosted, Smart-campaign and other declared locked types. These conditions come from actual fields rather than guessing editability from the action's display name.

A locked action can still matter to the client's understanding of reported outcomes. Keep visibility and editability separate. The assistant should not hide relevant reporting facts simply because a role correction is unavailable through the current path.

The convenience catalogue has no universal conversion-creation adapter. Existing eligible actions can support specific role and counting edits, while setting up a completely new measurement arrangement can require Google Ads and implementation work. Declared API capabilities still need their actual runtime constraints checked.

Do not substitute another editable action for the locked target without instruction. A technically valid mutation on the wrong action would not satisfy the client's request. Explain the limitation and obtain the appropriate supported next step.

The owner should understand whether the proposal changes an existing field, creates a resource or requires manual setup elsewhere. These are different effects, and the user-facing description must match the actual operation.

Assign the actual implementation work

Website event implementation, analytics collection and CRM imports can belong to different client suppliers. The advertising agency should identify who controls each required stage before reporting that tracking is fixed.

Give the responsible owner a concrete task and relevant scope. A website developer needs the intended customer action and route; an analytics owner needs the selected property and event; an import owner needs the expected business stage. A generic instruction to repair conversions leaves too much interpretation.

A controlled implementation test has its own evidence and authorisation. The account audit is not proof that someone submitted the client's live form or completed checkout. Do not invent those tests in the report, and do not perform consequential customer actions merely to make a configuration card look verified.

Privacy and business consent decisions remain with the responsible organisation. The assistant can identify a missing setup stage without assuming permission to supply customer data or accept terms.

Close each task according to its actual evidence. An action-role update, website event test and successful import observation can occur at different times. The agency handoff should preserve that sequence rather than collapse all work into one green status.

Match analytics events deliberately

A comparison with GA4 needs the relevant property, metric definition and event selection. All-primary Ads conversions can be compared with the selected total key-event population under the supported scope. A lead-specific or named-action comparison needs a confirmed corresponding event.

The assistant can inspect available event names and suggest plausible candidates where the released capability supports discovery. A name such as form_submit_contact can be a useful clue. The client still confirms that it corresponds to the intended Ads action rather than another form or business stage.

Current release gates matter. A planned named-event comparison should not be promised when that path is unavailable in the deployed tool. The assistant can explain the actual limitation and show independently available evidence without inventing a combined result.

Revenue comparisons also need definitions. Ads all-primary value and GA4 purchase revenue can be displayed as distinct compatible series, but they should not be summed as separate revenue streams. The same underlying activity can contribute to both systems.

Keep traffic scope explicit. All-traffic purchase revenue divided by selected advertising spend is blended ROAS or MER, rather than a claim that every purchase came from Google Ads. The client's question determines the appropriate numerator and spend scope.

Review an invented agency client case

Consider an invented agency, Laurel Coast Media, working with an invented client called Birch Hall Classes. The current eligible action inventory includes two web purchase actions and a valued enquiry action. The client supplies its intended reporting and business definitions before the agency interprets the audit recommendations.

The ecommerce audit identifies the purchase-role situation and the non-purchase value concern under its default assumptions. The agency does not announce that it has proved duplicate orders. It obtains the implementation context and asks which outcomes the client intends to keep in its primary population.

The client confirms a supported exact role correction for one eligible existing action. The proposal names that action and its current and intended role. It does not silently change counting, remove the action or rewrite the website event.

After confirmation, the technical outcome closes the role-update task. The agency retains the separate implementation investigation and notes that later primary-only reports use the revised population. This preserves both faithful reporting and accountable correction.

The example illustrates a decision process, not a real customer result. It shows why an agency needs business context and exact supported effects rather than applying every audit heuristic as an automatic global repair.

Prepare the exact supported correction

Resolve the requested existing action and its current eligible settings before preparing a role or counting edit. The target must belong to the selected account and satisfy the applicable locked-conversion policy.

The proposal should describe the exact field effect. Setting an action secondary differs from disabling it, removing it or changing its counting option. Keep those effects distinct in both the internal request and ordinary user wording.

Bulk role requests must identify every intended target and which actions remain primary. The shared builder requires declared primary targets to belong to the explicit target set. This prevents a partial list from implying an unintended account-wide role rewrite.

Local capability discovery can identify the required conversion target and parameters without campaign enumeration. Current action evidence and ownership remain necessary. The framework should use each source for its actual purpose.

If the complete requested effect cannot be prepared, explain the practical limitation before execution. Do not apply a convenient subset and report that the whole measurement request was completed.

Review readable steps before approval

The confirmation card should name each affected action and describe its role or counting change in a separate readable step. The client should not need raw provider payloads to understand the intended outcome.

Internal resource references remain available for exact execution, while user-facing output uses recognisable names and relevant scope. Do not append every conversion ID or expose an owner email to make a simple proposal look technical.

No live change occurs during preparation. The connected owner uses Confirm and Execute for the reviewed proposal, which has a limited pending lifetime. Cancel applies to pending work rather than reversing a provider change already accepted.

The actor, account and original message checks protect the interaction. Participation in the channel or receiving a forwarded card does not grant execution authority.

After approval, a visible progress state acknowledges that the request is underway. The final receipt should account for each supported step and distinguish technical completion from the client's remaining implementation work.

Distinguish current checks and outcome verification

Current-setting checks protect the prepared effect when another operator has changed the action during the conversation. A relevant mismatch should stop a stale proposal and prompt a fresh review.

Supported provider validation can identify request problems before the live write. It does not independently establish website event quality or the business appropriateness of the selected primary population.

Post-submission verification establishes the supported account result. A provider acknowledgement without complete independent verification needs its own accurate status rather than an exaggerated verified claim.

These stages answer different questions. The agency can explain them plainly while keeping the checks proportional to the exact action. Repeating unrelated campaign performance calls does not provide the same protection.

A verified field correction remains a technical milestone. The client still needs the later implementation and reporting evidence relevant to the original measurement concern.

Reconcile an uncertain submitted edit

A dispatched request can apply even when the final response is unavailable. Do not automatically repeat the role or counting mutation to obtain a cleaner completion message.

Inspect the relevant current action fields and stored execution outcome. A focused reconciliation establishes whether the intended configuration is present without restarting the entire audit.

Message delivery recovery should report stored state. It should not submit another provider mutation because the owner did not see a final Slack reply.

Keep pending, failed-before-dispatch and uncertain-after-dispatch states distinguishable. The next agency operator needs to know which applies before preparing another live request.

If the actual result remains unresolved, say so and identify the required check. An unsupported success statement is worse than a clear account of the remaining evidence.

Continue the measurement conversation in Slack

The assistant can retain the established client account, action and business question through follow-up messages. A reference to the action just discussed should not trigger unnecessary campaign clarification.

Context still does not replace fresh current-setting checks for a live correction. The conversation preserves intent, while the tool protects actual account state.

Creative wording assistance can use the supplied evidence without another API call. Drafting a client explanation or an implementation handoff differs from retrieving current action metrics.

Ordinary replies place the user mention before the feedback footer, with feedback last. Progress and execution use their own visible status treatment. This makes the stage of work recognisable.

Clarifications should identify the real missing prerequisite politely. An unavailable property or ambiguous action is not a reason to invent metrics, blame the client or redirect the request into unrelated drafting features.

Keep client reports comparable

For a client reconciliation, begin with a definition sheet rather than a request for two unexplained totals. Record what each system counts, the selected dates, account timezone, action population and traffic scope. The agency can then identify a real discrepancy between comparable evidence or explain why the original numbers were answering different questions. This is more useful than repeatedly changing a report until two values happen to look closer.

For example, a purchase-only report should retain its purchase selection when it is compared with another purchase measure. If the client instead requests all primary value, include the configured eligible primary population even when some actions are non-purchase. The user has changed the question, and the answer should change with it. A hidden purchase-only filter would misrepresent the requested account total.

Keep aggregate ratios based on their underlying totals. Combining campaign return figures requires the summed selected value and summed cost, rather than an unweighted average of displayed campaign ratios. The same principle applies when the agency groups a time series into weeks or months. A readable chart should preserve the metric's definition, not merely compress its labels.

Unknown and undefined values also need accurate treatment. Missing source evidence is not zero, and a ratio with no valid denominator should not be rendered as a confident performance value. The assistant can explain why a particular comparison is unavailable while still presenting the established components. This prevents a client from making a configuration decision based on a cosmetically complete but unsupported report.

When a follow-up asks for a chart, reuse the compatible returned dataset where possible and retain the requested segmentation. Ordinary native Slack output should aim for one readable chart with an appropriate coarser period when daily detail was not explicit. If explicit daily detail requires a supported split, explain it. Do not silently transform the request or substitute an image chart.

Report the selected outcome population and date scope. All-primary conversions, primary purchases and primary leads answer different questions, even when the client uses one casual word for all of them.

A role correction changes the population used by later primary-only reporting. Retain that definition change in a before-and-after discussion rather than attributing every movement to campaign performance.

Use the available supported date basis consistently. A conversion-date view and an interaction-date view can distribute outcomes differently. The report should preserve the requested basis and explain it when it matters.

A client summary can state the verified configuration effect and list remaining implementation checks. It should not expose raw query traces or claim recovered revenue without measured evidence.

Connect the audit with agency reporting. Consistent definitions make the configuration discussion and later performance report understandable together.

Use focused reusable evidence

Local capability discovery establishes which target and parameters a correction needs. It does not require retrieving every campaign for an account conversion-action question.

Reuse compatible returned action evidence for the explanation and proposal preparation. Required fresh checks still protect execution, while an identical repeated inventory read merely adds latency when its facts remain suitable for the current analysis.

Additional reporting should follow the actual question. A named-action metric needs focused evidence; a creative client explanation can remain conversational. Do not turn every wording request into a new research job.

Coverage remains essential. A capped preview cannot establish a complete action total, and a failed read cannot become an empty successful population. Efficiency does not justify unsupported aggregate claims.

Keep recovery proportional: bounded safe read retries, focused uncertain-write reconciliation and stored-state message recovery serve different purposes. This preserves both rate capacity and the approved effect across busy client conversations.

Leave a complete measurement handoff

Include the expected next observation date when the task needs later data. That gives the client a concrete continuation point without promising an automatic repair or a guaranteed business result.

A client takeover should distinguish work that the agency observed from work another supplier reported. If the website contractor says an event is installed, record that supplied statement and any actual test evidence separately. The advertising account's enabled action can support the configuration review without certifying the contractor's implementation. This makes the handoff honest and gives the next operator a concrete check to complete.

Retain the relationship between a business stage and its reporting name. A client may rename an action or use an internal acronym that does not describe its customer meaning. The handoff can explain that mapping while the tool keeps the actual resource reference internally. Ordinary client messages do not need raw identifiers, but the account workflow still needs exact identity to avoid editing a similarly named action.

Review changes in the client's operating process. A new CRM stage, replacement contact form or revised checkout can alter the intended measurement while the old action remains visible. The agency should ask which business event now matters and establish current implementation evidence. Simply keeping last quarter's primary-role plan may no longer reflect the client's actual journey.

Define the next responsible decision after an uncertain outcome. The handoff should identify the field or resource to reconcile and state that a dispatched edit must not be repeated blindly. Another colleague can then continue safely without treating an absent Slack receipt as evidence that no account operation occurred.

Keep final closure proportional to the original scope. A role correction can be complete while a wider implementation investigation remains open. A client can receive a concise update naming that completed effect and the remaining owner. This communicates real progress without either overstating tracking health or discarding useful work because every stage has not finished together.

Record the client account, business definitions, observed action configuration, intended correction and actual outcome. Add the owners for unresolved website, analytics and import tasks.

Retain audit assumptions and intentional exceptions. A client-specific primary arrangement should not become an automatic rule for another account merely because the same agency manages both.

Keep implementation evidence separate from configuration receipts. Another operator should be able to identify which events were actually checked and which fields were simply read or changed.

When testing finds a known defect, resolve it before continuing dependent checks and update the relevant documentation with the verified correction and remaining limits. Do not let an unresolved implementation issue disappear behind a passing setup card.

Use the original conversion-tracking guide and the broader agency audit routine alongside this handoff. The focused mechanics and client responsibilities support the same accountable decision.

Answer agency conversion-audit questions

Does a configured action prove its event works?

No. Configuration and implementation evidence answer different questions.

Does the report exclude extra primary actions automatically?

No. It counts the requested configured primary population. A setup correction is a separate reviewed decision.

Does one per click repair duplicate event implementation?

No. Counting is a field setting; duplicate implementation needs its own evidence and repair.

Can every action's role be edited?

No. Declared locked types, origins and current operation constraints apply.

Can the tool accept data terms automatically?

No. Human acceptance and the appropriate account setup remain separate responsibilities.

Can a lead action be compared with a specific GA4 event?

The corresponding event must be selected and the released comparison capability must be available. A plausible name alone is not confirmation.

Does verified execution establish tracking quality?

It establishes the supported technical correction. Later implementation and reporting checks remain necessary for broader claims.