Use device evidence to locate the decision, not invent its cause
Google Ads device-performance audits for enterprise: compare reported outcomes, isolate campaign patterns and review eligible changes
Read account and campaign device tables with stable metric definitions, investigate the relevant customer journey and turn a justified intervention into an exact supported proposal with clear verification.
Define the enterprise device question
A device-performance investigation should begin with the decision the enterprise needs to make. The team may want to understand where spend and primary outcomes were reported, identify the campaign behind a weak mobile ratio or assess whether a particular booking journey deserves attention. These are related questions with different evidence requirements. A broad statement that mobile performs badly is not yet a target, diagnosis or supported setting change.
Specify the account, date range, desired outcome and reporting scope. “Compare mobile and computer performance for the Service Enquiries campaign over the last thirty completed days” is a useful request. “Fix devices” leaves the population, metric and intervention undefined. The assistant can help turn the latter into a precise question, but it should not invent a commercial target or choose a live restriction simply because one device row has the lowest displayed ratio.
Identify the owner of the business outcome. A campaign operator can interpret reported advertising metrics, while a website team may own an unusable booking form and a service team may own unanswered calls. Device segmentation can help locate an investigation without establishing which owner caused the result. This keeps the enterprise discussion accountable: each team receives a concrete question supported by evidence rather than an accusation derived from one aggregated performance table.
Keep the initial question read-only unless the user requests an edit. Asking which device has the highest CPA does not authorise a bid change or exclusion. Once a justified intervention is identified, establish the exact setting and its supported eligibility before preparing approval. The distinction allows a natural analytical conversation while preventing a reporting result from silently becoming a live action against a broad account population.
Understand the reported device segment
The audit uses Google Ads' reported device segment, with readable rows for mobile, computer, tablet and connected TV where present. Other returned segment values remain part of the reporting population rather than being silently discarded. This classification describes reported advertising activity by device. It is not a list of individual users, physical handsets, browser versions or the full sequence of devices used during a customer's purchasing or enquiry journey.
A mobile-device row is not an app-inventory row. Mobile activity can involve websites and different advertising surfaces. Conversely, an app-category exclusion is an inventory setting with its own account scope. Do not interpret device performance as proof that a particular app category caused the outcome. The enterprise app-category guide explains that separate configuration question and its missing-only account action.
Device also differs from channel, location and product. A campaign can report mobile activity across several channels, serve customers in different countries and advertise several products. The device dimension alone does not identify which of those factors drove the observed conversion value. A useful enterprise analysis keeps each requested dimension explicit and adds another breakdown only when it answers a real missing question, rather than treating one row label as a complete explanation.
Use the provider's measured category without inventing physical-device detail. A client may ask whether a problem occurs on a particular handset or browser; that needs appropriate separate evidence. The current audit table should not be advertised as a website diagnostic or a device-level user trace. It supplies a useful performance grouping, and the organisation can then decide whether the pattern justifies a more specific journey investigation.
Read the account-wide population
The account device reader queries the customer resource with the requested date range and device segment. It collects impressions, clicks, cost, conversions and conversion value, summing returned rows by device through the shared aggregation helper. This is account-wide reported performance over that period. It should not be described as the results of only currently enabled campaigns unless a separately requested selection actually applies that restriction.
The distinction matters when enterprise accounts contain recently paused campaigns or changing campaign families. An account table can include historical activity whose current resource state differs from its earlier state. A present enabled-campaign inventory and an account-wide historical device report therefore have different populations. Keep the report title and explanation consistent with the actual query so a stakeholder does not attribute old spend to a present configuration without checking chronology.
The account view is useful for orientation: which devices carry most of the reported cost, which carry most selected outcomes and whether a large difference deserves investigation. It is not an instruction to apply the same intervention across all campaigns. Enterprise accounts combine offers, budgets, objectives and customer journeys. An account pattern can be commercially important while being driven mainly by one campaign that needs a narrower response.
When the user asks for a current-account fact, use the connected account context already established in the channel. Do not expose the provider customer identifier in every normal response. A readable account label, dates and metric definitions are more useful to the audience. Exact provider identity remains behind the scenes for the query and any later action, while the visible explanation focuses on the reported device population and the next analytical decision.
Locate the campaign behind the pattern
The campaign breakdown reader segments reported performance by campaign and device, using an account-scoped query keyed by campaign identity. The audit can then show the selected campaign's device rows. This supports the question the account table cannot answer by itself: which campaign is carrying the mobile spend or the weaker efficiency pattern? The wider breakdown collection does not issue an independent device query for every selected campaign.
Use campaign identity consistently when combining the rows with the relevant campaign context. Campaign names are for readable output; provider identities are needed internally to avoid mixing similarly named resources. A renamed campaign retains its identity, and two campaigns with related names remain distinct. The user should receive the actual selected campaign name without a raw ID suffix, while the reporting and action framework retains the precise resource reference.
A campaign view narrows the mixture but does not eliminate it. One campaign can contain several ad groups, offers, destinations and conversion actions. If the question concerns a specific group or ad, obtain the appropriate supported narrower evidence. Do not treat a campaign-level mobile ratio as a statement about every child resource. The correct next read depends on the decision, and the shared reporting framework should preserve that resource and measurement scope.
Current configuration still differs from historical performance. A campaign's present device criteria, bidding strategy or status may have changed during the reporting window. Resolve the setting relevant to a proposed edit at the proper preparation stage. A historical table can justify investigation, but it cannot replace the current target and eligibility checks needed before a live change. The account view, campaign view and current setting each answer a distinct part of the workflow.
Keep informational tables out of a failure verdict
The device cards are informational. They hide a pass-or-fail status and do not contribute a device-performance failure to the Issues Summary. This is deliberate: a performance distribution is evidence, not an automatic configuration verdict. A mobile row can have a lower reported ROAS than a computer row without proving that the mobile setting is wrong or that the account should exclude mobile devices.
The table's account-type presentation highlights ROAS for ecommerce and CPA for lead generation. That choice makes the report easier to interpret, but it does not invent a universal acceptable threshold. The organisation supplies its commercial target, selected outcome definition and relevant constraints. A low displayed ratio should prompt the appropriate investigation rather than a claim that the audit has identified a mandatory device correction.
The absence of a device table should also be interpreted through the available evidence. There may be no returned rows for the selected range, or the relevant report may not have loaded. A missing table is not a positive verdict that all devices perform equally or that the account has no device exposure. The unavailable-data handling and the conversational response should keep those circumstances distinct rather than converting silence into a clean result.
This informational approach supports enterprise decision-making because it preserves room for justified exceptions and different objectives. A lower short-term ratio can coexist with a strategic offer or a journey that converts through another selected outcome. The table gives the team a common observation; the organisation decides what question to investigate next. When a live change becomes appropriate, it follows an exact supported proposal rather than an automatic edit attached to a descriptive report.
Inspect the five base metrics
The shared base metrics are impressions, clicks, cost, conversions and conversion value. They establish both exposure and selected reported outcomes. Read them together before interpreting a ratio. A device row with little cost and one attributed conversion has a different evidential weight from a row with substantial activity over the same period. The audit does not turn that difference into a statistical certainty score or declare a winner solely from the largest ratio.
Cost is converted from the provider's micros representation into the working monetary value. Conversions may be fractional under the reported attribution, so they should not be described as a count of unique physical people. Conversion value is the value selected by the Google Ads metric, not an independent feed of bank receipts. These distinctions make the device report interpretable and prevent a client-facing summary from claiming more concrete business evidence than the provider data supplies.
The ecommerce table includes conversion value and ROAS; the lead-generation presentation includes conversion rate and CPA. Both use the same shared underlying metrics. The change in display does not mean one account has a different collection method or that a lead account's conversions are all qualified leads. The actual conversion selection still needs to match the user's question. A useful report names the measure rather than allowing account type to silently redefine it.
Client-facing figures should have no more than two decimal places, with whole-number formatting where appropriate. This limit improves readability without changing the underlying arithmetic. Long decimal strings should not be used to imply precision beyond the reported evidence. Keep values at sufficient internal precision for totals and threshold selection, then format consistently across Slack, the web audit, tables and any requested file.
Calculate totals from summed bases
The All row sums base metrics from the displayed device rows, then calculates the overall ratio from those totals. This is different from averaging the row ratios. A small device row and a large row should not receive equal weight in account ROAS or CPA. The shared performance-table helper keeps this arithmetic consistent between account and campaign displays, so the same data does not produce different totals simply because the user opened another view.
For an illustrative calculation, suppose mobile reports cost of 800 and value of 1,600 while computer reports cost of 200 and value of 800. The row ROAS values are 2 and 4. The combined ROAS is 2,400 divided by 1,000, or 2.4; it is not the unweighted average of 3. These are invented numbers to explain the arithmetic, not a claimed account result or an estimate of the effect of changing device settings.
CPA and conversion rate need the same discipline. Sum cost and selected conversions before calculating overall CPA; sum selected conversions and clicks before calculating the reported conversion rate. Do not average already rounded row values. The denominator determines the meaning of the ratio, and an enterprise summary should preserve it when moving between devices, campaigns or reporting periods. Otherwise an apparently small formatting decision can change the commercial conclusion.
Ratios remain undefined when the required denominator is unavailable or zero. The table uses a missing indicator rather than inventing a zero efficiency value. That missing state should survive exports, charts and conditions. A clear All row helps the team orient its investigation, but it is still a ratio of selected reported outcomes, not proof that each underlying journey or conversion definition is complete.
Keep conversion and value scopes stable
The standard Google Ads conversions and conversion-value measures used by the audit follow their provider reporting selection. In the conversational framework, a request for all primary conversions should include the selected primary actions and exclude secondary actions under that scope. Do not relabel all standard primary conversion value as purchase revenue. Primary non-purchase actions can carry assigned value and contribute to an aggregate value measure.
A purchase-only question needs its explicit purchase selection. A lead question needs the selected primary lead population, without an invented distinction between different lead categories that the business did not request. A named conversion action is another legitimate narrower selection. The assistant should retain the definition through the device breakdown, comparison and follow-up, instead of switching from all primary conversions to purchases merely because ROAS is the displayed account-type metric.
Several primary conversion actions can contribute to the same aggregate. The report adds their selected values; it does not automatically deduplicate separate actions that represent the same business event. That behaviour is distinct from the business's measurement design. A device report is not a hidden deduplication repair tool. If the enterprise requests a conversion-setup investigation, address that separately rather than changing the requested aggregate without explaining the selection.
Record the outcome definition in the decision brief and subsequent report. The enterprise conversion-counting guide discusses another configuration layer, while the conversion-tracking guide covers setup evidence. Stable definitions let the team distinguish a genuine reported device pattern from a difference caused by selecting another conversion population or assigning a different meaning to its value.
Distinguish missing, zero and undefined results
A provider read that fails must not become a table of zeros. The shared aggregator allows the read failure to propagate so the report's unavailable handling can retain it. This matters at enterprise scale, where a transient provider failure could otherwise be mistaken for a sudden collapse in device activity. The assistant should describe the missing evidence and obtain the relevant bounded retry rather than drawing a performance conclusion from a failed collection.
An observed zero is different. A returned row can have no selected conversions despite reported cost, or a selected period can return no device rows. Keep those observations at their actual scope. No returned rows for a period does not certify every device setting, and a zero outcome does not prove a website journey is broken. The result may justify investigation, but the diagnosis needs evidence beyond the numerical absence.
Undefined ratios need their own treatment. With no cost denominator, ROAS cannot be calculated meaningfully under that definition. With no selected conversions, CPA is not a ordinary zero currency figure. A table's missing marker should not be converted into zero when a chart or threshold filter is built. Doing so would incorrectly rank the row and could produce an unjustified proposal to restrict a device that simply lacks a defined comparison value.
Keep any partially available report explicit. If Google Ads rows are returned but the requested Analytics comparison is unavailable, retain the known advertising evidence and explain the missing comparison. Do not invent daily Analytics values or throw away a valid read to create a generic failure answer. The next read should resolve the specific missing source, metric or grain. Clear missing states make the analysis both more useful and more reliable.
Preserve period and time-zone meaning
Use the requested date window consistently across all device series. Rolling periods, calendar months and the current configured period are different requests. A user asking for last thirty days should not receive last month because a dashboard retained an older selection. The report needs explicit start and end dates resolved under the relevant account-local convention, with completed-day handling consistent with the metric request.
Current configuration and reported historical activity remain different layers. The present bidding strategy or device criterion may not have been in place throughout the range. When a pattern begins around a setting change, record that chronology without assuming causation. The enterprise change-history guide explains the bounded history evidence and why a current setting read cannot reconstruct every previous configuration state.
Do not compare a full mobile period with a shorter computer period or silently omit dates from one source. If a requested source has incomplete daily evidence, preserve that missing state. A table may be more honest than a chart that visually implies aligned observations where some were never returned. The enterprise audience should be able to identify what period each metric covers without reading provider query syntax.
Follow-up evaluation also needs stable periods and appropriate context. A week after a change can differ from a holiday week before it for reasons unrelated to device settings. Choose the comparison in advance and note concurrent offer, budget and website changes. The verified setting result remains a separate fact. A later performance comparison can support a business decision without being presented as automatic proof that the edit caused the entire observed change.
Separate device effects from campaign mixture
An enterprise account combines campaigns with different purposes. A strong computer ROAS can be driven by brand activity while mobile cost comes mainly from a broader acquisition campaign. The account device table may reflect that mixture rather than a device-specific failure. Move to the campaign breakdown before deciding whether the same intervention belongs across the account. A broad aggregate should locate the question, not flatten distinct commercial roles into one verdict.
Even within a campaign, offers and destinations can differ. One ad group may send users to a short enquiry form while another leads to a complex product configurator. If the campaign's mobile pattern deserves attention, identify the relevant narrower evidence and journey. Do not claim the device itself explains a conversion difference without examining the offer, traffic context and selected outcome. The report is descriptive evidence, not a causal experiment.
Device shares can change when the campaign mix changes. Pausing a campaign with high computer value can reduce account ROAS even if every remaining campaign's device performance is unchanged. Likewise, adding a new mobile-heavy campaign changes the account distribution. Retain base metric totals and resource scope when explaining those changes. Comparing only percentages or ratios can conceal the actual activity shift that the organisation needs to understand.
Separate commercial importance from metric rank. A device carrying less selected value may still serve a meaningful customer use case or a different primary outcome. The organisation should decide which objectives belong in the evaluation, and the assistant should apply that selection consistently. An account mixture analysis is useful when it explains the observed pattern with relevant evidence; it should not become an excuse to dismiss a real underperforming journey without investigating it.
Investigate the relevant customer journey
A weak mobile result can justify inspecting the intended landing page and customer action. The possible issue may concern offer clarity, form usability, page routing or an operational handoff. The device table does not test any of these. Define the journey that needs examination, including its entry destination and intended outcome, and assign the relevant owner. This keeps the investigation concrete instead of turning every device difference into an immediate bidding recommendation.
Use supplied context for creative reasoning where possible. The assistant can suggest clearer copy, a shorter explanation or a revised call to action without fetching unrelated account data. Those suggestions are ideas, not observed performance improvements. If the user wants the current ad or destination, obtain the exact relevant resource. If a website change is needed, do not claim the advertising tool can publish that release merely because it helped formulate the recommendation.
Destination configuration is also different from journey behaviour. A syntactically valid HTTPS URL does not prove that the page loads correctly on a device, preserves measurement identifiers or supports the promised service. The enterprise tracking-tag guide explains another bounded configuration check. A device investigation should retain the separate evidence for destination fields, actual page behaviour and received measurement events.
When the intervention concerns an ad, inspect the actual supported editor and its side effects. A dedicated RSA replacement can replace the full creative set, remove pins, clear omitted display paths and retain serving status. It should not be described as a harmless single-sentence patch. A justified journey diagnosis still needs a precise supported operation and explicit approval before the assistant changes a live advertising resource.
Include calls and offline outcomes deliberately
A mobile enquiry journey can involve calls rather than a website form. Primary call conversions can be selected in Google Ads reporting and can carry assigned value. If the enterprise's intended outcome includes calls, keep them in the defined aggregate. If it wants website submissions only, select that scope explicitly. The device segment does not itself establish that a call was answered, qualified or commercially valuable beyond the selected reported action.
Offline conversion actions can also appear in the relevant Google Ads conversion inventory and reporting selection. Their offline origin and business category are different descriptive dimensions, and they can overlap with a lead or purchase grouping. Do not create mutually exclusive totals by adding overlapping category and origin populations. When the user asks for offline actions, list the actual available actions under the requested scope rather than assuming that an offline measure cannot be reported.
Neither calls nor offline outcomes automatically have a GA4 pair. A business may record a website call click, a connected call or a later CRM outcome as separate events with different meanings. Ask for the specific corresponding event when a comparison is requested. The assistant can use available event names to suggest a likely candidate, but it should not declare equivalence solely because a name contains call or lead.
Operational evidence may still be required outside the advertising API. The device table does not contain call recordings, staff availability, CRM notes or a complete customer identity history. Use the enterprise call-asset guide for the related configuration review. Preserve the distinction between reported call conversions, configured call assets and actual service outcomes so the device analysis does not overstate what the tool can see.
Select a meaningful Analytics comparison
Cross-source comparison can be useful when metric meanings and scopes are explicit. Google Ads primary conversion value and GA4 purchase revenue can be shown as requested revenue-related series while their definitions remain different. Purchase-only selections provide another narrower comparison. The assistant should not block a useful chart merely because the sources use different names, but it also should not label different populations as identical business events.
For leads, select the corresponding GA4 event. Available event names can guide a suggestion, followed by confirmation of the intended business meaning. For aggregate conversions, the requested Google Ads primary conversion population and GA4 key-event population need their own clear selection. A named Google Ads action can be compared with a named GA4 event. Device segmentation should then preserve those chosen outcomes rather than silently replacing them with a generic total.
Keep the requested source filters and dates aligned. An all-traffic Analytics revenue series differs from one restricted to the intended paid traffic population. All-traffic revenue divided by selected advertising cost is blended ROAS or MER, while a Google-only attributed calculation answers a different question. Name the selected definition in the response. A device report should not force one interpretation when the user explicitly asks for another valid reporting scope.
Do not assume device categories, attribution treatment or event populations produce equal totals across systems. Establish compatible labels and the intended comparison, then retrieve the required grain. If a source cannot supply the requested detail under the available tool, resolve that data requirement or explain it specifically. Do not manufacture points or declare the entire request impossible because one predefined pair was too narrow for the user's legitimate comparison.
Apply exact conditions to supported data
A request such as “show devices with CPA at or above the target and cost above the minimum” contains two conditions and a logical intersection. The assistant should preserve both operators and the selected outcome definition. At or above is not the same as above. AND is not OR. These semantics belong in the common reporting and selection framework so they remain correct across account, campaign and other supported resource populations.
Threshold conditions should use the underlying metric precision, with display rounding applied afterward. A ratio slightly above a threshold should not be excluded because its two-decimal label appears equal. Undefined ratios also need their proper state rather than being substituted with zero. This matters when the result may later identify targets for a live proposal. Selection should follow the declared condition, not a visual approximation of the displayed table.
Conditions do not establish causal certainty. A device row can meet the requested low-performance threshold without proving which setting should change. The user may ask to investigate qualifying rows, and that remains a read-only task. If the user requests an edit, translate the selected targets into a supported action only after the relevant current setting, resource scope and eligibility have been checked. Do not infer an automatic exclusion from the filter alone.
When a requested condition depends on unavailable data, identify the missing metric or population. A device report cannot evaluate a CRM qualification rate it never received. The assistant can obtain another supported source when appropriate, but should not invent a proxy and silently apply the original condition to it. Exact conditions are useful only when their inputs are equally explicit and remain consistent through selection, explanation and approval.
Choose readable tables and native charts
A table is often the clearest device comparison because it keeps base metrics and ratios beside the device label. The All row supplies the relevant total without requiring the reader to reconstruct it. A requested chart can highlight distributions or trends, but it should answer the actual question. Cost share, outcome share and efficiency are different views, and one should not be silently substituted for another because it is easier to draw.
Use one native Slack chart for compatible requested series within the supported readable limit. Two or three related metrics should not become separate charts by default. When the measures use different units, make those meanings visible and choose an appropriate supported presentation rather than suggesting the numbers have the same scale. A chart is a communication asset generated from the selected data, not an additional source of performance evidence.
Long time series need deliberate grain. Prefer weekly or monthly aggregation when the user has not required daily detail and the native point capacity would otherwise split the report. Preserve ratios by aggregating their base values rather than averaging daily ratios. If explicit daily detail requires more than one native chart, explain the point constraint and split coherently. Do not surprise the user with disconnected partial-period outputs or replace a native chart request with an image.
Keep labels readable: current-year dates can omit the year, older-year dates should retain the necessary distinction and weekly labels should show the actual date range. Display no more than two metric decimal places. Place the user mention before the feedback section in the normal final conversational reply. Good presentation should make scope, dates and metric meaning easier to assess while keeping feedback text and controls at the end.
Follow an illustrative enterprise diagnosis
Consider an invented enterprise, Alder Booking Network, and its acquisition lead, Mara Finch. Mara notices that account-wide mobile CPA is higher than computer CPA during a selected completed-day period. She asks for the campaign device breakdown rather than immediately excluding mobile. The returned evidence shows that a new installation campaign carries much of the mobile cost, while a mature brand campaign contributes many computer enquiries. This is an illustrative example, not a customer result.
Mara preserves the primary enquiry definition and compares the relevant campaign before drawing a device conclusion. The installation campaign's mobile pattern remains worth investigating. The website owner examines its intended booking journey, while the advertising operator checks the exact ad and destination configuration. The assistant can help brainstorm clearer instructions from that supplied context without calling Keyword Planner or claiming that its wording suggestions are proven conversion improvements.
The team identifies a justified ad-content intervention rather than assuming a bid modifier will solve the journey. It prepares the supported exact ad operation and reviews its complete effects, including replacement creative and retained status. If a device-setting change is considered separately, the operator first establishes campaign and bidding-strategy eligibility. A low CPA rank is evidence for investigation, not permission to apply a setting that the provider does not support under the current strategy.
After an approved advertising change, the relevant fields are read back and the result is reported prominently. Mara records the execution date and schedules a stable follow-up comparison, noting the concurrent website work and campaign mix. The team does not attribute every later improvement to the ad edit. The useful result is a narrowed diagnosis, a verified configuration intervention and an accountable evaluation of the selected enquiry outcome.
Establish device-edit eligibility
A device performance row is not itself a writable setting. A proposed intervention must identify the actual resource and supported operation. Google's bid-adjustment guidance describes device adjustments and their campaign and bidding-strategy restrictions. Manual-style adjustments are not universally effective under automated strategies, and some supported device exclusions differ from ordinary positive or negative adjustments. Check the current strategy before presenting the action.
The same official guidance distinguishes a Target CPA device target adjustment from a simple bid adjustment and explains campaign-versus-ad-group interactions. Those details are reasons to inspect the relevant setting and parent scope, not to apply a generic percentage everywhere. An enterprise request should name whether it intends an eligible campaign criterion or group-level setting, and the assistant should explain the concrete effect supported under the selected resource and current configuration.
ppctor's local typed API catalogue can describe available resource operations, fields and dependencies without injecting every schema entry into every conversation. That discovery is a capability declaration, not evidence that a particular account's strategy accepts the requested change. The preparation framework validates typed fields and precise references, while provider checks address the applicable live constraints. Do not advertise universal device editing merely because a field exists in the schema.
If the requested operation is unsupported for the actual campaign or strategy, stop before live execution and explain the specific restriction. Do not substitute a campaign pause, app-category exclusion or broad budget change without the user's decision. A supported alternative may be worth discussing, but it has its own target and effects. The enterprise benefits from an honest capability boundary more than from an apparently helpful edit that implements a different action.
Use local capabilities and focused reads
The shared dependency framework should determine the relevant resource relationships locally before provider discovery. An account report needs its connected account and requested metric grain. A campaign setting needs the selected campaign, while a group setting needs its actual campaign parent. An ad operation needs the ad and its true parent chain. These distinctions prevent a device-performance question from triggering unnecessary keyword, asset-group or product-feed discovery.
Use the reporting data already collected when it answers the question, and obtain only the missing scope or grain. The audit's campaign breakdown collection is shared across selected campaigns rather than growing one device query per campaign. A conversational follow-up should likewise preserve valid target context instead of repeatedly asking which campaign was just discussed. Refresh relevant live state at preparation or execution where required, without confusing that necessary check with broad repeated inventory reads.
The typed API discovery table is code-local and can answer which operations and dependencies exist without a provider call. Current external settings still require the appropriate read. This separation is useful at scale: the assistant can reason about capability and sequence cheaply while limiting Google Ads requests to evidence that genuinely depends on the connected account. Local metadata is not a substitute for authorisation, ownership checks or provider validation.
Multi-step actions need explicit dependency ordering and supported references. An ad creation, group enablement and campaign change are distinct logical effects, even when they share context. Unsupported combinations should be rejected at preparation rather than executed partially without explanation. The enterprise segmentation guide discusses related parent and creation rules. A common framework keeps these relationships maintainable instead of creating a special device workflow for each phrasing.
Present the exact intervention before approval
The confirmation must show a readable target and the exact intended action. For a device-setting request, identify the campaign or actual group parent and the selected device, then state the precise supported change. For an ad intervention, identify the ad, ad group and campaign and disclose all replacement effects. Do not include raw asset IDs in normal labels or invent a group as its own parent. The message should be understandable without reading API JSON.
Separate logical actions into prominent steps when a request includes several effects. A new ad is not automatically enabled, a group enablement is not a campaign enablement and an inventory restriction is not a device adjustment. The user should see these distinctions before confirmation. If the complete request exceeds the current safe proposal scope, ask for smaller requests rather than silently dropping later actions or performing only the subset the builder happens to support.
Use the concise notice, “No changes have been made yet. This proposal expires in 15 minutes.” The authorised person's Confirm and Execute click is the boundary for live mutation. Until then, the assistant is preparing a reviewable request. Analytical discussions, creative suggestions and reports remain behind the scenes as conversation; they should not be logged or presented as executed Google Ads changes merely because they informed the proposal.
After the click, show an immediately visible change-in-progress state and make the original button unavailable for another submission. Do not rely on a subtle spinner to communicate that an operation is running. The progress message should not mention the user. A clear state transition reassures the person that the click was received while preserving the distinction between processing and the later verified result.
Verify settings without promising uplift
Validation checks whether the prepared operation is acceptable; verification reads the relevant intended result after live execution. Both matter, and neither replaces the other. A validated request has not changed the account. An accepted provider response should not be labelled independently verified if the appropriate state was not checked. Use the actual verification mode for the selected supported operation rather than treating every API acknowledgement as proof of final completion.
A prominent Executed and Verified message should show the achieved setting or resource result with readable targets and clear per-step effects. If the operation changed creative rather than a device criterion, say that. If several logical actions were requested, report each verified effect separately. The result proves the observed advertising configuration, not improved conversion rate, policy approval, landing-page usability or a causal performance benefit.
When a live result is not fully verified, reconcile the exact affected resource before retrying. A repeated creation can produce duplicates, and a replayed update can overwrite a newer external change. Report what was completed, failed, unverified or not started. This lets the enterprise operator decide what remains without guessing whether the account changed. A generic failure label should not erase an accepted operation's possible effect, nor should a partial result be called complete.
Keep the final user mention before the feedback section, with feedback controls last. The client-facing result should not expose provider resource names or internal storage keys. It should make the action's state obvious and preserve any remaining limitation. A precise verified configuration message is valuable evidence even when the business effect still needs evaluation; adding an unsupported uplift claim would weaken rather than strengthen that result.
Evaluate the subsequent outcome separately
Define the follow-up metric and window before examining the new results. Preserve the original outcome selection, device population and campaign scope where the comparison requires them. A change from all primary conversions to purchase-only value can alter the ratio independently of the intervention. A campaign mixture change can do the same. The enterprise team needs a stable comparison to assess what happened without attributing a definition shift to a setting edit.
Record concurrent changes in budget, offer, creative, destinations, measurement and operational capacity. They can explain observed differences or limit a causal conclusion. The device report remains useful even when the evidence does not isolate one cause. State the observed performance change and the relevant context, then decide whether further action is justified. Do not promise that a verified device or ad setting will necessarily improve every commercial metric.
Monitoring and scheduled Rules require separate explicit configuration. A conversational confirmation does not authorise continuous future device adjustments, campaign pauses or budget changes. The enterprise alerts guide addresses monitoring as its own workflow. Keep the one-time edit, ongoing reporting and any scheduled action distinct so the organisation understands what the application will actually do after the current conversation ends.
Revisit the decision when the campaign's bidding strategy or business purpose changes. A previously eligible intervention may need a new review under the current strategy, and an older device pattern may no longer represent the account's present offer mix. Read the relevant current setting before preparing a new live proposal. Historical results support the discussion, but they do not provide permanent authority to repeat an old action under different conditions.
Hand over a maintainable device decision
The handover should connect the selected device evidence, campaign scope, outcome definition, diagnosed question and actual intervention. Keep observations and interpretations separate. The account table located a pattern; a narrower report or journey investigation explained what needed attention; a supported proposal stated the change; readback established its configuration result. These steps should remain visible without turning the client explanation into a long technical transcript.
Give the next owner the dates, metric selection, readable target and reason for the decision. Retain the relevant missing evidence and follow-up responsibility. Internal IDs can stay in operational evidence, while client-facing output uses names and actual parents. A future operator should be able to understand why the action was chosen without assuming that the lowest device ratio always requires the same intervention.
Use consistent definitions across Slack, the web audit, charts and files. A device row should not become an app category in an export, and an undefined ratio should not become zero in a graph. Totals should continue to use summed bases, and date labels should remain faithful to the period. Consistent presentation lets the enterprise discuss the evidence across teams without accidentally changing the measure being compared.
The durable result is an evidence-led device decision with a known scope and an accountable next review. ppctor supplies the reported metrics, shared capability planning and approval-based execution for supported changes. The organisation supplies the commercial objective and external journey ownership. Together those boundaries let the team act precisely while preserving the difference between a verified advertising setting and a separately evaluated business outcome.