Google Ads enhanced-conversions-for-leads audits for consultants: verify signals and assign the remaining work

Define the client's lead-measurement brief

An enhanced-conversions-for-leads review should start with the outcome the client wants to understand. The engagement might concern account readiness, a form implementation, a later offline result or a reporting discrepancy. Those questions use different evidence. A pair of account flags can help establish readiness without answering whether a particular lead was matched or whether an import is operating correctly.

Agree what completion means before collecting data. A settings review can close with a verified account read and a clear next instruction. An implementation review needs the relevant website path and its behavior. An import review needs evidence from the actual supported data flow. A business-outcome review needs the chosen event and reporting population.

Identify the owners of those tasks. The account owner may need to review provider terms, the developer maintains the form and the operational team records the later sale or booking. A consultant can coordinate the evidence and prepare supported account edits, but should not imply that one role owns every part of the process.

The deliverable should name what is established and what remains. “The enabled signal is on and terms are reported accepted; the selected form and import still need testing” is more useful than “enhanced tracking works.” A bounded statement lets the client assign remaining work without reopening an account-read question that has already been answered.

Include an acceptance condition for each responsibility. The account review can require a successful fresh signal read. The website task can require evidence from the agreed successful enquiry path. The operational task can require a correctly defined later outcome reaching its maintained destination. These conditions keep the engagement practical: the client knows which demonstration closes a task, rather than receiving an indefinite instruction to investigate tracking.

Understand the matching purpose

Google's enhanced-lead setup guidance describes using user-provided data to supplement imported offline outcomes. The purpose is measurement matching, rather than creating demand or proving lead quality. An account setting is one prerequisite within a wider collection and import process.

That distinction matters when the client expects more leads after a configuration change. Better measurement can affect what is recorded and used by a supported setup, but the enabled flag does not guarantee additional enquiries, completed sales or improved profitability. Keep business expectations tied to the actual evidence rather than a feature name.

Frame the benefit as a measurement objective the implementation must demonstrate. The client can then evaluate whether the selected outcome becomes more useful for its reporting purpose, without treating a configuration milestone as an immediate commercial result. This makes the consultant's recommendation both actionable and proportionate to the evidence.

The later outcome can be different from the initial form submission. A person may enquire today and book after a call next week. The client needs a clear definition for the outcome recorded at each stage and a reliable way to maintain the intended connection. The audit card does not inspect that whole lifecycle.

A useful explanation separates identification, event meaning and reporting. Information used for matching does not decide whether the enquiry is commercially valuable. The event definition supplies that meaning, and the selected report supplies a measured result. Treating those layers separately helps the consultant avoid a broad promise based on a narrow readiness signal.

Read two separate account signals

The current account-core reader selects enhanced_conversions_for_leads_enabled and accepted_customer_data_terms with the other chosen customer settings. They are collected in one customer-row query rather than separate requests for related fields available in the same response. The audit preserves the two values separately.

The enabled signal describes the provider state returned for that field. The terms signal describes the reported acceptance state. Neither should be inferred from the other. The client can have accepted terms while the enabled signal is off, or receive an on signal without acceptance reported as true.

The audit displays two labelled pills and a summary reflecting the observed pair. This is more useful than collapsing both into a single “good” or “bad” label. It prevents the client from being asked to repeat an acceptance step that the account already reports completed.

A rejected customer read is unavailable evidence, not an off state. The account section should report that the setting could not be checked rather than invent a negative signal from a provider error. A consultant's next step should resolve the read before presenting configuration as an established deficiency.

Interpret each returned state pair

When both signals are positive, the audit can state that the enhanced-lead flag is on and the terms are accepted. That is a useful readiness observation. It does not establish that the form collects the right information, the import route is authorised or the selected business outcome has been matched.

When the enabled signal is off but terms are accepted, direct attention to the missing feature state and relevant provider setup. Do not tell the owner to accept terms again. The two-state explanation makes the next instruction specific and avoids a generic setup message that ignores completed work.

When the feature is on but acceptance is not reported, preserve that pair rather than treating the feature as proof of complete consent-related readiness. The account owner needs to review the actual provider state and applicable account relationship. The assistant should not quietly accept terms or label them satisfied because the other flag looks favourable.

When both are negative, explain both missing reported states and the provider-directed setup steps. The consultant should still stop short of claiming that the business has never collected or imported any outcome. These fields describe a selected account signal pair, not every measurement process the client might operate.

Respect output-only fields and human acceptance

The current API schema marks both selected fields as output-only. The audit therefore has no automatic enable fix for this account setting. A generic field catalogue does not turn every readable field into a writable one, and the assistant must respect that boundary when the client requests a change.

Terms acceptance is also a decision for the authorised account owner through the appropriate provider flow. A consultant can explain the missing state and assign the step. The conversation should not perform that acceptance silently or present another account edit as equivalent to it.

Related supported edits remain possible when requested. A conversion-role change, counting update or auto-tagging action has its own resource and effect. Those operations must not be described as enabling enhanced conversions for leads. Choosing a nearby writable field would produce a different result from the user's intended setup.

This boundary still allows useful work. The tool can read the signals, explain the current pair, outline the implementation questions and prepare exact separate supported actions. An honest capability limit gives the client a viable next step instead of an invalid mutation proposal that fails only after confirmation.

Check current provider settings and migration

Google's account-level enhanced-conversion guidance documents the unified setting introduced in 2026. The app's current audit still reports the selected API signals. A consultant should distinguish the provider's present UI and implementation model from the names of fields returned by this reader.

The offline-conversion developer guide documents historical access restrictions beginning in June 2026 and directs implementation toward Data Manager API. An old upload example is therefore not proof that this application's credentials can use the legacy route today.

Verify the intended implementation's actual supported route and access before planning an upload. A readable conversion action does not establish upload permission, and a provider migration notice does not establish that ppctor has implemented the new ingestion workflow. The consultant should keep those capability claims separate.

A useful handover can name the migration review as an external implementation task. It should not promise a built-in Data Manager upload tool merely because the official API exists. The current conversational audit can provide evidence and planning without pretending it operates an integration that has not been established in the application's code.

Give migration work a separate owner and checkpoint. A consultant inheriting an account should ask which maintained integration sends the later outcomes and who can demonstrate its current operation. An old screenshot or an account flag may explain historical intentions, but neither proves that the presently deployed sender works. Record the current integration evidence before suggesting replacement work; otherwise the client can end up funding a new connection while a working existing flow remains misunderstood.

Map the enquiry-to-outcome journey

Describe the process in business terms: where the initial enquiry occurs, where the operational team records it, which later outcome matters and how that outcome enters the selected measurement system. This map identifies the actual boundaries that a consultant needs to review.

The initial lead and later event can have different dates and values. An enquiry may be free while a completed job carries revenue. A person may submit a form and later cancel. The conversion definition should reflect the business event actually being reported rather than treat every stage as an interchangeable lead total.

Ownership can change along that journey. The website developer maintains collection, the operational team maintains the event record and another integration handles import. A missing step can remain unresolved even when the account owner has completed the provider setting. The handover should assign each task explicitly.

Keep the map focused on the requested outcome. There is no need to inventory every form and operational system when the client asks about one consultation flow. If the brief later expands, add the relevant paths with their separate evidence. A bounded process map is more useful than a speculative diagram of systems the client may not actually use.

Record exception paths alongside the ordinary route. A visitor might telephone after browsing, amend an enquiry through a staff member or submit twice while awaiting a response. The business can treat these situations differently without the consultant inventing one universal event rule. Describe how the operational team decides which later record is the intended outcome, then check whether the maintained measurement process reflects that decision. A simple account readiness card cannot resolve this business policy.

Review the actual website collection path

The enabled signal does not inspect the client's form. A contact page, a booking widget and a quote form can have different implementations even on the same website. Identify which path supplies the requested outcome before asking the developer to verify collection behavior.

Use actual implementation evidence rather than a guessed trigger. A form can send an event on a button click, successful submission or later confirmation page. Those are different behaviors. The consultant should establish the intended completion event and what the tested flow actually does.

A third-party transition can introduce another boundary. The main website may work while a calendar or payment step handles information differently. A successful first page load does not certify that later path. Record the tested route and the untested steps so the client knows the scope.

Website work belongs to its appropriate owner or supported deployment workflow. A Google Ads configuration edit cannot install the client's tag by itself. The consultant should state the required correction and verification separately, rather than describe an account signal readback as proof that the website implementation is complete.

Agree the test environment and the meaning of a successful test. A developer can demonstrate a collection path with an authorised test case rather than display a real customer's personal values in Slack. The evidence should identify the tested page, completion behavior and relevant observation. A demonstration from a different form is useful background, but it should not close the selected consultation-form task unless the owner establishes that the relevant implementation is shared.

Keep identity data out of normal Slack output

The business-facing review does not need real lead emails, phone numbers or other personal values pasted into the conversation. It can identify the relevant form field, required implementation owner and observed collection state without displaying customer records.

Hashing and formatting belong to the implementation's supported data handling. They are not a reason to treat transformed values as useful client report columns. The owner needs to understand whether the process is correctly configured, not inspect a wall of identity-related payload values.

Use invented examples when explaining the process and keep operational evidence in its proper context. A client-facing job URL should not encode an email or advertising account identifier merely as a lookup shortcut. Readable names and an opaque report reference can coexist with exact internal resolution.

The consultant should also separate provider terms from a universal legal conclusion. A returned acceptance flag establishes that reported account state; it does not certify every aspect of the client's data practices. The audit can assign the relevant provider and implementation review without pretending that a boolean field supplies a comprehensive compliance assessment.

Define the later business event

A later event needs a stable business meaning. It might represent a completed job, a booked consultation or another outcome the client considers valuable. The consultant should confirm that meaning rather than assume a category label determines the whole process.

For ordinary lead reporting, the app can aggregate primary lead categories as leads. It should not impose a new distinction between lead labels when the user did not request one. If the user asks for a named later stage, resolve the specific action and keep that definition visible.

An event name can suggest a likely meaning without proving it. A custom label such as “complete” might refer to a form or a sale. Ask the clarification that changes the report or proposal. The aim is a measured outcome the client can interpret, rather than an inventory that sounds precise but has uncertain business semantics.

Keep the operational source in view. An accepted enquiry and a completed job can be recorded by different teams at different times. If the later record is missing or inconsistently defined, the account's on flag cannot repair it. The next useful task may be process clarification rather than another Ads setting.

Establish the supported import route

An import route needs actual capability and access evidence. The client might use a maintained connection, an approved file workflow or another integration. The current audit's selected fields do not establish which route operates or whether a particular request has been accepted.

Review the current provider requirements for the intended route, including migration context, rather than copy an old sample into a new promise. A method appearing in documentation or a schema does not prove the application's credentials are eligible to call it for the selected account.

Acceptance of an import and evidence of a later matched result are different states. The consultant should inspect the relevant diagnostic evidence where the implementation makes it available. A transport response alone should not become a client claim that every lead was successfully attributed.

If ppctor does not expose the needed ingestion workflow, say that precisely and assign the task to the supported provider setup or implementation owner. The app can still read available conversion configuration and performance. Reading an offline action and uploading new offline outcomes are separate capabilities.

Separate readiness, acceptance and matched results

Readiness is the account signal pair and relevant prerequisites. Acceptance is an observed result from the supported import or implementation workflow. A matched reporting result is another evidence layer. Each supports a different statement, so the consultant should not collapse them into a single “working” status.

An on flag with accepted terms is not a match-rate report. A successful submission is not proof that the later business outcome appears in the chosen reporting population. A performance total can be useful without identifying which underlying events matched. The client needs the distinction that answers the actual brief.

Investigate a diagnostic message at its own scope. It can identify an issue with one data flow or event definition, rather than every form on the website. A useful follow-up names the affected path and required owner task instead of applying a broad configuration change unrelated to the observed problem.

Keep evidence time-bounded. A provider state read and a test result have dates. Another developer can change the implementation or an integration can alter its behavior later. The handover should establish what was observed, while ongoing monitoring needs separate explicit configuration rather than an implied permanent guarantee.

Use a small evidence register rather than a single undifferentiated status. For each observation, record its subject, time, source and implication in plain language. An account read establishes a field state; an implementation test establishes behavior along its tested path; a selected performance report establishes a measured total. This register lets a replacement consultant continue from verified facts. It also prevents a later report from being cited as proof of a website test that nobody performed.

Review conversion roles without changing the feature

Primary and secondary roles determine a conversion action's role within the applicable reporting and goal setup. They are separate from the enhanced-lead account signal. Changing a role does not enable the feature, accept terms or implement a data flow.

For requested primary-only reporting, include the selected primary actions and exclude secondary actions. Several primary outcomes can contribute within that definition. The tool should not discard one because another audit baseline recommends a simpler ecommerce configuration.

A named action comparison or role proposal needs the exact action and business meaning. The current builder checks the locked-conversion policy before editing relevant managed cases. An action can remain readable while unavailable for the requested role mutation.

Campaign goals also require their own context. Google's custom-goal exception means a simplistic statement that secondary actions never matter to bidding can be misleading. The conversion-tracking guide explains those boundaries and the difference between measuring the requested scope and changing the signal configuration.

Keep counting and overlap distinct

One or Every is a per-action counting policy. It is not a universal identity or cross-action deduplication mechanism. If two actions record the same business outcome, the selected primary report can still contain both measured contributions.

Two actions can also represent distinct valuable events. Their category labels or similar names do not prove overlap. The consultant should establish the actual event relationship before recommending that one be demoted or its counting policy changed.

A repeated import or website trigger is an implementation question. The on flag does not identify its cause, and a counting edit may alter reporting without correcting the underlying event behavior. The handover should distinguish policy changes from the required implementation review.

The counting guide explains the prospective boundary of those edits. A reporting request should preserve the client's configured primary scope without silently carrying out a duplication cleanup. A separate explicit change can be prepared only after its intended effect and target are established.

Explain assigned value and primary reporting

A lead or call can have assigned monetary value without being a purchase. Standard Ads conversion value can therefore include primary non-purchase contributions. The consultant should name the selected definition before presenting a return ratio as revenue performance.

All primary conversion value and purchase-only value answer different questions. Several primary actions can be added within the requested definition, while secondary actions stay outside a primary-only result. The app should not silently change that scope to make a comparison more attractive.

A later completed job can supply a different value from an initial enquiry estimate. The client needs to decide which outcome and definition the report should use. The account enabled signal does not identify the correct commercial amount or validate the operational record.

Keep profitability claims separate. A measured value ratio does not establish margin, labour cost or future performance. A configuration review can identify the field state and useful next measurement task without promising a recovery amount or attributing every value difference to enhanced-lead setup.

Select the corresponding Analytics event

An Ads lead measure needs a corresponding GA4 event selected for a meaningful comparison. The assistant can inspect available names and suggest a likely candidate. It should ask the client to confirm when naming alone does not establish whether the event represents a form, booking or later outcome.

An individual Ads action can be compared with a specified event when the user identifies both. Retain those names and the traffic scope in every part of the output. Do not replace the missing selected event with all website events merely to produce a chart.

All-primary conversions can also be compared with the selected aggregate key-event measure when requested. The reporting framework should preserve the chosen definition. A custom event representing an initial form and an offline action representing a later sale are not automatically the same outcome just because both relate to one customer journey.

Revenue scope needs equal care. All-traffic GA4 revenue divided by advertising cost is blended ROAS or MER. It is broader than a Google-Ads-only return measure. Distinct monetary series can be compared with honest labels without pretending that enhanced-lead readiness removes differences in event meaning, attribution or population.

Choose dates and conditions that fit the process

A current account signal read and a historical performance report have different time scopes. The field observed today cannot reconstruct every setup state during an earlier month. Record relevant application or implementation dates when the client asks for a before-and-after comparison.

Lead processes can take time. An enquiry might become a recorded sale after several days, while an import arrives later. A very recent period can therefore have a different completion state from an older one. The consultant should state the selected outcome and period rather than diagnose every shortfall as failed matching.

Last thirty days is not last month. Use the account time zone and actual requested boundaries, then retain them through the chart. Exact filters matter too: above differs from at least, and AND differs from OR. Undefined ratios and unavailable evidence should not become zero merely to satisfy a condition.

A count of qualifying actions differs from a preview of examples. Preserve population, filters and completeness in the shared report definition. The client should understand which events and dates the result measures before using it to justify a configuration proposal.

For a change review, keep the outcome definition stable across the compared periods. Switching from an enquiry measure before the change to completed-project value after it creates a different comparison even if both reports contain a familiar conversion label. State any deliberate definition change separately and avoid describing the difference as an isolated effect of the enhanced-lead setting. The client can still learn from both reports when their distinct meanings remain visible.

Follow an illustrative consultancy review

This example is invented. Consultant Iris Lane reviews a lead-measurement setup for Reed Home Planning, a business receiving consultation enquiries and recording completed projects later. The client asks whether enhanced lead measurement is ready, rather than authorising a general conversion cleanup.

The account read returns an off enabled signal and accepted terms. Iris explains that pair accurately and does not ask the owner to repeat acceptance. The owner reviews the relevant provider setup, while the website developer separately checks the selected consultation form and the operational team identifies the later completed-project event.

The audit cannot apply an automatic enable mutation to its output-only fields. Iris therefore assigns that provider step rather than disguising a conversion-role update as the feature enablement. Any requested related supported action would receive its own exact proposal and confirmation.

The handover records the account state, form task, current import-route review and selected event definitions. A later signal read can confirm reported readiness, while implementation and reporting evidence remain separate. The example illustrates a clear consulting process without exposing client records, claiming an unbuilt upload tool or promising recovered revenue.

Suppose the owner later reports that the setting is on. Iris requests the relevant fresh account evidence and updates that one part of the record. She does not mark the form test or import task complete automatically. If the developer then demonstrates the selected form's behavior, that evidence closes the corresponding implementation question. The operational outcome still needs its own supported flow evidence. Progress is visible without allowing the first completed task to conceal the remaining dependencies.

Use Slack context and narrow evidence reads

A client can ask for the account signal pair, then request an explanation for the developer. The assistant should reuse the established account and evidence where appropriate. Rephrasing the finding does not normally need another identical provider call.

Creative and planning tasks can stay conversational. Drafting a handover note, outlining implementation questions or improving a form instruction can use confirmed facts. The assistant should not automatically invoke keyword research or another full audit because the subject is advertising.

New fact questions need the relevant narrow tool. A changed period, named action or current-state prerequisite can justify another read. A live edit needs fresh relevant configuration because someone else may have changed it. That is different from rereading every resource for a presentation-only follow-up.

The generic framework should select supported metrics, dimensions and operations from local definitions, then retrieve the required evidence. This reduces unnecessary provider calls and repeated model work without replacing factual answers with guesses. Client replies should focus on the result and remaining task, not internal query syntax or routing decisions.

Present measured trends with readable scope

The two account signals are current configuration observations, not a daily lead-performance series. A trend chart needs actual measured data with the selected dates and outcome. Do not repeat the current boolean across a month or divide an aggregate conversion count evenly across days.

The app limits chart metrics or segments to three for readability. Try one compatible chart for two or three requested measures. If the user asks for more, explain the limit and ask for a selection rather than silently drop a requested series.

Native Slack charts allow twenty points per series in this workflow. A longer period without explicit daily detail can use a stated weekly or monthly breakdown. Explicit daily requests beyond the limit need split native charts and an explanation, rather than an unrequested image or missing dates.

Use readable dates and at most two displayed decimal places. Calculate grouped ratios from summed base metrics. Put the user's mention before feedback so feedback remains last. A concise caption should name the outcome, period and scope without implying that a performance chart certifies the entire collection and import implementation.

Prepare only supported requested edits

Capability discovery must distinguish readable output-only state from supported mutation fields. A schema inventory is useful precisely because it carries those constraints. The assistant should explain an unavailable requested operation instead of selecting a related edit with another effect.

Local dependency definitions can establish structural relationships without API usage merely to learn the parent. Current ownership and settings still need narrow reads when required for a proposal. An account operation should not trigger a campaign search simply because another part of the conversation discussed campaign performance.

A supported related edit, such as auto-tagging or a conversion-role change, needs its exact target and parameters. It does not accept terms or install the enhanced-lead implementation. If the client requests several related steps, preserve their distinct purposes rather than call the sequence a universal tracking fix.

Keep external tasks outside the execution claim. A website deployment, operational-process correction and Data Manager integration need their actual supported workflows and owners. The app can coordinate the plan and report available evidence without pretending an Ads mutation completes work in systems it did not change.

Distinguish the requested effect from the user's suggested method. Someone may ask to turn on enhanced lead measurement “by changing the conversion to primary.” Explain that the role mutation affects a different setting and clarify the desired effect before preparing it. If the user explicitly wants both tasks, describe the supported role proposal and the provider setup task separately. A familiar button should not persuade the client that an unsupported operation has become available.

Confirm clear steps and exact targets

For supported edits, show the target and exact action on clear separate lines. A conversion action can use its name, while campaign or group resources should show their real parents. An account field does not need fictional campaign parents, and internal identifiers do not belong in the client label.

One confirmation can cover a supported sequence with clearly separated actions. If the complete request cannot be prepared within the safeguards, explain why it needs narrower proposals before writing. Do not execute a subset silently or hide another business effect in the description of the first step.

State “No changes have been made yet. This proposal expires in 15 minutes.” Confirm and Execute authorises the presented scope. An earlier settings question or consultancy recommendation is not approval for a live mutation.

After confirmation, immediately make the proposal controls inactive and show prominent progress without mentioning the user. Relevant state is rechecked and the request validated before execution. The client should visibly know the click registered while the tool performs its checks.

Verify completed work and preserve remaining tasks

A successful supported edit should prominently show execution and verification, then describe its actual field effect and named target. Validation checks the prepared request, while verification reads the resulting state. Neither should be confused with a test of the client's wider lead lifecycle.

If a write is ambiguous or a sequence is partly verified, reconcile the affected resources before repeating operations. A step may already have succeeded. Report established changes and remaining uncertainty rather than claim the whole tracking process is complete.

The handover should preserve the signal pair, date, selected form, intended later event and each remaining owner task. Another consultant should be able to see what was measured, what was changed and what still needs implementation evidence without reading private customer records or raw payloads.

Close the engagement with a usable next checkpoint. Identify who supplies the next observation, what it needs to demonstrate and which unresolved question it answers. If the account is ready but the import route remains unverified, that is the remaining task; another broad account audit adds little. If every agreed task has adequate evidence, record the achieved scope and any separately requested monitoring. A clear boundary makes the review useful after the conversation ends.

The consultant audit guide provides broader review context. A useful enhanced-lead audit joins narrow provider signals with a real process map, respects output-only and acceptance boundaries, and gives the client a clear path to complete the implementation work without overstating the app's current capabilities.