Google Ads device performance guide: compare outcomes before changing bids or exclusions

Device performance is evidence for a decision, not a verdict on a screen

A device breakdown shows how returned advertising metrics vary across device categories. It can reveal a useful pattern, but the pattern is not a ready-made instruction to exclude a device. Start with the business question: which population deserves investigation, which outcome matters, and which decision could follow from the evidence? Without that context, the largest cost row can become an unjustified target.

High mobile spend can be consistent with a productive account. Low tablet spend can be consistent with little opportunity, deliberate configuration, or simply a smaller observed population. A desktop row with stronger efficiency can reflect the campaigns and offers that reached it. Device is a reporting dimension, not a full explanation of why each visitor did or did not become a customer.

A useful first review keeps cost and outcomes together. If the account is evaluated on conversion value, inspect that value and its definition alongside spending. If it is evaluated on lead acquisition, inspect the relevant primary outcomes and acquisition cost. Clicks can explain activity, but they do not substitute for the result the business actually wants.

Distinguish two kinds of decisions. A performance investigation asks what the measured pattern means. A configuration request asks for an exact current setting to be changed. They can connect, but neither automatically implies the other. The assistant should not turn a read-only question about mobile ROAS into a bid change, and it should not fabricate a performance justification for a clearly stated policy preference.

The strongest review can end without a live edit. It might establish that the account-wide pattern reflects campaign mix, that a mobile destination needs site work, or that the chosen conversion measure is unsuitable. These are concrete outcomes. An operator does not need to mutate Google Ads merely to demonstrate that a device analysis was useful.

The current audit displays device performance as information

ppctor's account device reader queries Google Ads performance segmented by device for the selected range. It collects impressions, clicks, cost, conversions and conversion value, then aggregates returned rows by device key. The current audit table uses those observations to show an account-wide breakdown. It is not a device-quality classifier and it does not assign a universal target adjustment to each row.

The audit presents device performance as an informational card with hidden status rather than a scored issue. A reader should therefore not interpret its presence as a failed setting. The table exists to make the distribution visible. A device row that looks less efficient than another is a prompt to investigate the actual scope, sample and business outcome before choosing an action.

The displayed categories have readable labels for mobile, computers, tablets, connected TV and other returned device keys. Categories that are not returned do not become a list of invented zero rows. If a required provider read fails, the associated check should show that it could not be verified instead of presenting a confident no-activity conclusion.

The table also contains an “All” row calculated from the included observations. Additive measures are summed, and the efficiency metric is derived from the combined relevant totals. That total is useful for orientation. It should not be added to the category rows again when preparing another summary, because doing so would count the same population twice.

Campaign-level device breakdowns provide narrower context. They can help identify which campaign contributes to an account pattern that would otherwise appear to be one universal device effect. The campaign table is informational too. A comparison should say whether it concerns the whole account or the selected campaign rather than switch between them silently.

The audit's presentation chooses an appropriate business-efficiency view according to its account classification. That default is helpful, but a user can request a specific measure for a different investigation. The assistant should honor the explicit metric and its definition through the relevant read capability. A default should not override a clear request or hide that a requested measure was unavailable.

Choose the outcome before deciding which device looks better

Cost shows the amount spent in the selected population. Clicks show one kind of interaction. Impressions show exposure. Conversions and conversion value describe configured outcomes with their own definitions. A device comparison needs to select the measures that answer the business question. Ranking by cost alone identifies the largest spending population, not necessarily the worst-performing one.

For a conversion-value review, ROAS is value divided by cost for the requested population. For a lead-acquisition review, CPA is cost divided by the selected conversion count. Preserve the numerator and denominator in the result. A high ratio based on little activity and a moderate ratio based on substantial volume need different interpretation even when the ranking is mathematically correct.

Do not average device ratios to obtain account efficiency. Combine the relevant totals and calculate the ratio from that combined population. A simple average would give a tiny category the same weight as a large one. The same rule applies when rolling daily data into weeks or comparing several selected campaigns: additive observations combine first, and the ratio follows.

Zero and unavailable are different states. If cost is zero, a cost-based efficiency ratio may not be meaningful. If conversion count is zero, a finite CPA should not be invented. If a provider read failed, none of those values can be confidently treated as measured zeros. A readable table can state the missing or undefined result instead of disguising it with a convenient number.

Keep fractional conversion observations where relevant rather than force every value into an integer for simplicity. Display formatting can remain concise without changing the underlying measure. The important distinction is between presentation and computation: use readable decimals in the message, while preserving actual returned values for ratios, filters and comparisons.

The default outcome scope should be explicit when it affects the conclusion. Primary conversion analysis differs from a request for all observed conversions including secondary actions. Individual named actions differ from an aggregated outcome family. A user can ask for the narrower comparison, and the generic data framework should select that population instead of relying on the device table's default aggregate.

The period must be as clear as the metric

A rolling thirty-day request is different from last calendar month. Keep the actual date bounds and account time zone aligned with the requested period. A report based on completed days should not quietly include a partial current day or end two days early. The device rows are comparable only when they use the same intended interval and population.

Choose the follow-up comparison deliberately. Equal-length periods can help evaluate movement, while calendar periods can serve a different business reporting need. State which was used. If the account changed conversion definitions, budgets or destinations during the interval, retain that context. A device trend is not isolated from changes that affected the campaigns reaching each category.

Recent outcomes can continue to change as reporting matures. A team should use its observed conversion timing and appropriate freshness context when interpreting very recent efficiency. Do not create a universal waiting period from the device label alone. A lead service with delayed qualification and a retailer with immediate online purchase observations can need different review practices.

When the request contains a threshold, apply it to the intended aggregate. “Devices with CPA above this amount over the last thirty days” describes a period-level calculation, not every individual day that crossed the amount. A request for daily exceptions is different. The assistant should retain the chosen grain so a table and chart do not silently answer different questions.

Operators can also investigate a particular campaign transition. Mark the change date and define the subsequent review population before comparing it with earlier observations. A setting changed halfway through the reported period cannot explain the entire period as though it had been present from the start. The execution record supplies useful timing context but does not replace actual performance reads.

A period with no returned activity can be a valid result if the read succeeded and the requested population was truly empty. It can also reflect a wrong filter or an unavailable source. Resolve which case applies before drawing a conclusion. “No data returned” needs context, especially when the owner knows the account was active.

Account device patterns can reflect a changing campaign mix

An account combines several campaigns, offers and customer intents. Its device totals inherit that mixture. A desktop-heavy brand campaign and a mobile-heavy prospecting campaign can produce an account-wide efficiency gap even when each campaign's own device pattern is less dramatic. Use the narrower campaign breakdown to investigate before treating the account row as evidence that a screen category caused poor results.

Campaign type also matters to interpretation. A connected-TV observation can arise in a different advertising context from a Search click on a phone. The same table gives useful visibility, but it does not make every category directly interchangeable for every decision. Compare metrics and populations that actually answer the requested question, and explain context that changes their meaning.

Within a campaign, groups and offers can still differ. If a pattern requires a narrower read, select the applicable supported dimensions and avoid requesting unrelated data. The objective is to identify which actual population produced the result. A focused group comparison can be more useful than downloading every keyword in an account just because the device total looked unusual.

Geography, time and device can interact in the observed data. A device category may have received more activity in a region or schedule with different outcomes. That does not automatically justify a complex bid recipe. It justifies the next appropriate read when the evidence matters to the decision. Avoid multiplying speculative explanations into a list of live changes.

Volume differences also matter. A device can have weaker efficiency while contributing essential total outcomes. Another can have excellent efficiency but little practical scale. The owner should see both efficiency and magnitude before choosing whether to restrict, investigate or retain it. A sorted ratio alone can hide the business consequence of removing a substantial population.

The assistant should explain the actual contribution rather than invent a causal model. “This campaign accounts for most of the reviewed mobile cost” can be established by a focused aggregate. “Mobile users are inherently worse customers” is not established by that read. Keep the conclusion proportional to the data and use the next supported query to resolve a specific remaining question.

Check outcome definitions before treating a device as the problem

A conversion definition is part of every efficiency calculation. An account that counts a low-value interaction as its main outcome can produce a device ranking that looks strong for the wrong business reason. Before recommending a device restriction, establish which primary outcomes the metric includes. A measurement correction can be more relevant than a targeting change, but it is its own approved operation.

Lead businesses may need to distinguish initial contact from later quality evidence in their business review, while retaining the user's requested aggregated lead definition in reporting. Do not assume a category name alone proves qualified business value. If comparing Google Ads leads with GA4, ask for the corresponding event when it is not established. A plausible event name can be suggested for selection, not silently accepted as the intended mapping.

A named conversion comparison can also help. The user may ask to compare one Google Ads action with one GA4 event across devices. That request needs those specific populations and compatible available dimensions. It should not be answered with the total of all account conversions simply because the audit has that aggregate ready. Preserve the named outcome through the plan and output.

Revenue definitions need similar care. Google Ads primary conversion value can include value assigned to different primary actions, while GA4 purchase revenue describes its purchase measure. The two can be compared with clear labels where the requested scope is supported, but should not be added together as though they were separate sales. A device chart should retain each source's metric identity.

A discrepancy between clicks and sessions is not by itself proof that a device's conversion tracking is broken. Those measures come from different observation systems and definitions. Investigate the actual account, website and report configuration needed for the question. Do not substitute a ratio of unlike totals for a verified diagnosis.

When measurement remains unresolved, keep the targeting proposal separate. The owner can approve a strategic restriction if that is truly intended, but should understand that the performance diagnosis is incomplete. The assistant's role is to present what was read, identify the specific missing evidence and avoid dressing an assumption as a provider-confirmed fact.

Investigate the destination experience on the relevant device

A weak mobile outcome pattern can justify examining the mobile customer journey. Review the actual page, offer and task the visitor must complete. A phone user may encounter a different layout or a configured mobile destination. The device report identifies the population to investigate; it does not inspect the page's form behavior, checkout steps or event implementation.

Start with the destination configured on the relevant ad or asset. A different mobile final URL can be intentional, outdated or poorly suited to the current offer. Confirm the exact field before editing it. A URL read can establish configuration, while a browser test establishes the observed page experience. Keep those two conclusions separate in the investigation note.

Review the task rather than only the page's first appearance. A booking form, contact route or purchase flow may have a problem later in the journey. The operator needs evidence from the appropriate site review. The audit's provider destination findings are useful context, but they are not a comprehensive browser test of every customer action on every screen.

Creative expectations can also be relevant. A mobile visitor may have clicked an offer whose destination does not explain the same promise. That is a message-and-page question, not automatically a bid adjustment problem. The assistant can help draft truthful alternative content in conversation, while live ad creation or replacement requires the supported operation and a separate confirmation.

Do not remove functional URL parameters merely to simplify a mobile link. Some select a product variant or appropriate language. Others carry a deliberate measurement convention. Inspect the owner and purpose before changing them. The landing-page tracking-tag guide explains why a tidy URL is not the same as a verified destination experience.

If the site review establishes a defect, resolve that defect before judging later device performance dependent on it. Keep the Google Ads analysis available, but do not continue testing a targeting change on top of a known broken customer journey and call the result a clean device experiment. The business question and the operational dependency should remain explicit.

Three fictional patterns lead to different next steps

A large mobile row is productive

A fictional shop named “Ashfield Carry” receives most of its reviewed cost and conversion value from mobile. Desktop has a slightly stronger ratio but a much smaller contribution. The owner reviews the actual totals and campaign mix rather than automatically cutting the largest row. The conclusion can be to retain mobile while investigating a particular campaign that differs from the broader pattern.

The Slack reply shows the requested metric, period and device populations. A follow-up campaign breakdown identifies the source of the unusual behavior if the owner asks. No write is required to produce that explanation. If a later configuration decision follows, it is prepared against the actual campaign and its supported strategy rather than applied to the whole account from the original summary.

A mobile booking path needs site work

An invented service company called “Birch Appointment” sees weaker mobile acquisition efficiency in a reviewed campaign. The team confirms the outcome definition and inspects the relevant destination. A site review identifies a problem in the booking task. The next step is to fix that customer journey, retain the change date and assess a suitable subsequent period. The device table did not diagnose the page itself; it directed useful investigation.

The owner avoids adding an unsupported bid adjustment solely because mobile was weaker. If a temporary targeting restriction is desired during remediation, that is an explicit separate decision with current capability checks. The eventual review considers the site correction and any advertising changes together, rather than attributing every later outcome to a single device setting.

A tablet ratio rests on very little evidence

A made-up retailer named “Rowan Studio Shelf” sees a high tablet ratio in a small population. The owner asks whether to increase tablet emphasis. The assistant returns cost and value alongside the ratio and explains the observed volume. It does not convert a small attractive row into a guaranteed opportunity or choose an arbitrary percentage increase.

The owner can request a longer completed period or a relevant campaign breakdown to understand stability. If a deliberate supported change is eventually chosen, the proposal names the actual field, target, current value and new value. The later review checks measured outcomes without claiming the original small-sample ranking predicted the result.

There is no universal correct device bid adjustment

The correct setting depends on the campaign type, bidding strategy, configured level and business intent. A device report is not itself an editable setting. To change configuration, identify the actual supported field and current target. A universal rule such as “mobile CPA is higher, therefore reduce mobile bids by a fixed percentage” skips those dependencies.

Google documents strategy-specific bid-adjustment eligibility and distinguishes Target CPA device target adjustments from ordinary bid changes. It also describes how campaign and group device adjustments interact, including the campaign opt-out exception. Review Google's bid-adjustment guidance before proposing a setting; one percentage does not have the same effect under every strategy.

For manual bidding where the requested control is supported, a change still needs its exact intended level and value. A group-level adjustment can differ from a campaign-level one. The owner should see that context in the proposal. Do not assume that changing a parent automatically expresses every intended child policy, or that a child value can override every parent restriction.

For automated strategies, first establish the eligible operation and its actual meaning. A displayed adjustment field is not permission to promise a proportional traffic or cost change. A supported exclusion is also different from a moderate adjustment. The assistant should use current capability discovery and provider validation rather than infer behavior from a field name alone.

Performance Max should not be described as offering the same manual device bid recipe as a standard eligible Search setup. If the owner asks for a device-related policy there, inspect current supported controls for that campaign and preserve the exact request. Do not present the informational device table as an automatic edit button or silently substitute another inventory restriction.

App-category exclusions address another decision. Excluding app categories at account level is not a device opt-out, and it can have broader scope than the campaign being reviewed. The app-category exclusions guide explains that separate action. Choosing it should be deliberate rather than a fallback whenever an unsupported device adjustment is requested.

Inspect performance and configuration separately in Google Ads

Google's Search performance guidance describes using the Device segment to compare campaign, group, ad or keyword statistics where available. This is a reporting workflow, not a settings mutation. See Google's device-performance inspection instructions for the native segmentation approach, and retain the selected table and date range when comparing it with another report.

Begin at the intended scope. Set the relevant date range, select device segmentation and include the cost and outcome columns needed for the decision. Verify that the rows belong to the chosen account or campaign. A table shown at a different scope can explain an apparent disagreement without either source having calculated the same population incorrectly.

Inspect the current strategy before moving to settings. The campaign's bidding strategy helps determine which adjustment is applicable and what it means. Review any relevant group-level values too. The goal is to understand current configuration rather than assume the performance row includes every setting that shaped its delivery.

When using an eligible adjustment editor, select the exact campaign or group and device category, review the current value, enter the intended change and save it. The current interface and campaign eligibility should guide the available control. If the desired control is unavailable, do not simulate it by changing an unrelated field with a similar name.

After saving, reopen or reread the relevant field. Confirm the requested value and target rather than rely on the editor closing. Then separate that configuration verification from the later performance review. A successful setting change establishes what is stored; it does not guarantee that the next day's volume or efficiency will move by the adjustment percentage.

If the user intends a full device exclusion rather than an adjustment, state that distinction before saving. The business consequence can be much broader. The plan should identify the eligible control and affected scope, preserve other settings, and include a review responsibility. A vague “optimize mobile” instruction is insufficient for a live operation with that consequence.

Ask the assistant for the exact population and outcome

A focused request can be “Compare cost, primary conversion value and ROAS by device for the last thirty completed days.” The assistant should select the relevant generic data capability, preserve the date definition and return a readable comparison. It should not fetch every resource in the account just to provide a device aggregate, and it should not substitute clicks when the requested outcome is value.

A campaign-specific follow-up should retain the same measure unless the user changes it. “Now show that for the seasonal campaign” narrows the population. It does not change the definition of ROAS or reset the period to last month. The plan should preserve established context while resolving the exact campaign when a name is ambiguous.

Threshold requests should remain precise. “Show devices with ROAS at least three” includes equality, while “above three” does not. Compound conditions such as cost above an amount and ROAS below a target require the intended logical relationship. Apply those conditions to the chosen aggregate and keep the resulting table's labels and scope aligned.

If the user asks which device is worst, establish the account's appropriate outcome and any necessary minimum evidence condition. The default efficiency measure can guide an ordinary request, but an explicit metric takes priority. A missing outcome or undefined ratio should not be promoted to the bottom of a ranking as though it were a measured poor result.

The assistant can explain a returned pattern without immediately calling a mutation tool. It can suggest the next relevant investigation based on the actual evidence, draft a handoff note or help phrase a business hypothesis. Creative explanation and planning remain conversational. Current configuration reads become necessary when preparing a real setting change.

A request to act should produce the actual supported proposal. The assistant needs the current campaign type, strategy, target and applicable field. If those facts do not support the requested operation, it should explain the specific limitation and inspect a relevant alternative only when that fits the user's intent. A generic framework should discover settings rather than require a new dedicated tool for every phrasing.

Make the chart answer the same question as the table

A category comparison often works best as a compact table with cost, outcome and efficiency together. A bar chart can emphasize one measure across devices. A time-series chart can compare a selected metric for up to three requested populations or compatible metrics in the current native chart output. Choose the representation that preserves the actual business question rather than automatically drawing several disconnected figures.

A device category and a metric are different components of a series. “Mobile ROAS over time” combines the device population with the ratio. “Cost and value over time” combines two measures over one population. The generic composition plan should keep those identities explicit. Otherwise, the chart can accidentally display account totals while its title promises mobile data.

For ratio time series, calculate each point from its interval's relevant totals. Do not average daily ROAS values to produce a weekly ratio. A week with large spending and a week with little spending need their own combined observations. The labels should show the chosen grain so the reader does not mistake a weekly trend for daily detail.

Native charts have a point limit. When daily detail is not explicitly required, a longer period can use a clearly stated weekly or monthly breakdown to remain in one readable chart. When the user explicitly asks for daily detail that requires more than one native chart, explain the split and keep the consecutive dates clear. Do not discard part of the range silently.

Use readable date labels and concise numeric formatting. The chart should not expose raw compact provider date keys or long decimal tails. Current-year labels can omit the year, while earlier-year dates need enough context to remain unambiguous. The displayed values are presentation; filters and ratio calculations should continue to use the underlying observations.

If the requested comparison exceeds the available native series limit, explain the limit and ask for the most useful subset. Do not randomly omit a device or combine dissimilar categories under an undisclosed “other” label. A clear selection keeps the output faithful to the request. The table can retain fuller context when the applicable reporting result supports it.

A live action needs a target, a setting and an explicit confirmation

The proposal should name the campaign or group, its proper parent context, the device category and the exact supported change. Show the current and proposed value where applicable. “Improve mobile” is a goal, not an executable setting. The owner should understand what will be different in Google Ads after confirming, without needing to decode an API payload.

Preparation reads current state and checks the operation's dependencies. Local capability and dependency information can answer structural questions without repeated provider calls, while current account facts still require the relevant read. This balance supports efficient tooling without skipping evidence needed for a live write. The application should not pretend a locally known field proves the current campaign is eligible.

The owner confirms the prepared proposal before execution. Current settings are checked again, the operation is validated, and the live write is followed by readback. Each step establishes a different fact. A response to a read-only device question should not bypass this flow just because the assistant inferred a likely optimization.

If the request includes another action, list it separately. A device-setting change and a campaign-budget change have different fields and implications. A destination replacement has additional content and URL requirements. Clear steps make the proposal reviewable and prevent one successful operation from concealing that another requested action was omitted.

Readback should compare the actual intended field and value, including relevant parent identity. It should not verify success by looking only at unrelated campaign status. If the write is submitted but the result cannot be fully verified, report the uncertainty and avoid an automatic replay. The account can be inspected to resolve state before another operation is requested.

The execution result should describe configuration success, not guaranteed business improvement. A verified adjustment or exclusion is a stored-state conclusion. Later efficiency needs a measured follow-up. The approval guide explains how precise targets and current-state checks keep a conversational decision separate from an authorized live edit.

Preserve the change context when evaluating what happened next

Record the original question, metric, period, relevant device population and reason for the decision. Add the verified configuration change and its time. This makes a later review reproducible. Without that context, another operator can compare a different outcome or scope and conclude that the same decision produced contradictory results.

Choose a subsequent completed interval that fits the business's reporting and outcome timing. Inspect both volume and efficiency, and retain concurrent changes in the explanation. A higher ratio accompanied by substantially fewer outcomes can require a different business judgment from a higher ratio with stable contribution. The owner should see those consequences rather than only a celebratory percentage.

Revisit the hypothesis if the evidence does not support it. A setting can have been executed correctly while the expected business result did not occur. That is not the same as an API failure. The next investigation should ask what was actually observed and which assumptions need review. Avoid repeating the write just because the first performance comparison disappointed.

A future reversal needs current configuration and an explicit new proposal. Do not assume that the old value is still the only relevant context, especially if another operator changed the account after the original action. The prior execution record helps identify intent, while a current read establishes today's state. Preserve unrelated changes when preparing the requested reversal.

Keep the outcome useful for the wider account review. Device evidence can inform destination work, measurement review and campaign planning even when no further targeting edit is needed. The conversational reporting guide explains how scoped follow-ups and generic data selection support those questions without inventing a separate tool for every variation.

During a handoff, preserve the conclusion's confidence as well as its numbers. A confirmed configuration, a measured comparison and a proposed explanation are different entries in the review. Another operator should be able to identify which statement came from a current field read, which came from a performance aggregate, and which still needs investigation. That record prevents a tentative explanation from becoming an unquestioned reason to exclude a device later.

If the owner requests another review after a business change, rebuild the relevant population rather than repeat the previous ranking from memory. A new offer, destination or campaign mix can change the comparison. The existing decision record provides context, while fresh scoped data answers the new question. This keeps the device workflow reusable without assuming that one historical finding describes the account permanently.

Questions about device performance

Is the device audit a failed setting?

No. The current device breakdown is informational. Its presence does not prescribe a bid adjustment.

Is the highest-spend device the worst performer?

No. Cost and business outcomes need to be reviewed together under the requested metric.

Can account ratios be calculated by averaging device ratios?

No. Combine the relevant totals and calculate the ratio from that population.

Does the device table identify app inventory?

No. Device and app-placement populations are different and need the appropriate dimensions.

Will the same adjustment work under every bidding strategy?

No. Discover the eligible field and its actual strategy-specific meaning before preparation.

Does a verified edit guarantee better ROAS?

No. It verifies the requested configuration. Later measured outcomes require their own review.