Use device evidence to coordinate acquisition and customer experience
Google Ads device-performance audits for in-house teams: investigate the journey before changing bids
Read the account breakdown accurately, preserve conversion definitions and distinguish a device pattern from its cause. Give media, analytics and web owners a focused decision with clear evidence and approval.
Choose the decision the comparison should support
A device-performance audit should help an in-house team decide what deserves investigation or change. It can reveal that mobile produces most conversions, that computers deliver more conversion value or that a small tablet segment has uncertain results. None of those observations supplies a cause by itself. Begin with the owner's question: whether a landing-page problem needs attention, whether a campaign's distribution fits its goal or whether the current measurement captures the intended outcome. The device table becomes useful when it serves that decision.
Avoid starting with a universal target for device share. Customers may research on one screen and complete an action on another, while different offers naturally attract different environments. A business that receives phone enquiries can have a different mobile journey from a business selling complex equipment through an online checkout. The right review concerns the intended customer experience and measurable outcome. More desktop revenue does not automatically imply that mobile should be excluded, just as more mobile conversions does not automatically justify increasing a bid.
Record the decision scope before collecting additional data. An account-wide overview can identify a pattern worth examining; a campaign-specific action needs evidence for that campaign and its applicable controls. Name the period, outcome definition and business owner. Then establish what would make the team change its current treatment. This avoids an open-ended investigation that retrieves every available report without resolving the original question. It also makes the eventual proposal easier to assess because colleagues can see how the selected evidence relates to the decision.
Understand the current device reader
The current account reader queries the customer resource segmented by device. It selects impressions, clicks, cost, conversions and conversion value for the requested date range. The integration groups returned rows by the device key and sums the selected measures. This gives an account-level advertising performance breakdown. It does not read browser behaviour, customer identity, phone transcripts or a list of website usability problems. The device label describes the reporting segment, while the reason for a difference remains a separate investigative question.
The reader's date condition uses the account timezone supplied to the integration. Its default range is the last thirty days when a caller does not provide another selection. A particular audit can use a different chosen period. Keep that actual period with the output instead of assuming every device table has the same dates. A date range is part of the evidence, not decorative metadata. Comparing a recent Slack request with an older dashboard view requires aligned dates before colleagues interpret different totals as a tool error.
The account device query has no enabled-campaign filter. Its historical metrics should therefore not be described as results from only the campaigns enabled today. Current campaign status and historical activity are different facts. A separate campaign breakdown reader groups device metrics by campaign, also using a date condition rather than an enabled-only filter in its device query. The team should select the population it actually intends to analyse and retain that boundary when moving from the account overview to an individual campaign investigation.
Preserve the historical population
A paused campaign can contribute to a historical period if it served during that period. Excluding it because it is paused now changes the analytical population. Sometimes the owner wants exactly that current-enabled subset, but it must be an explicit request with appropriate evidence. Do not relabel the account overview after looking at current statuses. The device card answers a historical performance question using the returned account rows. It does not reconstruct what the account would have looked like if today's enabled inventory had always been the only inventory.
Account totals also combine different offers and campaign purposes. A brand campaign, a prospecting campaign and a product programme can have different device distributions. That mix is useful for understanding the business overall, but it can obscure the decision at a narrower level. A strong account-wide mobile result does not prove that each campaign performs best on mobile. Preserve the aggregation while deciding which follow-up is justified. The next read should answer the specific campaign or outcome question, rather than replace the overview with an unrelated selection.
Keep missing and excluded populations visible when reporting a filtered comparison. If the owner asks for one campaign or only primary calls, state that scope. If a provider view cannot supply the requested breakdown, do not fill it from account averages. A device segment belongs to its source, date range and measure definition. Respecting those boundaries allows the assistant to combine compatible data intentionally while preventing misleading joins. The in-house team can then compare results confidently without wondering whether the same label represents a different population in each reply.
Interpret the table and its total
The device card presents the returned categories in a preferred order: mobile, computers, tablet, connected TV and other. Additional returned keys follow that list. It includes only keys present in the data rather than manufacturing every category with zero metrics. The table's All row sums the displayed row measures before calculating the derived performance columns. This total describes the returned device population. It is not a separate count of unique people or proof that every possible device category produced activity during the selected period.
For an ecommerce-classified account, the table shows conversion value and ROAS alongside the common activity measures. For a lead-generation account, it shows conversion rate and CPA instead. These are presentation choices based on the account type. The underlying reader still selects conversions and conversion value. A colleague should understand which metric is being shown before interpreting a good or bad result. The table does not switch the underlying conversion selection to purchase-only simply because the displayed account-type metric is ROAS.
The shared table formats costs with a dollar symbol, which does not independently establish the account's currency. A current account-currency check is necessary when the distinction matters. Conversions can be fractional in the provider's reporting, and the table rounds their display. Ratios should use the underlying summed measures, as the total row does, rather than rounded visible values. These details help colleagues interpret the report correctly without turning the page into an implementation guide. The central rule is to retain the measure, scope and units behind each displayed number.
Distinguish volume leadership from efficiency
The card's summary leads with overall ROAS for an ecommerce account or overall CPA for a lead-generation account when the required totals are positive. It also identifies the device with the most conversion value or the most conversions, respectively. Most value and most conversions describe volume leadership. They do not identify the best ROAS or lowest CPA. That distinction matters when a reader turns a short summary into a recommendation. The largest contributor can have weaker efficiency while still producing most of the total outcome.
Read the relevant ratios alongside scale. A device with a small number of conversions can have an attractive CPA that is not yet a reliable basis for a broad change. A large segment can have a less attractive ratio but contribute outcomes the business needs. The audit card is informational and hides an ordinary pass or fail treatment. It does not impose a universal device benchmark or supply an automatic corrective action. The owner should interpret the pattern through the account's goals and the quality of the available evidence.
Use precise language in the conversation. Say mobile contributed the most conversions when that is what the summary established. Say computers had the highest reported ROAS only after comparing the relevant ratios within the agreed population. Avoid calling one device the winner without defining the criterion. A ranking request should resolve the metric, any meaningful thresholds and the scope before selecting a target. This is a general analytical requirement, not a special rule that should be patched separately for every new phrasing of a device question.
Separate loading, missing and zero values
The account performance reports can load after the core settings audit. While that stage is pending, the device card reports loading rather than a completed set of zero metrics. The integration throws on a provider failure so the surrounding report fetch can record the problem. This distinction prevents a spending account from appearing to have no device activity merely because a read failed. A successful empty result is also different from an unavailable section. Keep the retrieval state attached to the interpretation.
A missing device row is not automatically a measured zero for that device. The reader includes present keys, and an absent row supplies no direct evidence about a hypothetical unreturned category. Within a returned row, a zero denominator makes some ratios undefined. The table displays a dash for CPA when conversions are zero and does not present a valid ROAS without positive cost. Do not replace those states with an impressive zero or an infinite performance figure. The business conclusion should follow the available measure rather than a display convenience.
If the user asks why the report could not be completed, investigate the relevant read rather than speculating about account performance. A provider error, an unfinished deferred report and a genuinely empty period require different responses. Re-fetch only what is necessary to resolve the state. Repeated whole-account discovery does not make an unavailable device metric more trustworthy. Once the section is available, report the actual period and population. That gives the user a verified answer while avoiding both false reassurance and unnecessary provider traffic.
Define conversions before comparing devices
The audit reader uses the standard conversions measure. A total primary-conversions question should include the intended primary actions and exclude secondary actions. Those actions can represent purchases, leads, calls or other outcomes. The table's generic conversion heading does not establish that every counted action has the same business meaning. Before drawing a recommendation from device CPA, establish whether the selected actions match the owner's objective. A low CPA for a broad aggregate can conceal a different mix of outcomes from the one the business wants.
A request for a named conversion action needs that action's evidence rather than a renamed total. For example, comparing completed contact-form conversions across devices differs from comparing every primary conversion. Preserve the distinction in both tables and charts. If the owner wants leads aggregated across lead categories, use the agreed primary lead scope without creating separate universal quality tiers from category names. Qualified-sounding names can help identify an action, but they do not prove the underlying business qualification process. The metric definition must come from the selected conversion setup.
Calls and offline conversions deserve the same clarity. Primary calls can carry value, and imported offline conversions can be visible to reporting tools. Their availability in the account does not mean the compact device card lists their individual sources. A follow-up asking which offline actions exist requires a suitable conversion-action read. A cross-source lead comparison requires the corresponding GA4 event to be selected. Keep the report framework flexible enough to retrieve named measures while retaining a stable definition, instead of inventing a dedicated answer for each conversation example.
Keep revenue and return definitions explicit
Standard primary conversion value can include values assigned to non-purchase actions. If the owner asks for all primary revenue values, the report should retain that intended aggregate. If they ask for purchase-only value, use the appropriate purchase selection and label it accordingly. The device card's ecommerce presentation does not perform that narrower selection by itself. Do not describe its conversion value as a provider-confirmed purchase-only measure without checking the underlying scope. A familiar business label can hide a substantial difference in what is counted.
GA4 purchase revenue is another defined measure. It can be compared alongside an appropriate advertising value series when the user requests the comparison, while the explanation preserves source and scope differences. An identical currency unit does not erase attribution or event-selection differences. The tool should be able to select compatible measures through the general reporting catalogue rather than forbid a useful comparison merely because sources differ. At the same time, it should not silently relabel total advertising conversion value as identical to every GA4 purchase definition.
All-traffic revenue divided by advertising cost is blended ROAS or MER. It answers a broader business question than device-specific advertising ROAS and should be named that way. If the owner requests device-level blended measures, establish whether compatible revenue and cost populations are available at that breakdown. Do not divide a device-specific cost by unrelated all-account revenue and present the result as a comparable device return. The formula is easy; the analytical scope is the part that makes it meaningful.
Use the right dates and outcome maturity
Use the user's requested date window consistently. Last thirty days is a rolling period, while last month is a calendar period. Yesterday depends on the relevant timezone. State the actual included dates when the distinction matters and avoid substituting the dashboard's saved selection for a fresh conversational request. A date mistake can change both device mix and outcome totals. The owner should not need to discover from chart labels that a rolling request became a calendar-month comparison or that a recent completed day was omitted.
Recent outcomes can mature after their initial advertising interaction. A device comparison over a very recent period may therefore change as conversions are reported or adjusted. Keep that timing consideration separate from a tool retrieval failure. A reported zero is an observation for the selected evidence at that time, not a prediction that no further outcomes will be attributed. Choose a period suited to the decision and record any comparison limitations. The team can then evaluate meaningful changes without treating the newest ratio as a complete final result.
Use comparable periods when assessing a website or media change. Keep outcome definitions, device scope and date handling stable, and note material campaign or offer changes. An improvement after a release does not establish that the release caused all of it. Seasonality, demand and distribution can also change. The point is not to avoid decisions; it is to make the evidence supporting them clear. A focused before-and-after review can be useful without being presented as a controlled experiment or a guaranteed causal explanation.
Investigate campaign and channel mix
Account-level device differences can reflect campaign mix. A campaign focused on immediate calls may attract more mobile activity than a programme selling a considered purchase. Combining them can produce a device ranking that says more about offer distribution than device effectiveness. If the owner wants to change one campaign, inspect that campaign's relevant metrics before selecting an action. The account overview can identify where to look; it should not be used as though every campaign inherits the same ratio and the same commercial context.
Channel mix can matter in the same way. Device categories do not describe whether an impression appeared in Search, video or another advertising surface. A connected TV row is not interchangeable with a computer search row simply because both are devices. Request the additional breakdown needed for the question, preserving provider field compatibility and report availability. Do not pretend that two separate marginal tables automatically provide a complete joint device-by-channel view. The framework must retrieve compatible dimensions together when that combined evidence is required.
Follow the smallest useful sequence. Begin with the returned pattern, select the relevant campaign or channel question and request the necessary detail. Avoid reading every campaign's full configuration merely to explain which device contributed the most conversions. Current settings become relevant when preparing an actual edit. Keeping investigation and preparation distinct reduces unnecessary work and helps the owner see why a particular read was needed. It also leaves the assistant free to answer explanatory questions from already supplied context without repeated provider calls.
Review the customer journey on each device
A device pattern can justify reviewing the experience customers receive, even before a bidding change is considered. The web owner can inspect the relevant destination, form or checkout under representative device conditions. The product or service owner can confirm what a successful journey should look like. These checks should address a concrete concern, such as a difficult form step or an offer detail hidden on a smaller screen. The device table does not observe those defects, so the investigation must establish them directly.
Choose tasks that reflect the advertised promise. A mobile visitor seeking a service quote should be able to find the relevant information and complete the intended request. A customer buying equipment may need clear specifications and delivery details. A desktop test and a mobile test can reveal different practical barriers. Record the page, scenario and observed behaviour, then assign the issue to the owner who can change it. Avoid assuming that a lower reported conversion rate proves poor design before the journey has been examined.
Retain the distinction between a website fix and a Google Ads mutation. The assistant can help draft a testing plan, summarise findings or prepare a supported advertising edit, but a media action does not publish a website release. The in-house team should track the external implementation separately and test it after deployment. If the agreed remedy is a form correction, do not invent a device bid action merely to provide an executable button. The correct next step follows the diagnosed problem, even when its owner works outside the advertising account.
Test the relevant measurement behaviour
A measurement difference can also influence device results. Test the specific outcome the business intends to record and the relevant journey conditions. A form may submit successfully while its expected event fails, or an event may fire before successful completion. The device table cannot tell the team which situation occurred. The analytics and web owners need a controlled test with an explicit expected action and destination. Keep the test focused so it resolves the observed concern instead of producing a large collection of screenshots with no acceptance criterion.
Consent states, redirects and separate mobile destinations can change the route that collection follows. These should be tested where relevant to the request, without treating one successful scenario as proof of every combination. A manual URL-parameter audit is also a different check from browser event testing. Clean URL labels do not prove that a purchase event fired correctly, and an installed tag does not prove that the intended value was sent. Each evidence source should support its own conclusion rather than being promoted into a universal tracking certificate.
Keep sensitive diagnostic material out of ordinary Slack output. The team needs a readable summary of the scenario, observation and required correction. Private identifiers, customer details and raw event payloads belong in an appropriately restricted diagnostic record when they are needed. A normal conversation should not expose them merely because a tool returned them. The final decision can state that the tested mobile journey did or did not produce the agreed event. That is concrete evidence, with a scope colleagues can understand and verify.
Assign one decision across several owners
The media owner coordinates the device review, but the remedy can belong to analytics, engineering or the business unit. Name the decision owner and the implementation owner separately. The person who understands a campaign's goal may not be able to change a checkout, while the engineer who can fix it may not know which conversion matters commercially. A concise shared task should connect the observed pattern, the confirmed issue and the acceptance test. This makes the handoff useful without requiring every colleague to read the full account audit.
Prioritise according to evidence and business relevance. A confirmed barrier on a high-volume journey can merit urgent work. A small segment with limited outcomes may need observation rather than a release. The device ratio alone should not determine engineering priority. Include the relevant scale and the customer behaviour established during testing. Conversely, do not postpone a clear measurement defect because its current reported conversion count is low; the defect itself can explain why the count is unreliable. The investigation should inform priority, not merely repeat a ranking.
Record what will count as completion. A website task may require a successful representative journey and event check. An advertising-setting task may require exact provider readback. A reporting task may require a corrected definition and reproducible query. These are different acceptance criteria. Keeping them visible prevents a team from declaring the entire device problem resolved when only one contributing task finished. The in-house workflow becomes reliable when each owner can demonstrate the result relevant to their responsibility and the decision owner can assess the remaining work.
Follow an invented in-house investigation
The following is an invented example. Esme Vale manages paid acquisition for Willow Desk Supplies. The account table shows that mobile contributed the most conversions, while computers had a stronger reported return. Esme does not conclude that every mobile campaign should be reduced. She defines the relevant purchase measure and selects the campaign behind the immediate question. The analyst checks its device results for the same period. This narrower evidence helps the team decide whether the account-wide pattern applies to the offer they intend to change.
The web owner tests the advertised product journey and finds that a delivery-information panel is difficult to use on the selected mobile layout. The analytics owner separately confirms the intended purchase event behaviour in that tested route. The team assigns the interface correction to engineering and retains the current media treatment while the fix is reviewed. They do not turn the account's device ratio into a causal estimate of lost orders. The observed interface problem and the advertising pattern are related investigative evidence, with different levels of certainty.
After the release, the team verifies the corrected journey and records the implementation date. They review subsequent campaign results using the same outcome definition and note other material changes. The example demonstrates a disciplined sequence, not a guaranteed improvement. Another investigation could find that the journey works and the difference reflects campaign mix. The important pattern is to move from a descriptive device table to focused evidence, assign the actual remedy and keep technical completion separate from later business evaluation.
Check bidding eligibility before proposing adjustments
A device performance difference does not establish that a manual bid adjustment is supported or useful. Google documents different bid-adjustment behaviour by campaign type and bidding strategy. Smart Bidding already considers auction context, and ordinary manual adjustments are not applied uniformly under those strategies. Target CPA device adjustments have a distinct target-related meaning, while some strategies permit only a full device opt-out in the relevant context. Check the current eligible operation before proposing a percentage change. Google's bid-adjustment guidance documents these distinctions.
The device audit card does not read the campaign's current bidding strategy or existing adjustment fields. Those settings need a separate current read when an edit is actually being prepared. Do not infer eligibility from the presence of a device row in reporting. Reportability and writability are different capabilities. A campaign can produce device metrics without supporting the same adjustment mechanism as another campaign. The workflow should select the correct supported operation from its capability rules and then verify the relevant current account facts.
A percentage must also have a clear meaning. An adjustment value can differ from the multiplier stored internally, and an exclusion can differ from a modest reduction. The user-facing proposal should state the intended business action in readable terms. It should not ask the owner to decode an internal bid modifier. If the desired control is unavailable for the selected campaign and strategy, explain the actual limitation and a relevant next step. Do not prepare a superficially similar operation whose effect differs from the user's instruction.
Distinguish device controls from inventory controls
Mobile device reporting is not the same as mobile app placement reporting. A mobile row can include activity outside apps, and an app-category exclusion does not disable the entire mobile device category. Keep these controls separate when interpreting a follow-up. A user concerned about in-app distribution should receive the relevant inventory analysis or supported exclusion proposal. A user asking about device performance needs the device measures. Shared words such as mobile should not cause the assistant to choose the wrong target type or imply that one control solves both questions.
Product exclusions form another independent structure. A Performance Max asset group's listing tree or a Shopping ad group's product grouping can exclude products while the campaign still serves on several devices. Those product decisions do not follow directly from an account device table. If the user asks for products with a particular performance condition, the framework needs the relevant product-instance and performance evidence. It should not use aggregate device ROAS to classify individual products. A general reporting and editing system must retain the resource relationships that make each action meaningful.
Likewise, a website layout change, an advertising device control and a placement policy have different owners and acceptance tests. A useful plan names each action accurately. It does not bundle them into an ambiguous optimise mobile step. The owner should see whether the proposal changes a provider setting, asks for external implementation or simply supplies analysis. This precision supports both safety and efficiency: the workflow retrieves the required facts for the chosen operation rather than fetching every vaguely related resource or applying a broad fix to an unrelated problem.
Use a general reporting workflow
The assistant should select metrics, dimensions, filters and dates through the shared reporting framework. A device request is one combination of those choices, not a reason to build a dedicated conversational patch. The same machinery should support a named conversion, a campaign scope or a condition such as CPA below an agreed value when compatible evidence is available. The tool must distinguish inclusive and exclusive comparisons and preserve the intended logical conditions. A readable answer depends on a correctly defined data request before it depends on a chart style.
General explanation and planning can stay conversational. The user may ask for hypotheses about a device pattern, ideas for a mobile headline or a checklist for a form review. Those tasks do not inherently need new provider calls. Current account claims and rankings need relevant evidence. Follow-up questions can reuse reliable results when they answer the request, while preparation refreshes changeable settings as required. This separation helps the assistant remain useful and responsive without turning every discussion into a full account report.
Clarify only the ambiguity that affects the answer. If the user says worst-performing device without a clear criterion, establish the relevant account-type metric or ask for the intended one. If they specify ROAS and a date range, preserve those choices. If they refer to a previously identified campaign, resolve that context instead of starting discovery from scratch. The system should retain the user's definition across follow-ups, especially after a correction. A framework is successful when new phrasing changes the selection, not when it requires a new hardcoded exception.
Make the chart answer the requested question
A device table can answer a comparison of period totals, while a time series needs dated rows. Do not manufacture daily points from one aggregate result. Request the compatible date and device dimensions when the user asks for a trend. A graph should preserve the period and metric definitions already agreed in the conversation. If the user wants two or three compatible measures in one chart, prepare the appropriate series rather than splitting them solely because they came from separate fields. The output should follow the requested comparison.
Slack native chart limits should shape presentation transparently. The app's chart workflow allows at most three requested metrics or segments for readability. When a period has more than twenty points and daily detail was not explicitly requested, use a suitable coarser weekly or monthly breakdown so one chart can represent the period. If the user explicitly requests daily points that require multiple native charts, explain the twenty-point limit and the split. Do not substitute an image or silently omit the later part of the requested period.
Label dates clearly. Current-year dates can omit the year, while older dates need enough context to avoid confusion. Weekly points should use actual date ranges rather than unexplained year-week codes. Display metrics with no more than two decimals and retain readable units. These choices should apply throughout the shared output layer, not only to one device example. The goal is a chart the user can understand immediately, backed by the requested data and honest about any aggregation or split needed to fit the native format.
Prepare a specific supported action
An informational device finding does not carry an automatic fix. If the user requests a change, identify the exact supported operation and its target. That might be a campaign setting, an ad-group-level adjustment where applicable or an external website task. The current compact card is not proof that a universal device-edit convenience tool exists. The workflow must establish its actual capability before preparing a provider request. A supported general operation should retain the same validation, ownership and verification safeguards as any named convenience action.
Use local capability rules for stable knowledge and provider reads for current facts. The relationship between a campaign and an ad group can be represented in a dependency table. Current bidding strategy, existing device settings and target ownership require account evidence. Do not call the provider merely to rediscover a structural rule, and do not use the local table as a substitute for the current configuration. This division allows efficient preparation while keeping the proposal grounded in the exact account state it is intended to change.
Keep the requested action narrow. A request to change one eligible device setting does not authorise a campaign pause, a new bidding strategy or a landing-page rewrite. If the user explicitly requests several actions, represent each as a logical step and sequence real dependencies. If the full sequence cannot be prepared safely, ask for narrower requests before writing. Do not execute a convenient subset and omit the rest. The owner should be able to review the complete accepted intent before any live mutation begins. External creative work remains separate from the supported provider operations.
Present readable steps and explicit approval
The confirmation should show the exact human-readable target and the proposed action. A campaign-level device setting belongs to that campaign; an ad-group-level setting should show its campaign parent. Routine output should omit private asset identifiers and never print a fabricated or undefined parent. Each logical action needs its own visible row or section, with a clear current-to-proposed difference where relevant. The user should understand the effect without decoding an internal resource name, a technical modifier or a JSON-like payload.
Use one confirmation for an accepted supported sequence, with each logical action prominently described. State that no changes have been made yet and that the proposal expires in fifteen minutes. The Confirm and Execute button should approve the exact displayed steps. Before that click, the workflow can prepare and validate the request but must not apply the live edit. Keep website implementation tasks distinct from provider operations; a proposal should not make an external task look automatically executable just because it is listed beside an advertising change.
After the click, show an immediate prominent change-in-progress state and prevent duplicate execution from the same button. The progress message should not include a user mention or imply that verification has finished. A later result can clearly highlight executed and verified when supported by the checks. If several actions were approved, report the result of each. A visible status transition helps the owner understand what happened while the provider work runs, especially when execution takes longer than an ordinary conversational response.
Verify the setting without promising uplift
A supported edit should verify the exact target field and intended value after execution. Submission acceptance is different from confirmed stored state. The verification must correspond to the proposed operation, including any relevant relationship or status. Re-running the descriptive device table does not establish that the right setting changed. Performance metrics can remain historical, and the table may not include the edited field. Direct configuration readback supports the executed-and-verified claim for the setting that the user approved.
Business consequences require a later review with stable definitions. A verified device adjustment does not prove that ROAS improved, lead quality rose or a specific amount of spend was saved. Those outcomes depend on subsequent activity and other influences. Record the implementation time, selected target and intended evaluation. The owner can then compare relevant reporting without confusing technical completion with causal proof. A website task similarly needs its behavioural acceptance test rather than a provider mutation response.
Preserve a meaningful current-to-proposed record. If the user later asks to reverse the change, the workflow should inspect current state and prepare a specific correction. It should not apply a universal undo that erases later work or assumes every advertising operation is reversible. The original action can be correctly executed even if the owner changes strategy afterwards. Clear history distinguishes the earlier approved decision, its verified implementation and the new intent. That makes future conversation more accurate and reduces unnecessary rediscovery.
Resolve partial and uncertain outcomes
An interrupted request can leave uncertainty about whether a provider change was applied. Inspect the exact current setting before retrying. A timeout is not proof that no mutation happened. If the intended value is already stored, reconcile the outcome; if it is not, determine the appropriate next action under the workflow's safeguards. Avoid blind replay of a stale request, especially when later steps involve resource creation. Current evidence should resolve the target state before the assistant prepares another live change.
For several logical actions, retain per-step results. A device setting may be verified while another approved campaign change failed. A website release may remain pending even though the advertising edit completed. Report those states separately instead of declaring the entire request successful or entirely untouched. The user needs to see what happened and what remains. Detailed diagnostics can stay in the execution record, while the normal reply uses clear business language and omits private identifiers or raw provider payloads.
Reconciliation should be focused. Reading one edited setting does not require rerunning device performance, fetching all campaigns or regenerating a chart. The operational question is current configuration, so retrieve the evidence that answers it. This keeps the workflow efficient under concurrent account usage and avoids introducing unrelated failures into a simple verification task. Once the target state is established, report it directly. Further analysis should follow the user's request or a genuine unresolved decision, rather than becoming an automatic response to every execution uncertainty.
Maintain a useful device-review record
A useful recurring review records the period, population, outcome definition and decision. It does not need to preserve every intermediate conversational request as an executed edit. Keep actual actions in the execution history and ordinary Slack requests in their appropriate conversation record. The owner should be able to tell whether the team discussed a possible device change, approved it or applied it. This distinction matters when a new colleague reviews an older thread and tries to understand why the current account differs from a previous report.
Revisit device evidence when it can inform a meaningful decision: a major website release, a changed offer, a new campaign objective or a substantial reporting pattern. Avoid recurring writes simply because a device's ratio differs from another's. The informational card provides visibility, not a mandate for constant adjustment. A documented decision to retain the current treatment can be useful when the evidence supports it. It gives the team continuity and prevents repeated debate driven by the same descriptive pattern without new information.
The in-house team can use device reporting well by connecting media evidence with customer experience and measurement ownership. The account table identifies a pattern within a defined historical scope. Focused investigation establishes which explanation is supported. The appropriate owner then implements the actual remedy, with explicit approval for supported live advertising edits and acceptance tests for external work. Keeping these stages distinct makes the audit a reliable decision tool. It also avoids turning a descriptive device comparison into an unsupported claim about causation or guaranteed returns.