Google Ads for ecommerce: three checks that make daily account review useful

Start with purchase measurement, eligibility and the destination

An ecommerce account connects advertising activity to a catalogue and a checkout process. A campaign can be enabled while important products are unavailable. A product can be approved while excluded from a particular group. A revenue report can look healthy while its selected value includes non-purchase actions. Daily review becomes more useful when those different conditions are checked separately.

Three priorities provide a practical starting point. First, establish whether the purchase measurement and value definition support the business decision. Second, inspect whether the products are eligible for the intended market and reporting context. Third, inspect whether the destination works and matches the offer. These checks address the path from recorded outcome to product opportunity to the customer's actual shopping experience.

They matter before small bid refinements because they can change what the performance report means or whether the intended offer can be shown at all. An efficiency ratio cannot compensate for an unsuitable conversion population. A budget increase cannot resolve a product disapproval by itself. A healthy feed field cannot establish that a landing page displays the intended price and available variant.

Use the findings to choose the next investigation, not to impose the same action on every account. Some issues need website or feed work. Others need provider review. A supported advertising edit requires its own proposal and approval. The useful outcome of an ecommerce review is a defined problem, suitable evidence and an owner who can resolve the relevant part of the workflow.

Check whether the purchase measurement supports the question

Begin by identifying the actions that represent purchases in Google Ads. Review their names, categories, primary roles and recorded values. The current business reporting framework can select primary Purchase actions separately from all primary conversions. This helps a retailer ask about sales without treating every assigned action value as a purchase outcome.

A configuration read establishes what the account is set to measure. It does not prove that the website sends every event correctly. A tag can be configured while a recent checkout change affects its implementation. A recorded value can exist while currency or transaction handling needs review. Use the account evidence as one part of the measurement check, then inspect the relevant site implementation when the question requires it.

Google's GA4 ecommerce measurement guide describes ecommerce events and their associated information, including purchase and refund activity and currency for value data. A retailer's implementation should be reviewed against its chosen measurement design. The presence of an event name alone is not enough to establish a complete purchase measurement.

Ask a bounded question first: “List the primary Purchase actions and show their selected recorded value for the period.” Then confirm which population the regular report should use. A broad all-primary total and a purchase-only total can both be available, but they answer different questions. The tracking review guide explains the limits of account metadata and the evidence needed beyond a configuration flag.

Review primary roles and counting settings without assuming duplicates

Primary and secondary roles determine an important part of the report population. The current business measurements select primary actions by default and leave secondary actions out unless requested. Selected primary actions are added together. If the retailer has several primary actions, the total includes the relevant actions rather than trying to repair the implementation or merge them into a deduplicated order count.

The ecommerce audit can flag multiple primary web Purchase actions or non-purchase primaries for review and recommend a preferred purchase source using its account heuristic. That recommendation is a review aid. It does not prove that two actions represent the same purchase, that one source is correctly implemented or that every retailer must use exactly the same arrangement.

Counting settings are another separate choice. Google's conversion-data guidance describes counting every conversion or one conversion after an interaction. The current audit evaluates eligible action categories against its counting recommendation and excludes locked provider-managed actions from supported edits. A counting recommendation should be reviewed with the actual action purpose.

Do not confuse these controls with implementation deduplication. Changing primary role alters the selected population. Changing counting behaviour alters how the action records outcomes under its setting. Neither is a universal repair for two tags reporting the same transaction. A retailer should understand the action and intended report before approving a supported change to its configuration.

Distinguish purchase value from broader conversion value

Money in a report is not automatically order revenue. An account can assign values to primary calls, leads or other outcomes. The current all-primary value measurement includes non-purchase primary values. The purchase-revenue measurement selects primary Purchase actions on the Ads side. A retailer should choose the measure that matches the question instead of relying on a convenient generic revenue label.

Consider an invented account with £10,000.00 in primary purchase value and £800.00 assigned to primary consultation calls. Its broader primary conversion value is £10,800.00. Its selected purchase value is £10,000.00. The difference is a population difference, not an arithmetic contradiction. A sales-efficiency report should identify the intended numerator before comparing it with spend.

Recorded purchase value also does not establish profit. Advertising cost is only one expense. Product cost, returns, shipping, payment fees and other business considerations can matter to the retail decision. A ratio using recorded purchase value and advertising spend should not be labelled as a profit calculation unless the necessary business cost inputs are part of an explicitly defined calculation.

Keep the source and definition visible in ordinary output. “Primary purchase value” is more precise than “revenue” when the account also records non-purchase values. A short explanation can preserve that distinction without exposing technical field names. This makes the result easier for ecommerce, marketing and finance colleagues to compare and prevents one familiar label from carrying several incompatible meanings.

Interpret purchase ROAS and average order value from their components

Purchase ROAS divides the selected primary purchase value by selected advertising spend. Average order value relates the selected purchase value to the selected purchase count. Both are useful when the components and population are clear. Neither should be interpreted independently of the underlying volumes, especially when a small number of purchases can move an average sharply.

For an invented example, £12,000.00 in primary purchase value from 200 selected purchases and £3,000.00 in spend produces £60.00 average value and purchase ROAS of four, equivalent to 400 percent. The arithmetic explains the selected report. It does not establish which products created that result, how many orders were refunded or whether the ratio meets the business's margin requirements.

Combine ratios using their components, not a simple mean of campaign averages. A small campaign should not receive the same weight as a large campaign merely because each occupies one row. The framework uses defined ratio components and complete compatible data. A result without a denominator should remain undefined rather than appear as a misleading zero.

Use a follow-up to locate a movement. If purchase ROAS fell, inspect spend and purchase value before choosing a cause. If average value fell, inspect purchase count and value, then the appropriate supported product or campaign detail. The metric explanation guide shows how to separate the formula, recorded components and investigation of the cause.

Compare Analytics with explicit source and traffic definitions

GA4 adds a site reporting perspective that can be useful alongside advertising data. A retailer may compare primary Ads purchase value with GA4 purchase revenue for the same dates. The comparison should retain source labels and the selected traffic scope. It should not require identical totals to be useful, and it should not add both sources together as independent revenue contributions.

All-traffic site revenue is a different numerator from advertising-attributed value. If the retailer wants GA4 purchase revenue from all traffic divided by selected advertising cost, describe the result as blended ROAS or MER. Select the spend source explicitly: Google Ads spend or the advertising cost available in GA4. Do not silently narrow the all-traffic numerator to make it resemble the Ads report.

A difference can justify a measurement and scope review. Confirm dates, conversion populations, attribution and the source definitions before calling it a tracking failure. A configuration read can establish which actions exist; an aggregate report can establish their recorded values. Neither alone reconstructs every shopper's journey or proves which measurement implementation is correct.

Keep the question bounded. “Compare primary purchase value with all-traffic GA4 purchase revenue daily for the last seven completed days” provides a defined comparison. A requested native chart can show the two labelled series when supported. The answer should state the actual reporting period and any coverage or processing notes relevant to interpreting the values.

Check product eligibility in the intended market and context

A product can have different eligibility across countries and reporting contexts. A retailer selling in several markets should inspect the intended market rather than rely on a blended catalogue number. Shopping ads and free listings are different contexts, and the same offer can appear in more than one. Counts should preserve those boundaries instead of pretending every row describes a distinct physical product.

The current Merchant status tool reads Google's aggregate product statuses by country and context. It deliberately avoids inventing one deduplicated account-wide total from overlapping counts. Issue counts can also overlap when a product has several problems. A large issue total should not automatically be described as the number of distinct affected products.

Google's visibility and status guide distinguishes approval status from visibility controls and explains that limitations can relate to countries or marketing methods. This is why a retailer should name the relevant market and context when asking whether its catalogue is eligible. An account can have available products in one scope and important restrictions in another.

Begin with the counts and principal reasons for the selected scope, then retrieve affected examples where needed. An approved product is not guaranteed impressions or purchases. A product under review is not the same as a manually excluded product group. The result should lead to the specific next check rather than a broad claim that the entire catalogue is either healthy or broken.

Distinguish product issues from account issues

A product-level issue and an account-level issue can affect very different populations. The former concerns the relevant offer; the latter can affect a broader catalogue or account capability. A retailer should inspect the returned reason and its scope before deciding who needs to resolve it. A product title correction and an account website-claim problem are not the same work.

Google's Merchant issues guidance describes product data and policy issues, including country-specific differences. The current feed audit combines product-health findings with account setup checks. A finding should preserve whether it comes from Google's issue response, a supported field check or an application comparison of values already retrieved.

Prioritise the actual reason rather than applying a generic feed rewrite. A product can have an image issue, a price mismatch or an unavailable destination. Each has different evidence and ownership. A warning or limited state should not be relabelled as a complete disapproval. Missing source coverage should remain unavailable rather than count as a passing audit check.

Use the feed audit to organise review, then act in the appropriate system. Current Merchant tools read and report; they do not provide a universal feed-editing or approval override. Some work belongs in the ecommerce platform, some in Merchant Center and some in the advertising account. The feed audit guide explains how to interpret the findings and their practical boundaries.

Separate stock availability from approval and targeting

Stock availability answers whether the offer can be bought under the stated condition. Approval answers whether Google accepts it in the relevant scope. Targeting answers whether the advertising structure includes it. A retailer needs all three distinctions to understand why an item is not contributing. Treating every unavailable product as a policy issue directs the team toward the wrong remedy.

The current availability audit recognises more than a binary in-stock or out-of-stock choice. Preorder, backorder and limited availability are distinct submitted states. Limited stock availability is not the same as limited serving eligibility. Review the actual value and business intention before describing it as an error. A preorder can be deliberate and need the corresponding offer information rather than a forced in-stock label.

Compare the submitted state with the live offer through the appropriate review. A feed field can be internally valid but stale relative to the website. A website can have stock while the feed has not yet updated. A current status read establishes what Google reports, while a manual product-page and platform check can establish the retail state. Keep those observations separate.

Assign the remedy accordingly. A genuine stock shortage needs inventory work. A stale availability submission needs feed or platform work. A manual group exclusion needs advertising targeting review. The same product can have more than one relevant condition. A useful account conversation identifies the conditions instead of flattening them into one reason that sounds definitive but is incomplete.

Prioritise previously earning products that have stopped serving

Not every catalogue issue has the same business priority. A product that recently generated recorded value and is now unavailable deserves a different review from a new item with no activity. Historical performance can help order the investigation, while the present reason determines the remedy. The historical value is context, not a guaranteed amount of future revenue lost.

The current Merchant audit includes a view of products that converted over its thirty-day performance window and are no longer serving. It can identify stock-only cases separately from rejected or limited cases. The table ranks relevant products using recorded conversion value. Where performance could not be read, the finding states that boundary instead of presenting an invented ranking.

Use the result to ask the next concrete question. Is the item genuinely out of stock? Does its current offer match the submitted data? Is the restriction country-specific? Does an account-level issue explain several items at once? A list of historical earners gives a review order, but it does not answer every cause or justify changing unrelated budgets.

Keep the interpretation restrained when sharing the result. “These products recorded value in the selected past window and are now unavailable” is supported by the joined observations. “This exact amount will be lost next week” is a forecast that the report does not establish. This distinction makes the finding useful to inventory, feed and marketing owners without overstating its financial precision.

Check the destination and the consistency of the offer

The third priority is the shopper's destination. An ad can promise a specific product or promotion while sending the shopper to a generic page, an unavailable variant or an outdated offer. A retailer should inspect the relevant URL, the visible product, price, currency, availability and route to checkout. The necessary review concerns the whole offer, not just whether a server returns a page.

The current ppctor destination command reads Google's published destination-related policy findings across supported ad, asset and asset-group surfaces. It reports what Google has identified on its review schedule. It is not a fresh crawl of every page and does not certify the current checkout experience. If one surface cannot be read, that missing coverage is named rather than treated as an all-clear.

Use those findings to prioritise a manual or platform review where appropriate. Open the actual landing page, select the advertised variant and inspect the displayed offer. Test the relevant path with the team's normal website review process. A provider verdict and a current manual observation can complement each other, but they establish different things and may have different timestamps.

Keep Merchant feed URLs and advertising destinations conceptually distinct. The same website can be represented through several surfaces, and a check of one does not automatically cover every other URL. The destination-check guide explains the reporting workflow. A retailer should use the relevant source and site evidence before describing the entire shopping path as healthy.

Review price and promotion transitions as a coordinated change

A promotion changes more than a headline. The product page, regular price, sale price, dates and any advertising claim need to remain consistent. A sale can end on the website while an old creative still advertises it. A submitted sale price can remain active longer than the team intended. Treat the transition as a coordinated retail change rather than a single account setting.

The current feed audit can compare sale prices with regular prices and inspect submitted sale date ranges. It distinguishes an expired range from a sale with no range. Its comparison of sale and regular prices is an application check, not an invented Google issue code. The finding should be interpreted according to the data it actually evaluated.

Review the intended state with the merchandising owner. A permanent discount can be deliberate, while a time-limited event needs the planned end state. Check the live page, submitted fields and active creative together. A correct feed field does not establish that every ad has updated wording, and an updated ad does not establish that every product variant has the intended price.

After the change, check the relevant provider status and measured activity without assuming immediate completion everywhere. A submission can be accepted before the resulting review state changes. A performance increase during the event does not prove the promotion caused it. Preserve the dates, offer scope and selected purchase definition when comparing the event with another period.

Keep product targeting separate from feed eligibility

A product can be eligible in Merchant Center while excluded from an advertising group. Conversely, an included product can be unable to serve because of a feed issue. These are different controls. A retailer asking why an item is absent should inspect both the provider eligibility and the relevant campaign's listing-group structure rather than assume that one state explains the other.

Performance Max can contain several asset groups with different listing-product trees. Standard Shopping uses ad groups for its corresponding structures. A product can sit under broader brand or category groups and then under an individual item selection. The reporting framework needs the full parent path and inclusion state to explain the relevant relationship.

Counts must preserve the chosen unit. If one product is excluded in two enabled groups, that is two group-level exclusion occurrences and one distinct product identity. Default review should keep enabled parent populations clear. A tree-node count is not automatically a count of represented products, and a limited preview is not an exhaustive relationship result.

If the user asks to include or exclude a supported target, prepare the exact relationship change for review. Keep other branches and existing segmentation intact. The earlier report can inform selection, but the live action requires complete resolved targets and current conditions. A feed disapproval cannot be bypassed by simply changing listing-group inclusion.

Use reporting periods that fit the retail decision

Retail decisions often involve launches, promotions, stock changes and recurring trading cycles. Choose the dates that correspond to the question. Last month is a calendar period; last thirty days is a rolling one. An event window can be shorter. A current partial day can help inspect delivery but should not be compared with a completed day as though both contain the same opportunity.

Preserve purchase and spend definitions across comparisons. A pre-promotion window and promotion window may have different product availability or campaign populations. A currently paused campaign can have historical spend. Explain those choices before treating a revenue or efficiency difference as a change in underlying demand. The returned period and scope should remain visible in the result.

Daily detail can identify when a pattern changed. A longer automatic trend can use coarser grain for readability when every day was not required. Explicit daily requests retain the requested detail within supported chart limits. Do not omit the last days of a retail event merely to fit one visual or substitute a calendar month for the user's rolling window.

Keep present status separate from historical performance. A product's last-thirty-days recorded value and its current eligibility are joined observations, not the same timestamp. The combination helps prioritise review, but it should not be described as a daily lost-revenue measurement. Clear temporal labels make the report more useful to colleagues managing stock and campaigns.

Work through a fictional catalogue incident

A fictional retailer, Briarwell Ceramics, notices a fall in purchase value. The marketing manager first compares consistent completed periods using primary purchase value and spend. The result establishes that the decline exists. A campaign breakdown shows it is concentrated in a Shopping-related part of the account. Those observations narrow the investigation without yet proving the cause.

The team checks Merchant eligibility for the relevant country and context. Several important offers have an availability issue, while others remain eligible. It retrieves affected examples and checks whether any were recent earners. The issue totals are not added into an invented distinct-product count because one product can have more than one finding.

The inventory owner confirms that some products are genuinely out of stock. The feed owner finds a stale submitted state for another item that is available on the site. The advertising owner checks the relevant listing-group inclusion. These are different remedies: restocking, correcting the feed state and reviewing a targeting relationship. One generic campaign edit would not resolve all three.

This invented incident demonstrates the three priorities working together. Purchase measurement establishes the performance question. Eligibility locates product restrictions. Destination and live offer review establish the retail state. The team can then act through the appropriate systems and check the outcome. It does not claim that the historical value of the affected products is a guaranteed future loss or recovery.

Review a product launch before interpreting its early performance

A product launch introduces a new offer, new creative and often new catalogue data at the same time. Before judging its first results, confirm that the intended purchase measurement is available, the relevant products are eligible and the landing pages reflect the actual variants and offer. A quiet launch can otherwise be mistaken for weak demand when the products were not available in the intended scope.

Check the catalogue connection and target market first. Inspect current approval or review states and any issue reasons. Verify the product's advertising inclusion in the relevant enabled groups. A new item under a broader tree can be included through a parent branch without an individual leaf, while a specific exclusion can prevent the intended delivery.

Review the visible offer and checkout path separately. A new page can have correct text but an unavailable default variant. A price can appear in one currency while the submitted offer uses another. A product image can be present while important buying details are missing. Use the team's website and platform review to establish those facts rather than relying on an account status count.

Then interpret early performance cautiously. A short window or small number of purchases can make averages unstable. Ask for components and exact dates before ranking the launch against an established campaign. Creative brainstorming can remain conversational, while publishing new assets requires the supported approval flow. The launch review should establish a usable baseline before a budget decision is made.

Connect performance to budget review without treating ROAS as profit

A retailer can use purchase outcomes to inform budget discussion, but the ratio is only part of the decision. Margin, stock, fulfilment capacity and business priorities may matter. A campaign with a strong recorded purchase ROAS may promote a product that is nearly unavailable. Another may have a different strategic role. Define the objective before choosing a budget action from a ranking.

Pacer provides a projection against a configured target, while performance reporting explains recorded spend and outcomes. Those are separate functions. A monitoring target is not a live campaign budget. Review the current period, completed-day calculation and relevant configuration when interpreting a projection. Do not describe it as an instruction already applied to Google Ads.

If the user requests a supported campaign budget edit, inspect the actual budget type and target. The current standard campaign-budget action has specific eligibility, including non-shared daily budgets. A broad account pacing concern does not make every budget editable through the same action. Unsupported or ambiguous work needs an appropriate narrower request or provider workflow.

Keep the proposed change concrete. Name the campaign, current value and intended value, and require confirmation through the edit flow. Recheck relevant settings before execution. The budget pacing guide explains how monitoring and live budget changes differ. A reliable ecommerce workflow connects the evidence to a reviewed decision rather than letting a ratio trigger an assumed action.

Assign the issue to the owner who can resolve it

Ecommerce problems cross team boundaries. Marketing controls advertising selections and creative. Merchandising controls offers and product information. Inventory controls availability. Website specialists control implementation and checkout behaviour. A useful audit finding should lead to the owner of the relevant system, rather than land every issue in the paid-media queue.

Give the owner the exact evidence needed. For a feed issue, identify the product examples, relevant market and provider reason. For a purchase-measurement review, identify the selected actions and observed discrepancy. For a destination issue, identify the reported surface and live page review required. Avoid sending a large account export when a focused finding establishes the task.

Keep the recommended next step separate from the finding. A product reported as out of stock needs confirmation from the inventory system. A primary-role recommendation needs measurement review. A destination finding needs inspection of the affected offer. The evidence can be clear while the remedy still requires a business decision. That distinction helps the owner act without inheriting an unsupported diagnosis.

Track the outcome through the relevant source. A corrected feed field and Google's resulting status are separate observations. A website fix and recorded purchase recovery are separate observations. A supported account edit can be verified, while its business effect needs later measurement. Clear ownership and outcome definitions make the review maintainable across several teams.

Run a focused ecommerce review in the connected Slack destination

Begin in the destination linked to the intended advertising account. Ask for the purchase measure, spend and period you need. “Compare primary purchase value and spend for the last seven completed days with the previous seven” establishes a bounded performance question. A follow-up can request a campaign table or a labelled chart when that presentation helps.

Use the relevant deterministic tool for a broader account check. /ppctor audit queues the advertising audit. /ppctor products reports product status, and /ppctor feed-audit runs the feed review through its current workflow. These commands need the relevant account and source context. A missing connection should be resolved before claiming the data is available.

Ask structural questions precisely. “How many product exclusion occurrences are in the enabled groups of this campaign?” differs from “How many distinct products are excluded?” Name the campaign or group when narrowing the population. If a performance condition is involved, preserve unknown coverage rather than assuming every product has the required group-level metric.

Keep the output readable and the audience appropriate. Use asset names and genuine parent context rather than raw identifiers. A concise summary can show the main result and a few examples, while a fuller attachment or web result supports detailed review. Channel members can see posted information, so the destination should fit the commercial sensitivity and volume of the report.

Review supported account changes explicitly

A report or audit can support an action request, but it is not authorization by itself. If the user asks to pause a campaign, adjust an eligible setting or change a supported targeting relationship, the workflow prepares the exact target and action for review. The live API call occurs only through the applicable confirmation and execution path.

Deeper targets should include their real parents. A keyword belongs to an ad group and campaign. A listing relationship belongs to its actual Shopping group or Performance Max asset group. Multi-step requests should show their logical actions separately and sequence dependencies correctly. A creation or inclusion proposal should not conceal omitted steps inside a technical paragraph.

Relevant authorization and settings are checked again before execution. A proposal expires after fifteen minutes, and supported results are verified afterwards. An uncertain outcome needs investigation rather than a blind retry. A successful configuration change does not establish Merchant reapproval or guarantee a purchase recovery. Each result should describe the operation it actually proves.

Website, feed and provider-review work may remain outside the supported edit tools. Current Merchant tools read and report rather than editing the catalogue. Do not claim that every finding has a one-click fix. The confirmation guide explains the review boundary. It lets the retailer combine conversational evidence with supported actions while preserving the distinction between diagnosis and execution.

Build a review cadence that follows retail changes

Routine review should cover the three priorities at a frequency suited to the business. Purchase performance can be checked over comparable completed windows. Product health can be monitored in the relevant market and context. Destination and offer review should accompany important launches, platform changes and promotions. The cadence should respond to meaningful change rather than request every possible report every morning.

Use deliberate saved Reporting for recurring output and the relevant monitoring configuration for continuing conditions. Ad hoc questions remain useful when a new investigation changes its scope. A one-time conversation should not silently become a schedule. Every recurring configuration needs an owner and destination so that output remains useful after staff or account changes.

Review shared definitions when measurement changes. A new primary action can alter a broad conversion total. A new product market can alter overlapping eligibility counts. A new listing structure can change relationship populations. Preserve the actual definitions rather than assuming that a familiar question continues to mean exactly what it meant several months earlier.

Keep handovers concise and complete. Record the measured finding, selected scope, responsible owner and intended next check. Stop obsolete schedules and review active Rules when an engagement ends. The ecommerce workflow succeeds when purchase evidence, catalogue state and shopping experience remain connected to the people who can act on them.

Frequently asked questions about ecommerce account review

Which checks should come first?

Start with purchase measurement, product eligibility in the intended scope and the destination offer. They establish whether the performance report is meaningful and whether the intended shopping opportunity is available. Use the findings to select the next investigation rather than apply the same edit to every account.

Does an approved product have to receive impressions?

No. Eligibility and advertising inclusion are different from measured delivery. Review the relevant campaign and group structure, current status and actual performance. Approval alone does not guarantee impressions or purchases.

Are all-primary values purchase revenue?

No. Non-purchase primary actions can carry assigned value. Use the purchase-only measurement when that is the intended numerator, and keep the chosen source and population visible in the result.

Can Merchant issue counts be added into one product total?

Not safely without a defined distinct-product population. Countries, contexts and issue reasons can overlap. The current aggregate status tool preserves country and context rather than inventing a deduplicated account-wide total.

Can every ecommerce finding be fixed from Slack?

No. Supported advertising edits have their proposal and confirmation flow. Feed, website, stock and provider-review work can require other systems and owners. The report should identify the practical next step without claiming a universal automatic fix.