Review what each counted action means to the client
Google Ads conversion-counting audits for freelancers: choose justified settings and verify the exact correction
Understand the current counting recommendation, separate it from duplicate-event diagnosis and prepare readable owner-approved changes. Keep action scope, future reporting and implementation responsibilities clear during a freelance takeover.
Define the freelancer's counting review
A counting review should begin with the client's actual concern. The freelancer might be checking an inherited setting, explaining repeated recorded outcomes or preparing a change to one action. These questions can lead to different work, and the audit's recommendation should not replace the original brief.
Confirm the connected account and selected conversion action where the request is specific. A campaign name can help establish context, but the counting field belongs to an action. The assistant should resolve the actual resource rather than guess that a campaign label identifies one editable target.
Establish the deliverable before collecting every report. A successful review can explain the current choice, identify a justified exception or prepare an owner-approved correction. It need not become a website implementation project unless the evidence and client request require that work.
Record the measurement responsibility within the freelance engagement. The freelancer may manage Ads settings while a developer controls event emission and the client defines commercial value. Knowing those owners prevents an account correction from being described as a completed fix to components the freelancer never inspected.
Use settled conversation context where it already resolves the question. If the thread identifies the enquiry action and why it matters, retain that information. Ask a focused clarification only when ambiguity changes the proposed action or the meaning of the report.
Explain the two counting choices
Google's counting-options guidance distinguishes counting every conversion for a tracked action from counting one after an interaction. The choice applies to the action; it is not an account-wide customer deduplication setting.
The current audit displays these choices as Many per click and One per click. Its internal enum labels are preparation details, not necessary client-facing language. A proposal should explain the desired count in words the owner can connect with the business outcome.
A field read establishes the chosen configuration. It does not establish how many real people, orders or households exist in the client's other systems. Those interpretations depend on the event definition and relevant business evidence.
The freelancer should make clear what is being selected before discussing efficiency. A lower recorded conversion count after a deliberate choice is not automatically worse commercial performance. The count's definition can change even when the underlying business activity does not.
Keep this explanation short in the client conversation. The owner needs to recognise the current setting, intended change and reason. Long internal enum lists do not improve that decision when the supported choices and target are already clear.
Establish the commercial outcome
The business should define what one useful outcome represents. A paid order, submitted enquiry and repeated funnel interaction can have different purposes. The freelancer needs that definition before deciding whether the current count supports the client's objective.
A category label is an input to the audit's recommendation, not a complete description of the client's process. A named conversion can be miscategorised, deliberately broad or used for observation. Investigate those circumstances where they affect the proposed correction.
Ask the owner what repeated activity means commercially. Another sale can be valuable while another submission may represent the same enquiry, but the exact business process matters. Do not decide from an action name alone that every repeated outcome is invalid.
The freelancer should retain the agreed definition in the review record. A later analyst can then understand why a category-based recommendation was applied or intentionally retained as an exception. Without that rationale, the same account may receive contradictory corrections at each takeover.
A useful brief identifies the actual decision: review the count of the existing consultation enquiry action because repeated submissions are not separate acquisition outcomes. That is more actionable than a generic instruction to improve conversions, which can conceal several unrelated measurement questions.
Use the actual editable action inventory
The current counting finding uses the analysed conversion-action inventory, which excludes locked conversions. It compares only actions whose current count is one of the recognised One or Many enums. Its scope is therefore narrower than every possible conversion-like contribution in the account.
Enabled editable actions are configuration targets for the review. Historical performance can include another population. The freelancer should not assume that a list of recommended corrections is a complete census of all outcomes appearing in an account report.
Resolve the action's actual identity before preparing a live edit. Two similar names can describe different sources or purposes. The assistant should establish which existing action the client intended rather than selecting the first name containing a familiar word.
Internal resource identity supports reliable writes while client-facing names support readable review. Both matter, but they have different roles. Do not expose a raw identifier in place of an understandable target description or treat a name alone as a secure execution reference.
A focused inventory read can answer a configuration question without collecting every campaign metric. Obtain performance evidence when the client asks for performance, and obtain current action fields when the requested decision concerns counting. This keeps the freelance workflow efficient without weakening its evidence.
Understand the category-based audit rule
The inspected audit recommends Many per click for Purchase, Add to cart and Begin checkout. It recommends One per click for other recognised categories. This is application logic used to identify deviations, not proof that every intentional exception is a business error.
The finding lists only actions that differ from that expected rule. A clear list helps the freelancer focus the review, but it does not include every correctly matching action or every unsupported enum. Do not broaden its correction count into a statement about the whole account's measurement quality.
A pass means no deviations were found within the checked inventory. It does not prove every tag fires correctly, every action represents the right business event or every recorded value is financially accurate. Those questions require separate evidence.
A failure supplies a review candidate and current-versus-recommended setting. The freelancer should reconcile the recommendation with the client's commercial definition before proposing a write. The owner needs an intelligible reason beyond the fact that a category rule returned a mismatch.
Record an intentional retained exception where appropriate. That decision can be legitimate even though the audit continues to describe its generic recommendation. A useful review explains the difference instead of promising that every heuristic can be satisfied without changing the client's intended measurement.
Review purchase counting with the client
A purchase action should be evaluated against the client's actual order definition. The category suggests commerce context, but the freelancer still needs to know what event the implementation sends. A settings inspection cannot independently verify that every firing represents a settled order.
The current audit's Many recommendation fits its purchase category rule. Apply that rule with the commercial rationale established, rather than claim that the API examined the order ledger and selected the setting on that basis. The reader does not contain that financial verification.
A counting correction does not establish the role of the action. A purchase can have a correct count and still be secondary or used in a campaign context that needs separate review. Keep counting, role and goal observations distinct in the client report.
If two purchase actions exist, inspect their actual purpose before making a duplication claim. Changing one to Many does not identify overlap between the sources. The freelancer should avoid treating a count-field correction as proof that separate purchase implementations no longer record the same business outcome.
The proposed effect should remain narrow: change the selected existing purchase action's count. It should not imply that tags were removed, another source was demoted or historical revenue was recalculated. Additional requested effects need their own supported preparation and clear approval.
Keep funnel actions in their proper role
Add to cart and Begin checkout belong to the audit's Many category set. That recommendation concerns counting, not whether the client should optimise every campaign to those actions. A correct count does not settle the action's commercial role.
The business may use a funnel action for observation or another deliberate purpose. The freelancer should establish that purpose before treating its repeated activity as a finished purchase outcome. A category name does not convert a shopping step into realised revenue.
Recorded value on a funnel action is another question. An intentional value definition can affect reporting, while a counting edit changes a different field. Do not describe the count correction as repairing all value-risk findings in the account.
If the client asks why funnel totals are large, obtain the relevant reporting evidence and implementation context. The current count explains part of the configuration but cannot establish every reason the event fires. Repeated legitimate interactions and implementation mistakes need different diagnoses.
A useful freelance handoff preserves these distinctions. It can state the verified count, current role and outstanding event-definition check separately. The owner then understands the actual correction without being told that one action is universally good or bad because it sits earlier in the funnel.
Review lead counting without inventing quality
The audit recommends One for categories outside its ecommerce repeatable set. A lead-generation review should connect that recommendation with the client's enquiry definition. The application category cannot independently decide which repeated submissions represent useful separate commercial outcomes.
Keep lead types under the requested lead interpretation unless the user selects a particular action. A form, call or later qualification stage can have different implementation meaning, but the assistant should not invent a quality hierarchy from suggestive category labels.
The current count does not establish whether a lead is qualified. CRM evidence can inform that question when available and properly scoped. The freelancer should not convert One per click into a promise that every reported conversion represents one unique qualified person.
If the client wants one named enquiry action corrected, resolve that action and its present setting. A broad bulk correction can include other actions with different purposes. Keep the target population aligned with the request rather than assume every generic deviation should be changed together.
The resulting client message should explain the exact count effect and retain any unresolved quality question separately. This gives a freelancer a useful supported correction without claiming that account configuration alone repaired the business's entire lead process.
Investigate calls and imported outcomes
Call-related actions need their actual type and origin inspected before an edit is offered. The word call in a name does not establish whether the action is editable or managed by the provider. The shared policy makes this distinction through source signals.
The client's call definition also matters. A reported action is not automatically a verified conversation, qualified enquiry or completed sale. A counting review should explain the selected field while leaving those business interpretations attached to the relevant measurement evidence.
Imported offline outcomes can be visible in reporting and may have deliberate commercial definitions. The action's current count does not verify the completeness of the upload process or the identity of every record. The freelancer should identify the process owner where that investigation is needed.
Do not change a role or value setting as an unannounced consequence of counting work. Primary calls and offline outcomes can contribute count and value under their configuration. The owner must see each requested logical effect clearly before approving it.
A practical handoff can state that the selected editable call action's count was verified while an offline process check remains assigned elsewhere. That is an accurate outcome. It is more useful than claiming all call and imported conversion tracking became correct through one field change.
Do not confuse counts with customer identity
A conversion count is a source measure, not a customer database. The current audit does not expose every person's identity or establish the number of distinct households behind the reported outcomes. Avoid switching between conversions and customers as though the words were interchangeable.
An action can be configured to count one while several actions still contribute separately. That matters when the client wants a total of primary outcomes. The aggregate should retain its actual definition rather than become a locally invented unique-person count.
Fractional reported conversions can also appear in performance results. Preserve their underlying precision for calculations and format them readably. Rounding a result into a whole-person description can misrepresent the measurement even when the counting field is valid.
If the client needs unique customer acquisition, identify the proper business source and scope. The counting setting alone cannot answer that broader question. The freelancer should explain the missing evidence instead of assuming every counted outcome represents a distinct new buyer.
This boundary makes the report clearer. A statement about recorded actions can be accurate and commercially useful without pretending the app performed identity resolution. Keep the selected measure stable from the table through the conclusion and any exported summary.
Separate duplication and counting corrections
A counting field and duplicate-event implementation are different components. The current edit changes how the selected action counts outcomes. It does not remove website tags, reconcile transaction identifiers or determine whether two sources recorded the same purchase.
The freelancer should investigate suspected duplication with the relevant implementation owner. Similar action names or values can suggest a review, but they do not prove every outcome overlaps. The settings audit identifies configuration evidence, not a complete event-by-event diagnostic.
Two primary actions recording the same business outcome can both contribute to the aggregate. The ordinary report does not deduplicate between separate actions. Do not promise that selecting One on each action resolves that cross-action relationship.
Likewise, an observed count reduction after a field change is not proof that a website error was fixed. The measurement definition changed. A developer's verified implementation correction would be a separate result with its own scope and evidence.
Keep confirmed overlap and suspected overlap clearly identified in the handoff. That lets another freelancer continue intelligently without assuming the audit already settled the transaction relationship. It also prevents a generic counting recommendation from becoming an unsupported explanation of the client's sales ledger.
Keep action roles and campaign goals distinct
Counting, primary role and campaign-goal use answer different configuration questions. An action can match the count heuristic while its role still deserves review. The freelancer should not treat a counting pass as a complete optimisation-settings pass.
A supported counting proposal changes the selected counting field. If the client also wants a role correction, prepare that separate logical effect explicitly. The owner should not discover an unrequested primary-to-secondary change after confirming a count adjustment.
Campaign context can matter when interpreting the commercial effect. An account action can be relevant to more than the campaign that motivated the review. Establish that scope where required rather than describe an action-level setting as a change confined to one campaign without evidence.
The client's requested reporting aggregate remains separate from configuration advice. A primary-only report should reflect the selected primary population, not subtract contributions locally because the audit recommends another role arrangement. Reporting is not an undisclosed repair operation.
Document the observed count and role separately. A later account manager can then see which decision was made and which setting was verified. This reduces confusion when a follow-up asks why campaign conversions differ from a broader account report.
Preserve the recorded-value definition
A count correction does not independently redefine conversion value. The client may assign values to purchases, leads or other primary actions. The freelancer should preserve the actual measure when reporting value instead of calling every primary-value total purchase revenue.
The current audit has a separate ecommerce value-risk review. Its findings use another heuristic and action population. A valid counting correction should not be presented as complete resolution of every value observation unless the relevant fields and implementation were also verified.
Acquisition cost and return calculations depend on consistent numerators and denominators. If the count definition changes, later comparisons need that context. A different ratio can reflect measurement configuration rather than a proportional change in actual commercial performance.
Use the account's verified currency and actual action scope in client reports. A compact money symbol or an action's friendly name cannot establish those definitions alone. The freelancer needs enough evidence to explain the metric without inventing financial reconciliation.
Retain the underlying values for calculations and use no more than two displayed decimals. Readable formatting should not change the selected population or manufacture a precision claim. An export and Slack summary need the same definition even when their layouts differ.
Explain historical and future scope
Google's counting guidance states that changes apply to future reporting rather than rewriting past data. The freelancer should explain that prospective effect plainly. A live field correction is not a historical reconstruction of every conversion the account previously recorded.
The current setting read also does not supply a complete change timeline. Do not assume the field had the same value throughout the client's selected period. Actual change evidence is needed if the timing affects a before-and-after interpretation.
Keep the reporting window aligned across count, cost and supporting observations. Last thirty days and last calendar month are different requests. A saved reporting period should not silently replace the client's date instruction when evaluating the effect of a correction.
Recent outcomes may still develop after their interaction dates. A completed day does not guarantee every reported conversion is settled. A follow-up should use an appropriate measurement interpretation rather than declare a commercial change from an immediate small count difference.
Record the verification date and later review question separately. The first establishes technical account state; the second evaluates recorded outcomes under the new context. Neither alone proves a causal business uplift or a complete repair of measurement implementation.
Handle missing configuration evidence
An unavailable conversion-action read is not proof that the account has no editable actions or every count is wrong. The audit records section failures so missing evidence can remain distinct from configuration findings. The freelancer should establish source success before trusting a complete-looking verdict.
Fallback collections can support rendering without becoming client facts. A failed action read represented internally by an empty array does not establish that no deviations exist. The exported review must preserve the unavailable condition rather than convert it into a verified pass.
Unknown or unsupported counting enums are outside the current comparison rule. Their omission from the mismatch list is not evidence that the application checked and approved them. Inspect the actual returned inventory where the client needs a complete explanation.
A focused retry can resolve a temporary read failure while retaining the requested action and account. Recollecting unrelated campaign assets adds work without obtaining the missing count field. Use the smallest source observation that completes the actual decision.
If the evidence remains unavailable, state the precise unresolved input and preserve verified context. The freelancer can still assign the next investigation step. It should not prepare a confident write solely to correct a state inferred from placeholders.
Respect locked and source-managed settings
The shared locked-conversion policy uses action type and origin rather than names. Google-managed and specified read-only actions are excluded from the editable path. A friendly label does not establish that the provider permits a counting mutation.
Google's guidance identifies source-dependent management conditions, including counting controlled in Analytics for paid-and-organic attribution. Establish the real action context before offering an Ads-side change. Do not promise universal editability simply because a field appears in an API definition.
The current audit recommendation inventory and the shared AI edit check have their own boundaries. A generic schema request cannot make an immutable field writable. Preparation must still establish the actual supported resource and provider applicability.
If the requested effect is unavailable, explain that specific limitation and retain the useful report. An unrelated editable action is not a substitute for the client's target. The owner should understand which measurement component needs a different setup path.
Keep eligibility separate from reporting visibility. A locked action can still matter to the selected outcome report. Excluding it from an edit plan does not authorise removing its contribution from an aggregate that the user asked to see.
Prepare one supported counting change
The shared AI preparation resolves the exact conversion target, checks its current fields and applies the locked-action policy. It then prepares the selected count field with the requested supported value. This gives the owner a concrete proposal rather than an unspecified instruction to fix conversion counting.
The preparation builder records a readback expectation for the same field. If the current value already matches the intended value, it can retain a check without adding a redundant update. A no-op should not be described as a newly applied correction.
Use the action's actual name in the readable description. The internal resource reference supports dispatch, while the owner needs the recognisable target and before-and-after effect. Raw identifiers do not improve the client decision.
A conversion-action edit does not require discovery of every keyword, product or ad asset. Local scope knowledge identifies the relevant resource. Additional reads should establish the required current configuration, not collect unrelated structures merely because they exist in the account.
Keep the proposed reason connected to the client brief. A category mismatch can support review, but the intended commercial count explains why the change is appropriate. The owner should be able to approve the real decision without decoding implementation details.
Understand the existing bulk correction
The existing audit bulk action re-reads enabled conversion actions before writing. It inspects type, origin, category and count, excludes locked actions and computes the current mismatch list. That avoids blindly reusing an old rendered list as the entire live correction scope.
The actual batch uses partial failure, despite an earlier stale comment describing atomic behaviour. Eligible operations can therefore have different outcomes if the provider rejects part of the batch. The freelancer should describe the implemented behaviour rather than repeat the outdated comment.
After dispatch, the action re-reads the inventory and computes remaining mismatches. Its reported fixed count comes from the difference between before and after mismatch counts. That is a reconciliation mechanism, not an operation-by-operation transaction ledger.
Concurrent configuration changes can affect a broad before-and-after inventory comparison. Do not promise that every reduction proves one specific operation succeeded solely because the number shrank. Exact selected-field evidence remains important where the client needs an individual result.
A bulk recommendation also needs the owner's commercial review. Several actions can have different intentional purposes. The freelancer should not apply every heuristic deviation automatically when the client requested only one target or retained an explicit exception.
Reconcile partially completed work
A batch can finish with some settings corrected and others still unresolved. The client needs the actual completed and remaining effects, not a generic success message that hides the incomplete work. Preserve the real targets when explaining the outcome.
Provider acceptance and remaining mismatch analysis provide different evidence. A batch response can be accepted while particular operations fail. A later read can establish current state, but it should be interpreted within its real scope rather than described as a guarantee that every original write occurred.
Reconcile an uncertain target with a focused field read before preparing another mutation. Do not replay the whole batch merely because one result or Slack message is missing. That could repeat work already completed and obscure the original operation record.
If a target is now locked, removed or otherwise inapplicable, explain that state accurately. A revised proposal may be needed for the remaining supported request. The owner approved the original concrete scope, not an arbitrary substitute that happens to be editable.
The freelancer should leave a precise remaining-work note. Name the unresolved action and evidence required to continue. This makes partial progress reviewable while avoiding an unsupported claim that the account's entire counting configuration is correct.
Show a clear owner confirmation
The confirmation should show each requested logical action as a readable step. Name the selected conversion and count change plainly. A wall of raw enum payloads makes the operation harder to understand without increasing the owner's ability to judge its effect.
The application can use one confirmation for a supported sequence with each action clearly visible. If the complete request needs smaller proposals for safe review, ask the client to divide it before writing. Do not silently execute only the first steps while presenting the whole original request as completed.
The connected owner confirms before execution. The proposal states that no changes have been made yet and that it expires in fifteen minutes. A discussion of the audit finding is not itself authorisation for a live setting update.
Keep additional effects explicit. A role edit, value change or new action setup is different from the count adjustment. The client should not discover those changes after clicking a button that appeared to approve only counting.
A short commercial rationale helps the owner evaluate the proposal. Explain the intended outcome definition rather than promise a performance uplift. Technical validity can establish that an edit is possible, while the client brief establishes why the selected effect is appropriate.
Match verification to the execution surface
The shared AI edit preparation records the exact expected count and its verification read. Preflight checks whether the prepared operation still applies; readback checks the resulting field. These stages answer different questions and should not be described as redundant copies of the same task.
The existing audit per-item runner returns the provider result without its own explicit count readback. The bulk runner performs a broader inventory re-read. Do not claim those legacy paths have identical field-verification behaviour merely because they edit the same setting.
Show visible progress when the owner clicks confirmation, then a prominent accurate result. The owner should know whether execution was verified, partially established or uncertain. Delayed messaging should not make the workflow appear inactive or encourage repeated clicks.
If dispatch may have succeeded but verification failed, reconcile the resulting state rather than blindly replaying the mutation. A missing final response does not prove the account write failed. Message delivery and field state need their own evidence.
A verified count confirms the technical setting, not website event correctness or future commercial performance. The freelancer can report that narrow result confidently while assigning implementation and outcome review separately. Clear boundaries strengthen the report instead of weakening a valid verification with unsupported claims.
Follow an invented freelance counting review
Consider the invented freelancer Hazel Brook and the invented client Elm Court Lessons. The client asks why its enquiry action uses Many while the business regards repeated submissions as one acquisition enquiry. These names and observations illustrate a process rather than describe a live customer account.
The freelancer resolves the named enabled action and confirms its current count. The audit recommends One for its category. The client supplies the commercial definition, while a developer remains responsible for checking whether the form emits the intended event.
The assistant prepares one exact count change, retaining the action's role and value settings. The proposal uses the recognisable name and explains the effect. It does not claim to remove website tags or deduplicate outcomes across every other action.
After owner confirmation, current-state checks and field readback establish the requested setting. The final response makes that result clear. The developer's event review remains separate, because the count change does not verify the actual form implementation.
The handoff records the agreed definition and prospective review scope. It does not rewrite past results or convert the new count into a unique-person census. The example shows how a freelancer can complete a justified setting correction while preserving the rest of the measurement responsibility.
Keep reports and exports consistent
Lead with the requested decision and its evidence. The client needs the current count, the recommendation and the actual approved result if a change occurred. A complete internal payload is rarely the most useful way to explain that narrow outcome.
Keep configuration and metrics separately labelled. A counting setting describes a field; a conversion total describes a reporting population and period. An implementation task describes another source of evidence. Combining them into one tracking-health sentence hides important differences.
Use readable action names and no unnecessary account identifiers in client outputs. Parent context should be included only where it reflects the real target relationship. A conversion-action setting should not acquire an invented ad-group parent because another asset type uses that hierarchy.
Exports must preserve the same availability and scope boundaries as Slack. An unread inventory cannot become a clean pass in a PDF, and a count correction cannot become a verified event implementation in a CSV. Format changes do not enlarge the evidence.
Display supporting metrics with no more than two decimals and clear units. Retain underlying precision for calculations. Avoid estimated losses or promised gains that the boolean or enum field never establishes; the client's commercial assessment needs its own actual outcomes.
Continue the conversation without wasted reads
The assistant should retain the action, account and business definition already established in the thread. A follow-up asking to change its count can continue that context where the target is unambiguous. Repeating settled discovery makes the conversation harder without improving the result.
Reuse compatible retained evidence for explanation, while obtaining current fields for executable preparation. A prior reporting total can answer a compatible question but cannot substitute for the action's fresh configuration. Choose the read that resolves the actual dependency.
A creative request can remain conversational. The assistant can draft a developer handoff or client explanation from supplied context without querying every Ads surface. It should not treat all measurement-related wording tasks as factual performance requests.
A requested live edit still needs the confirmation workflow. Context continuity resolves the target; it does not bypass the connected owner's approval. Clear progress and execution messages help the client distinguish explanation, preparation and an actual write.
Keep ordinary reply mentions before the final feedback section and progress messages focused on the operation. Consistent output makes the workflow recognisable. The owner should not need to inspect a technical wall of text to determine whether a correction is awaiting confirmation or already verified.
Record the decision and next measurement owner
Record the selected action, agreed commercial definition and actual count decision. If a change occurred, retain the verified field result and its date. Another freelancer should understand what was done without reconstructing the entire conversation.
Keep intentional exceptions with their rationale. A future analyst can then distinguish a deliberate business choice from an unexplained mismatch with the generic audit rule. This prevents repeated automatic proposals that ignore the owner's established objective.
Assign any remaining implementation investigation explicitly. A developer may still need to inspect event emission, while the business owner may need to clarify downstream quality. The account correction can be complete without concealing those separate unfinished tasks.
The follow-up should identify a concrete question and trigger. It might review a verified implementation release or compare appropriately defined recorded outcomes after the setting change. A vague instruction to watch conversions does not establish what evidence would complete the next review.
A useful conversion-counting audit gives the client a justified setting decision with a precise scope. It preserves the difference between counts, identities and implementation, uses owner-approved supported edits and leaves the measurement handoff clear. That makes the freelancer's work practical without promising that one field repaired every tracking issue.