Google Ads conversion-counting audits for agencies: review action-level choices before changing the client's reports

Define the client's counting question

A counting audit should begin with the business question the client wants its advertising reports to answer. The agency may be reviewing repeated sales, repeated enquiries or the relationship between a funnel action and a final outcome. These questions can involve the same setting while needing different commercial interpretations.

Ask what the configured action represents. A label such as Registration can describe a valuable completed booking, an early enquiry or a low-value account creation. The category and setting are provider facts, while the client's operating process supplies the business meaning.

The objective is a suitable action-level decision, not making every audit card green. A category-based recommendation can identify a setting worth reviewing, but the client may have a legitimate reason to retain an exception. The agency should understand and document that reason rather than overwrite it automatically.

Keep the correction scope explicit. A counting update changes a particular field on an eligible existing action. It does not create a new tracking implementation, change every goal or repair duplicate events. A useful engagement explains the exact supported effect and assigns any separate implementation work to its responsible owner.

The connected owner remains responsible for approving the live proposal. An agency discussion about best practice is not continuing permission to modify all client conversion actions whenever a recommendation appears.

Understand the provider counting choice

Google's counting-options guidance distinguishes counting every occurrence of an action after an interaction from counting one for that action. It also states that changes affect future reporting rather than rewriting the action's past data.

This setting is attached to the conversion action. The agency should not present it as a general account-wide deduplication mode or a promise to measure unique people across every customer interaction. The target and requested effect remain action-specific.

Use plain client language while preserving the field's meaning. A report can show the current counting option and the proposed alternative without exposing enum names in every sentence. The internal tool still uses the exact supported values to prepare a valid request.

The agency's interpretation should connect that technical choice to the client brief. The question is whether the option supports the intended outcome measurement, not whether one label sounds more conservative. A commercial decision needs the actual business process and available evidence.

A provider explanation and a client decision have different roles. The documentation defines the setting, while the organisation decides what its action should represent. Neither an account name nor the assistant's general preference can replace that decision.

Read the audit's actual recommendation

The current audit recommends many per click for purchase, add-to-cart and begin-checkout categories, and one per click for other recognised eligible categories. It compares the observed counting field with that declared product rule and lists mismatches for review.

The recommendation is category-based. It does not independently inspect the client's form, checkout or CRM workflow to determine what each repeated occurrence means. The agency should describe it as the audit's recommendation and obtain business context before treating every mismatch as a confirmed implementation defect.

A matching field produces a passing counting finding under the rule. That establishes configuration consistency within the selected population. It does not prove that conversion events are implemented correctly or that reported outcomes correspond to unique customers.

A mismatch produces an individual recommended change and a bulk-caution option. The owner needs to review the actual affected actions. A short count of items to fix is useful for triage but is not a substitute for understanding the requested effect on each action.

Unknown or unsupported counting values do not become a familiar alternative merely to make the recommendation complete. The current logic evaluates the recognised one and many options. Keep the eligible comparison scope identifiable when explaining the result.

Preserve the eligible action population

The relevant action inventory includes names, categories, types, origins and current counting settings. These fields establish which actions the agency is reviewing and which supported constraints apply. A display name alone is not enough to decide editability.

The bulk audit correction rereads enabled actions and excludes declared locked types and origins. That population differs from a request to list all historical conversion actions. Do not claim that the corrective batch covers every action that has ever contributed to a client report.

Keep action identity exact internally. Similar names can belong to different sources or business stages. The client-facing review can use recognisable names and relevant context while the execution tool retains the actual resource references.

A capped preview is not the complete count. If Slack shows examples, preserve the distinction between displayed rows and the full successfully established eligible result. If a read is incomplete, explain the missing coverage instead of reporting a definitive total.

Current enabled status does not reconstruct the client's entire measurement history. An action disabled today may have contributed earlier. The agency should use the appropriate current population for correction and the requested historical scope for reporting.

Check the business meaning behind a category

During onboarding, ask the client to describe the action in ordinary operational language. What happens after the enquiry arrives? Does another team merge repeated submissions? Does the same person legitimately buy separate items? Which result appears in the client's own sales report? These questions help the agency understand the intended measure without claiming that the audit has inspected those business systems.

Keep the answer tied to the named action. A client can have a contact form, quotation request and booking flow on the same site, each with a different purpose. A general statement that the company sells services does not resolve every action's counting decision. The agency should preserve the relevant mapping instead of applying one business label across the entire inventory.

When the client cannot yet confirm the meaning, hold the proposed correction rather than invent a preference. The agency can still show the established field and audit recommendation. The unresolved business decision belongs in the handoff with a named owner, so it does not disappear behind either a green card or a rushed account mutation.

A configured category describes the action's assigned type, not a complete account of the client's process. A purchase category can be wrong, a lead label can be imprecise and an internal name can hide an important distinction. The agency should confirm what the action actually represents.

Ask whether repeated occurrences are distinct useful outcomes or repeated signals from the same stage. That question can identify an implementation investigation or a legitimate business counting decision. It should not be answered solely from a field recommendation.

The client can explain an intentional exception. A service may accept several separate bookings from one advertising journey, while another treats repeated enquiries as one operational opportunity. These invented business possibilities illustrate why context matters; they do not establish the correct setting for a real client without its evidence.

Keep category correction separate from counting correction. If the assigned category itself needs review, identify the actual supported operation and constraints. Do not silently change a category while presenting the proposal as a counting update.

Document the client's decision and the agency's evidence. This makes future account takeovers more reliable and prevents another operator from undoing a justified exception simply because the default audit recommendation appears again.

Keep counting separate from primary role

Counting and primary role are independent configuration dimensions. A primary action can have either recognised counting option, and a secondary action can also have a counting setting. A request to change one field does not authorise changing the other.

The assistant's primary-only reports retain the requested configured primary population. An audit recommendation does not silently demote an action before answering a performance question. Reporting the existing account and proposing a correction are separate tasks.

If the client asks for both role and counting changes, represent both effects as explicit steps. The owner should see which action changes role and which changes counting. Do not hide a primary-population rewrite inside an explanation about repeated outcomes.

A suitable role arrangement can still have a counting issue under the audit's rule. Conversely, a matching counting option does not establish that the action belongs in the client's primary objective. The agency should investigate the dimension that actually matters to the question.

Keep legitimate business-value exceptions visible. A non-purchase primary can be intentional, and counting configuration does not determine its commercial validity. The client brief remains necessary for the broader measurement decision.

Distinguish counts and reported value

A count and its associated conversion value are different reported measures. Changing a counting option should be explained as the exact field effect, not a guaranteed correction to realised revenue. The actual value arrangement may require its own review.

All-primary value can include non-purchase actions. Purchase-only value is a narrower definition. When a client asks why its return measure changed, establish which population supplied the numerator instead of assuming every currency value represents an order.

Several primary actions can contribute recorded value to the requested total. The reporting tool does not remove one merely because the audit recommends reviewing its setup. The agency can investigate whether those actions represent distinct business outcomes or duplicate recording separately.

A fixed action value can have a deliberate lead-scoring purpose. It is not automatically cash revenue, and its presence is not proof of an error. The client needs a clear explanation of the chosen measure and any commercial assumptions behind it.

Do not promise that a counting correction will recover a specific amount of revenue. The audit reads configuration and prepares supported effects; the later commercial result requires actual evidence under the selected definition.

Investigate duplicate implementation separately

Duplicate event implementation is a different question from the action's counting field. A website can send repeated events, several actions can record the same business outcome or an import can repeat a record. The agency needs the relevant implementation evidence to identify which situation applies.

A similar name or shared category can suggest a review, but it does not prove that two recorded actions represent the same transaction. Avoid declaring duplicate orders from configuration alone. The client or implementation owner should supply the evidence needed for that conclusion.

When the user asks for the configured primary total, add the recorded primary population faithfully. If separate primary actions recorded the same outcome, both can enter that total. The report is not a hidden implementation repair service.

A counting change does not delete another action, merge records or rewrite event code. The proposal should preserve that boundary. If an implementation defect is found, assign its actual repair and verification instead of claiming the account field solved it.

Keep the follow-up measurable. The agency can establish the current field, the implementation owner's correction and the later observed event behaviour as separate milestones. This is more useful than one broad statement that duplicates are fixed.

Review the client's lead arrangement

Lead businesses often measure several stages of one customer journey. A form, call and later imported stage can each carry useful information while overlapping operationally. The agency should understand that relationship before interpreting aggregate counts.

Lead categories remain leads for the assistant's requested aggregate. The bot should not invent quality tiers from category names or assume every client uses the same qualification process. The actual business meaning comes from the client.

One action's matching counting option does not establish unique people across all lead actions. Several configured actions can contribute to the total. The report should identify its population rather than label every aggregate as deduplicated leads.

A named lead action can be inspected when the client asks about a specific form or stage. A comparison with GA4 requires a confirmed corresponding event and an available released comparison path. A plausible event name alone is not enough.

Keep the requested correction narrow. A counting review should not automatically disable calls, demote offline stages or rewrite the client's sales process. Those are separate business decisions with their own supported targets.

Review purchase and funnel actions

The audit groups purchase, add-to-cart and begin-checkout categories under its many-per-click recommendation. These actions can nevertheless represent different business stages. Their counts should not be added together as though every row were a separate completed sale.

Purchase-only reporting selects the appropriate category and requested role population. A broader conversion total can include funnel actions if they are primary. Establish that definition before describing a client result as orders.

The ecommerce primary-role heuristic is a separate review. It recommends one web purchase primary under its default assumptions, while legitimate client exceptions need context. Counting alignment does not settle that role decision.

A website implementation can need its own event-quality checks even when every eligible action matches the audit recommendation. The agency should not use a passing field comparison as evidence that cart, checkout and purchase signals occur at the correct points.

When a client requests several corrections, present the complete supported effect with clear steps. A purchase counting change, role update and website repair are different actions, and not all belong to one provider request.

Respect locked and unsupported targets

The shared locked-conversion policy uses type and origin fields. Google-hosted, YouTube-hosted, Smart-campaign and other declared locked types are excluded from the eligible convenience correction. The agency should not attempt to infer editability from friendly names.

Locked does not mean irrelevant to every report. Such actions can still matter to the client's understanding of outcomes. Keep visibility and mutation support separate when answering a question about the account.

A provider rejection can still occur for another operation-specific reason. The eligible local population is a necessary constraint, not a promise that every request will be accepted. Validation and the actual returned result remain important.

If the client names an unavailable target, explain the real limitation instead of selecting a different editable action. A technically valid update to the wrong resource would not satisfy the request.

The audit bulk action and conversational proposal have different execution paths. Their available verification and partial-outcome behaviour should be described according to the actual path, rather than making one universal claim about all counting edits.

Separate current settings and historical evidence

A current read establishes the action's present field. It does not prove that the same setting applied throughout an older performance period. Historical configuration claims need available change evidence or an accountable operator's supplied context.

Google's counting guidance states that a change applies to future reporting rather than the action's past data. Keep that boundary explicit when a client expects an old report to be rewritten after a correction.

An agency takeover should preserve the prior measurement arrangement and any known changes. A before-and-after report can otherwise attribute a definition movement to advertising performance. The account value and reporting context both matter.

Unavailable evidence is not a familiar field value. A failed read should not become a confident one-per-click or many-per-click statement. Retain the actual coverage limitation and obtain the focused next check.

Use the observation date and selected source when explaining a result. The client does not need internal retrieval traces, but the agency needs enough context to distinguish a current verification from a retained historical audit finding.

Follow an invented agency review

Consider an invented agency, Ash Coast Media, reviewing an invented client called Rowan Hall Learning. The eligible current inventory includes a purchase action and an enquiry action whose observed counting settings differ from the audit's category recommendations. These are illustrative facts, not a customer incident or claimed performance outcome.

The agency first confirms what the actions represent. The purchase belongs to the client's course checkout, while the enquiry belongs to a consultation form. The client supplies the intended business interpretation, and the agency keeps implementation quality as a separate question.

The assistant prepares two exact supported counting effects for the identified existing actions. It does not change their primary roles, delete either action or claim to repair the form's event implementation. The connected owner reviews the complete proposal with separate readable steps.

After execution, the technical result establishes the supported field outcomes. The agency notes the definition change for later reporting and retains any separate implementation follow-up. It does not claim that the historical report was rewritten or that unique customers have been deduplicated across the account.

This process gives the client a clear decision and evidence trail. The audit raised the configuration question, the client supplied the business meaning and the confirmed proposal defined the actual account correction.

Prepare an individual correction

Resolve the exact existing action and current eligible setting before preparing the individual edit. The action must belong to the selected account and satisfy the supported locked-conversion constraints. A name match without resource identity is not enough for execution.

The shared builder accepts the supported counting alternatives and describes the current-to-intended effect. It keeps role and counting separate. A request for one field should not silently add another measurement change.

The owner-facing proposal can use ordinary labels rather than raw enum values. The internal request still carries the exact field and valid value. This makes the result reviewable without sacrificing precision.

The older audit per-item action reports the provider mutation response, while the shared conversational workflow can include the relevant verification plan. Do not assume every visible button supplies identical independent evidence. Describe the actual result according to its execution path.

If the field already matches the intended effect, report the established state rather than force an unnecessary live mutation. The purpose is the client's correct configuration, not generating an execution message for its own sake.

Review bulk scope and partial outcomes

The audit's bulk correction reads enabled actions, removes declared locked targets and determines the mismatches under its category rule. It submits changes for that selected population and then rereads the relevant fields. This scope needs to remain visible in the agency explanation.

The current bulk path enables provider partial-failure handling. Some operations can apply while another is rejected. A single request therefore does not mean every action has an all-or-nothing outcome. The result must account for remaining mismatches rather than announcing universal completion from the initial response alone.

The reread supplies the current field evidence used by the bulk result. A reduction in mismatches is useful progress, while remaining actions need focused follow-up. Keep names and exact affected scope identifiable so the agency knows what still needs attention.

Business exceptions should be resolved before selecting a broad correction. If the client deliberately retains one alternative, the agency should prepare the appropriate explicit scope instead of applying a default batch and restoring the exception afterward.

A complete review also distinguishes the audit batch from a conversational grouped proposal. The actual builder and provider boundary determine submission behaviour. Do not promise atomic rollback across all counting paths because the owner used one confirmation.

Use local capability and dependency rules

Counting correction targets an existing conversion action. The local capability catalogue can determine the target kind and required parameter without first enumerating campaigns or ad groups. That conceptual discovery does not need a provider call.

The dependency framework treats conversion actions as existing eligible targets for the convenience catalogue. It does not invent a new action-creation adapter merely because a later counting effect is requested. A complete tracking setup still has its own required workflow.

Local rules also keep unrelated resource relationships out of the plan. The agency should not show an ad group as the conversion action's parent simply because another edit template uses ad-group context. The review scope must match the actual target.

Current ownership, action fields and operation constraints still require appropriate evidence. The local table explains how the request is structured; it cannot establish that the connected account is reachable or the prepared value remains current.

This reusable approach supports differently worded client requests while preserving the same target and validity rules. It avoids a dedicated handler for every phrase and reduces unnecessary account discovery.

Read the complete confirmation steps

The confirmation card should name each action and show its exact counting change on a separate readable line or step. The owner needs to understand the complete effect without decoding provider request syntax.

Keep raw conversion identifiers internal when recognisable names and context establish the review scope. Undefined parent values and irrelevant campaign relationships make the card harder to trust. The presentation should reflect the resource's actual hierarchy.

The pending proposal states that no changes have been made yet and that it expires in fifteen minutes. The connected owner uses Confirm and Execute for the reviewed effect. Cancel applies to pending work and does not reverse a dispatched mutation.

Actor, account and original-message binding protect the interaction. Seeing the card in a channel does not create approval authority. A forwarded message should not casually approve a different stored proposal.

If the request contains too many independent actions or cannot be prepared completely, explain the practical limitation and ask for a smaller coherent request. Do not apply only a convenient subset while presenting the original request as finished.

Distinguish validation and verification

Pre-execution checks establish ownership, relevant current state and operation eligibility. Supported provider validation can catch a request problem before the live write. These checks protect the prepared effect but do not decide the client's business definition.

If another operator changed the relevant field after preparation, a stale proposal needs a fresh review. The conversation's retained intent does not guarantee that the account state remained unchanged.

Post-submission verification establishes the supported result. The current field read can confirm the intended setting, while an unavailable response or readback can leave a different outcome. The final message should reflect the evidence actually obtained.

Provider acceptance without complete independent verification is distinct from verified completion. Preserve that status rather than using one success phrase for every path.

Technical verification does not prove event implementation or future commercial quality. The agency still needs the appropriate later evidence for those claims. Explain the boundary clearly when a client asks whether tracking is now fully fixed.

Reconcile a dispatched uncertain request

A dispatched request can apply even when its final response is unavailable. The assistant should not automatically repeat the counting mutation to produce a cleaner result message.

Use the stored execution and focused current action fields to establish what happened. A full account inventory or performance scan is unnecessary for reconciling one known field effect unless the actual question requires that broader evidence.

Message-delivery recovery should report stored state rather than submit another account write. An updated original card and thread receipt can be two surfaces of one operation.

Keep pending, failed-before-submission and uncertain-after-dispatch states distinguishable. Another agency operator needs that information before preparing a follow-up action.

If the result remains unresolved, state the missing evidence and next check. A precise uncertain status is more useful than an unsupported declaration that nothing happened or everything succeeded.

Continue the client discussion in Slack

The assistant can retain the established client account and action through follow-up messages. A request to change the action just discussed should not trigger irrelevant campaign clarification.

Conversational context preserves the business intention, while current-setting checks protect later execution. Both are needed when another operator may have changed the account during the discussion.

Drafting a client explanation or supplier handoff can use the established evidence without another API call. Retrieving actual current settings or action metrics requires the appropriate tool. Creative wording and current account facts should not be routed identically.

Ordinary replies place the user mention before the feedback footer, which remains last. Progress and execution notices use their own visible status layout. This makes discussion, pending review and technical completion recognisable.

Clarifications should identify the actual missing input politely. An ambiguous action or unavailable connection is not a reason to invent a result or redirect the request into unrelated drafting features.

Keep subsequent reports comparable

A client reconciliation can begin with a small definition sheet: selected actions, role population, date range, date basis and source. The agency should establish those choices before requesting two unexplained totals from different systems. A difference between non-equivalent totals is not evidence that the counting correction failed.

Distinguish an action-level figure from a campaign aggregate. The action view can answer how a particular business signal contributed, while the campaign view can include several selected primary outcomes. Moving between them without stating the population can make a client think the tool changed its answer arbitrarily. Retain the question's scope through follow-up and visualisation.

A later chart should preserve the definition used in the explanation. Coarser weekly or monthly presentation can improve readability where daily detail was not explicit, but the metric still needs the appropriate aggregation. A chart title cannot correct an underlying population mismatch or an invented missing value.

If the client explicitly asks for daily points beyond the native Slack allowance, explain the supported split rather than silently dropping days. Keep one chart when an appropriate supported coarser breakdown satisfies the request, and avoid an image fallback. The purpose is a readable faithful presentation, not another provider call for each formatting choice.

Record the selected outcome population and reporting dates when the counting choice changes. A later movement can reflect the revised definition as well as advertising performance. The client should understand that context before interpreting a trend.

Use compatible metrics. All-primary conversions, primary purchases and primary leads are different populations. Call or offline counts can already be included in a broader total and should not be added again as independent outcomes.

Preserve the requested date basis and traffic scope. A conversion-date report and an interaction-date report can answer different questions. A GA4 comparison also needs the relevant source and confirmed event selection where applicable.

Aggregate ratios from their underlying totals rather than averaging displayed campaign ratios. Unknown source values should not become zero merely to make a chart complete. Readable output must retain the metric definition.

Connect the correction with agency client reporting and conversion-tracking review. A focused field change and a broader measurement discussion support each other when their scope remains clear.

Avoid unnecessary account reads

Local action discovery establishes the correction's target and parameters. It does not need campaign enumeration for an existing conversion-action field update.

Reuse compatible returned action evidence for the explanation and proposal preparation. Fresh checks required before execution have a real purpose, while repeated identical analysis only adds latency when no new fact is needed.

Additional performance data should follow the actual client question. A current counting check does not automatically require every campaign's historical metrics. A creative explanation can remain conversational.

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

Recovery should be focused too: bounded safe read retries, uncertain-write reconciliation and stored-state message recovery are different tasks. These distinctions preserve rate capacity and the approved effect across busy agency channels.

Leave a useful agency handoff

Record withdrawn decisions as withdrawn. A client can change its mind during review, and the agency should distinguish that choice from a failed provider operation. The next operator needs the actual decision state before preparing a replacement proposal.

For a multi-client team, include the account mapping in the internal work record. Similar action names across clients must not lead to reused account facts or a proposal for the wrong connection. Local capability definitions can be reused safely, while each client's returned state and approval remain scoped to its own account.

When two agency operators discuss the same correction, coordinate the business decision before either submits a new proposal. Current-setting checks protect the actual effect, but they do not establish that every external editor has stopped working. The handoff should make clear which proposal is pending and who owns the next confirmation.

Review unresolved implementation work before declaring final closure. A matching counting field can be established while the website team is still investigating repeated event firing. The client can receive a concise update showing real technical progress and the remaining task, without suggesting that all measurement concerns are solved together.

Define the next observation point when later reporting is required. A completed field update is immediately useful evidence, while a later trend needs an appropriate completed period. Record that follow-up expectation without promising a guaranteed commercial improvement or an automatic future edit.

Use the handoff during supplier transitions. A new contractor or CRM workflow can change the underlying business event even when the advertising field remains untouched. Revisit the relevant action meaning and implementation responsibility rather than assuming last year's counting decision still represents the current client process.

The handoff should identify the client account, business meaning of each action, observed field, intended correction and actual outcome. Add the owners for unresolved website, analytics or import work.

Retain the audit's assumptions and any deliberate exception. Another operator should not undo a justified client decision solely because the same category recommendation appears again.

Keep technical receipts distinct from implementation evidence. The field change can be complete while a repeated-event investigation remains open. A concise client update should state both stages accurately.

During a takeover, preserve supplied statements separately from actual tests. A contractor's assurance that the form works is not the same as verified event evidence. The next agency operator needs to know which facts were observed and which require confirmation.

Use the original conversion-counting guide for setting mechanics and the agency audit routine for the broader engagement. This page adds the client decision and handoff responsibilities around those supported capabilities.

Answer conversion-counting questions

Does counting change primary role?

No. They are different fields and need separate explicit effects.

Does a passing card prove unique customers?

No. It establishes alignment with the audit's configuration rule.

Does the audit repair duplicate events?

No. Implementation duplication requires its own evidence and repair.

Is every action eligible for correction?

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

Is the audit bulk correction always atomic?

No. Its current path permits partial failures and rereads remaining mismatches.

Does the setting rewrite old reports?

Google describes the change as applying to future reporting, not past action data.

Should an uncertain write be repeated?

Reconcile the current resource and stored execution first. It may already have applied.