Slack Merchant Center feed-audit guide: review product data, account setup and earning-product risks

Choose a broader audit when the setup needs investigation

A Merchant Center product-status summary tells the owner which eligibility counts and reasons Google reports. A feed audit asks a wider question: what does the available product, account, programme, and performance evidence suggest the team should investigate? That broader review is useful before a catalogue launch, during an unexplained shopping concern, or when a new operator needs to understand the merchant's setup. It is not simply the product-status command with a longer message.

The distinction changes the task. If the owner wants today's disapproved count by destination, a focused status overview is efficient. If the owner wants to understand missing data, inconsistent values, account configuration, and products with past conversion activity that now have eligibility or stock concerns, the audit brings those observations together. Selecting the tool by the question prevents a broad inspection from becoming the default response to every simple count request.

An audit is an evidence-led work queue rather than a universal repair service. Its findings can concern an upstream product record, a feed-generation rule, a site claim, a programme setting, a policy relationship, or unavailable evidence. Different owners and actions follow from those different sources. The value is in making those distinctions visible, assigning the next check, and preserving a complete snapshot that colleagues can revisit during the work.

Start with an intended decision. A seasonal launch review might ask which problems could affect the offers due to go live. An integration handover might ask which fields the merchant actually supplies. An incident review might ask which recently converting products now have problems. These are practical ways to use the same audit evidence without pretending every reported finding has equal urgency or represents a provider disapproval.

Keep business outcomes separate from configuration observations. A missing field is not automatically lost revenue. A claimed website is not a complete checkout test. An approved product is not guaranteed impressions. The audit can expose useful conditions for investigation while the owner retains responsibility for the intended market, product truth, commercial priorities, and relevant source process. That separation makes the review dependable rather than merely impressive in length.

The audit preserves three different evidence sections

The current audit groups findings into earning products with current concerns, product feed health, and account health. That ordering helps the owner review product-level commercial context before inspecting the catalogue and the merchant setup beneath it. The sections are not three independent catalogues. Their observations can concern the same merchant or product population from different angles, so the team should not add their findings into a supposed unique product total.

The earning-product section relates recent tracked conversion activity to current reported eligibility and availability. The feed-health section includes provider reasons, readable attribute coverage, submitted-value checks, and relevant data recommendations. The account-health section covers such areas as the merchant's business context, homepage claim, programmes, shipping, and returns. The complete audit retains detailed findings instead of reducing all three sections to a single generic feed score.

A section can be absent when it has no findings to display. That is not equivalent to a guarantee that every imaginable check succeeded. Some checks are conditional, some require a particular source, and some unavailable surfaces have their own informational result. Read the actual evidence rather than infer universal coverage from the number of visible headings. A useful review identifies which question remains unresolved after the available findings have been considered.

The structure also helps assign work. A stock concern belongs with inventory or source availability. A submitted-value inconsistency can belong with catalogue maintenance. A missing account policy needs the account administrator. An unknown taxonomy check needs its evidence restored before a product value is declared invalid. Grouping these observations is useful because the receiving colleague needs a coherent task, not simply a list of everything that made a red card appear.

During a handover, preserve the section and specific finding name. “Please investigate the product-data coverage result for this catalogue” gives more direction than “the audit failed.” Include the scope and the unresolved observation that changes the decision. The colleague can then use the complete snapshot for details while the Slack thread remains short enough for the owner to follow.

A finding count is not a count of rejected products

The audit counts findings classified as fail, review, and pass, while informational results are excluded from those verdict totals. A single finding can concern many products. Several findings can concern the same product records. One dynamic provider reason can produce its own finding, while one coverage card can contain several field observations. Therefore, the number of failed checks cannot be interpreted as the number of unique disapproved offers.

The current Slack summary's issue count reflects failed findings. Review findings remain part of the complete audit, but the short posted sections focus on failures. That means an initial message with no failed issues is not necessarily a statement that nothing needs review. The complete result is the place to inspect recommendations and evidence gaps. The reader should understand that summary boundary before using the headline to close a broader investigation.

The catalogue's disapproved count is a separate statistic derived from a product-level aggregated eligibility state when the catalogue read is complete. Its underlying selection counts products marked not eligible or disapproved across all reporting contexts. It does not mean every product affected by a disapproval in any one destination. A product limited in some contexts can belong to a different eligibility state. Align that definition before comparing it with destination-specific aggregate counts.

The app's own recommendations should remain identified as recommendations. A short title or description can trigger a review suggestion without constituting a provider rejection. Treating all yellow or red observations as official Google policy violations confuses the merchant and can result in unnecessary source changes. The correct response depends on whether the finding reports provider status, a documented bound, an app recommendation, or missing evidence.

A passing result is also narrow. It supports the particular check using the evidence available on that run. It does not certify every product, country, checkout experience, or commercial claim. Read the finding's description and caveat when interpreting it. A dependable audit makes work easier by clarifying what was established, not by claiming its scope extends beyond the fields and conditions it actually evaluated.

Historical conversion value helps prioritize, but is not future loss

The earning-product read looks at the last 30 days of Merchant product performance, retains a bounded group of products with conversions, and compares them with current product status and availability. The current implementation retains up to 200 recent earners before selecting those with relevant eligibility limitations or out-of-stock status. The detailed finding can show a ranked table of up to 50 entries. This is a priority view, not a guaranteed exhaustive list of every historically converting product.

A limited eligibility state can mean a product remains eligible in some contexts. Out of stock is a different condition from a provider disapproval. The finding's title refers to earning products that stopped, but its qualifying population includes these distinct situations. Read the individual reason and state before describing an offer as completely unable to show everywhere. The useful conclusion is that these products merit investigation, not that all share the same absolute block.

The displayed tracked conversion value belongs to the selected historical interval. It is not money already proved lost since the current condition began, an estimate of tomorrow's sales, or profit. The audit does not include the corresponding advertising spend in this view, so it cannot derive ROAS from the shown value alone. If the owner needs a return analysis, request the appropriately scoped Ads performance data separately.

The official Merchant performance-report guidance explains that selected segments shape the returned rows and that performance queries need a date range. It also notes currency-specific rows for price metrics. These details matter when interpreting a value comparison: confirm the measure, segmentation, and currency rather than treat any displayed number as interchangeable account revenue.

The current earning-product helper combines by offer identifier rather than exposing a country-and-method comparison in this finding. Consequently, it should not be used as evidence of which specific market lost all eligibility or as a reconciled multi-currency total. A market-specific investigation needs the appropriate focused report and status scope. The audit can establish where to look next without already answering every attribution and population question.

Use past value as one priority signal alongside stock plans, product importance, and intended market. A historically strong product that is deliberately discontinued may need no repair. A smaller new offer can matter greatly to an imminent launch. The assistant should preserve the historical evidence while asking the owner for the missing business decision. It should not automatically re-enable, restock, or rewrite offers based on the ranked table.

Coverage reports field presence, not universal correctness

The catalogue coverage view counts how many readable product records carry selected fields. It can reveal that a field is absent widely enough to suggest an integration issue, or that a smaller subset needs inspection. Presence is an important starting point. It is not proof that a value is truthful, well written, appropriate for every market, or responsible for current eligibility. Those claims require additional evidence.

The current coverage card uses stored requirement information to decide whether an unconditional missing required field can be graded. Conditional requirements are shown as conditional rather than automatically treated as faults. The audit does not resolve every vertical, country, or variant condition for every product in this coverage view. If the requirement table is unavailable, it falls back to coverage information instead of guessing that every gap is a violation.

Different read surfaces expose different fields. The reporting catalogue supplies such fields as title, brand, GTIN, availability, price, and resolved category or product-type levels. Other attributes, including description, some variant details, and custom labels, are examined through a separate processed-product pass. This division is deliberate. A field absent from one report schema should not be labelled absent from the actual product without consulting its applicable source.

Google's product data specification distinguishes product attributes, supported values, and conditional requirements. It defines title and description ceilings and the identifier-related context. The specification is the reference for provider requirements; the audit's shorter-text recommendations remain app guidance. Neither field presence nor a recommendation replaces reviewing the actual product and its intended use.

When a field is missing across many records, inspect the source mapping before editing individual offers. When it is missing only in a family of variants, inspect that family's data process. These are investigation patterns, not conclusions from a percentage. The audit helps identify a plausible starting point, while the receiving source owner establishes the actual cause. That distinction keeps the work targeted without pretending a coverage table diagnoses the full integration.

A coverage improvement can be verified independently of eligibility. The team may increase field presence while a separate policy reason remains. It may correct a required value without changing another optional field. Record the outcome that was checked rather than expect every audit card to turn into a pass together. This is particularly useful during phased catalogue repairs when several teams own different attributes.

Submitted-value checks add detail that counts cannot provide

The feed-health section includes checks of text length, certain broken characters, identifiers, sale-price relationships, date context, submitted category values, variant attributes, and other readable product information. These checks help distinguish a missing field from a present field with questionable content. They do not evaluate every possible semantic error. A product description can fit its length range while still needlessly repeating text or omitting an important distinction.

The current text-length checks separate provider maximums from app review floors. Titles shorter than 30 characters and descriptions shorter than 150 characters can trigger recommendations; those floors are not Google's universal minimum requirements. The reason to review such copy is whether it adequately describes the offer. A concise correct title should not be expanded with irrelevant words solely to satisfy a recommendation.

Identifier context also needs truthful product information. A missing GTIN is not a reason to invent one or copy a code from a similar product. The audit considers whether identifiers are declared to exist, but the actual requirement can depend on the product. The next task is to inspect the correct manufacturer or catalogue record and the applicable specification, then change the genuine source. A plausible-looking number is not evidence of a valid identifier.

Submitted category validation differs from observing resolved category coverage. One shows what the merchant provided; another shows the category levels represented in the product report. The audit can use a stored taxonomy to examine submitted values when that reference is available. If the taxonomy was not checked, it should not certify all values as valid. The operator needs to preserve that evidence boundary when reporting the result.

Sale-price and date findings also require intent. A price relationship that does not reflect the intended sale deserves investigation. A missing sale window can represent an ongoing price rather than a forgotten deadline. The current checks distinguish these situations rather than applying one blanket correction. Ask the pricing owner what the offer should be and check the appropriate source before changing dates or amounts.

Value lists can reveal naming inconsistency, unusual vocabulary, or a source rule that treated variants unevenly. They do not establish that every rare value is wrong. A small specialized range may legitimately differ from the main catalogue. Use the list to select representative records and compare them with actual product truth. The assistant's role is to organize that inspection, not normalize away valid differences merely because they are uncommon.

Account context belongs in the audit, but not every feature is universal

The account-health section examines the merchant setup behind the product data. It can include business location, homepage claim, programme context, shipping, returns, checkout, promotions, and local-related features where applicable. These observations matter because correcting one product attribute cannot compensate for every setup issue. An operator reviewing only disapproval reasons can miss account-level work that the responsible administrator needs to investigate.

Feature availability depends on relevant account and country context. The audit uses shared country-support information for applicable checks instead of treating every feature as universally required. An unused optional programme should not automatically become a feed failure. The team should read why a card appears and whether the business intends to use that programme. A feature opportunity and a blocking setup defect need different language and priority.

A homepage-claim result concerns the account's reported homepage relationship. It is not a live test of every landing page or proof of a fully functioning purchase journey. Advanced-account relationships can also affect interpretation because a subaccount may rely on parent context. Do not turn a single claim field into a blanket statement about website ownership failures without reviewing the relevant account structure.

Shipping and returns need coordination with the business owner. A returned configuration may be present while the actual commercial terms have changed. The audit can help identify missing or unmatched relationships, but it does not decide the merchant's policy. A source correction should use intended truthful terms. The site and merchant settings can then be checked for consistency through the appropriate process.

Return-policy labels are an example of a relationship check using already-read evidence. Products can point to labels that do not match a defined account policy. The audit can compare the product label tally with the account's policies without asking the provider once per product. The resulting review task concerns the intended policy relationship. It is different from a count of products rejected for an image or price issue.

When an account field is unavailable, the team should restore or inspect that evidence rather than create a setting blindly. An unread feature is not automatically disabled. A country-specific check that does not apply should not become a mandatory task. The complete audit's context and descriptions help the administrator make those distinctions, while a concise Slack handover should name only the uncertainty that matters to the current decision.

A broad audit can retain useful findings while some evidence is missing

The audit reads several surfaces separately and records unavailable slices. A failure reading one surface should not erase every other useful result. However, a completed overall audit does not guarantee every source was readable. Some cards show unavailable evidence explicitly; some conditional checks are omitted when their required source cannot be used. A missing card is therefore not automatically a pass.

The catalogue and processed-product passes are bounded by page and time limits. When a catalogue pass ends at a supported boundary, its exactness flag becomes false. Counts based on that partial population need to be interpreted as bounded observations rather than a complete catalogue total. In particular, the headless summary withholds its unique fully-ineligible product count when the catalogue is not exact. It reports that count as unavailable rather than publish an incomplete total.

The performance helper also refuses certain incomplete responses instead of ranking a partial result as though it were complete. Its retained earner population is intentionally bounded even after a successful read. Distinguish these two limits: a priority selection can be valid within its defined scope, while an incomplete underlying response can be unavailable. Neither supports the claim that every historical earner in the merchant was exhaustively examined.

Compare like evidence during repeated runs. A full catalogue count and a later bounded observation are not interchangeable. A recommendation omitted because its source was unread cannot be used as proof that the source problem cleared. The owner should note the relevant read availability when evaluating change. That is more reliable than watching only the total number of failed findings move up or down.

Use missing evidence to choose a next step. If the performance surface is unavailable, restore it before asking the audit to rank historical value. If product attributes cannot be read, request the applicable source or reconnect authorization. If a conditional reference table is unavailable, inspect its actual requirement rather than infer it. An honest audit gives the team a useful question to resolve instead of a misleading clean bill of health.

Three illustrative audits lead to different work queues

A seasonal catalogue has stock concerns and short descriptions

Imagine a fictional outdoor merchant named “Summit Pantry.” Its audit surfaces recently converting offers now marked out of stock and several short-description recommendations. The operator must not combine those into one list of disapproved products. The stock task goes to inventory and availability ownership. The description task goes to the catalogue content owner and asks whether the text adequately explains the offer, not whether Google universally requires a longer paragraph.

The owner expects the unavailable products to return before a launch. The team records the intended restock plan, checks source availability when the change is made, and later reviews the relevant product state. It separately updates descriptions where the actual content is insufficient. The final note names both outcomes. It does not claim that expanding text caused restocking or that the historical conversion value equals revenue recovered after the launch.

A catalogue integration loses an important field

A fictional household merchant named “Willow Shelf” finds that a readable field is missing across a large portion of the catalogue. The audit also reports provider issues for a smaller product population. The operator checks the integration mapping rather than editing every product by hand. The coverage result is a source-pattern clue; it is not proof that all absent-field records belong to the provider-disapproved group.

The source owner establishes which rule changed, restores the truthful mapping, and checks representative processed products. A later audit examines coverage and status separately. If coverage improves while some provider reasons remain, the task continues for those reasons with the appropriate owner. The team does not declare all issues cleared just because one broad field tally now looks healthy.

An account handover has review findings but few failures

A made-up home-accessories merchant named “Cedar Room” runs the audit during an agency handover. The short Slack summary has few failed findings, but the complete audit includes review recommendations and unavailable context. The receiving operator opens the complete result before concluding the setup is ready. It records programme intent, policy ownership, and which unread evidence needs restoring before a launch decision.

The team creates a concise handover with three owned tasks and links the saved audit snapshot. It avoids forwarding raw technical fields to the business owner. Once the account evidence is readable, a new snapshot can confirm the relevant setup. The original snapshot remains useful for understanding what the previous operator actually saw, rather than being silently replaced by a later set of different observations.

Translate a finding into a task with a real source owner

A useful audit task says what was observed, where it applies, who can correct the source, and how the outcome will be checked. A large finding count is not enough. The receiving colleague needs to know whether the work concerns inventory, text, a data mapping, account configuration, or provider review. Include representative product detail only where it helps locate the problem.

Distinguish verified cause from a proposed investigation. “The field is missing in the readable catalogue; please inspect the source mapping” is appropriate before the integration rule has been checked. “The source mapping is broken” requires evidence of that rule. This does not make the task vague. It gives the receiving specialist an exact observation and a concrete question without pretending the audit already inspected systems it does not read.

For a shared source change, record how the team will avoid applying incorrect information to valid exceptions. A content template might need different truthful attributes for variants. A policy relationship might depend on product type. A price change might have a specific effective date. The audit can identify the affected pattern, but the source owner needs those business distinctions to make a durable correction.

Plan the verification before the edit. A product attribute change can be checked in processed product evidence. A policy relationship can be checked against the defined policies. A provider status needs a later applicable read after processing. A website journey needs its own testing process. Naming that checkpoint makes the task concrete and avoids the familiar closure where everyone assumes another team has confirmed the result.

Do not let a temporary advertising decision erase source ownership. The owner might choose to pause a supported target while a feed problem is investigated. That confirmed Ads action can be complete while the product-source task remains open. Preserve both records and name their different outcomes. The audit's value is strongest when it helps a team coordinate several correct actions instead of collapsing them into one vague “fix feed” button.

Run the current command and understand the short reply

The current command is /ppctor feed. It uses the Merchant Center associated with the Google Ads account connected to the Slack channel. The handler checks the channel account link and merchant connection separately, explaining the missing prerequisite when either is absent. A missing connection is not evidence that the merchant's product feed is empty. Restore the intended account context before interpreting audit results.

The initial interaction provides a working receipt, while the broader provider reads run afterward. The current delivery path can replace that receipt with a more specific still-auditing message after about 20 seconds if the work has not finished. When the result is ready, it replaces the receipt rather than leave a permanently unfinished message above a separate result. That is a work-progress mechanism, not a guarantee the provider will finish within a particular duration.

The posted summary names the merchant and failed-finding count, includes the fully-ineligible product count when its underlying catalogue evidence is exact, and lists failed findings in their sections. It uses each finding's summary rather than only a compact web-card value. Review and informational results remain available in the complete audit. The summary therefore supports triage but should not be treated as the exhaustive output.

Use the readable merchant name to recognize context, and the finding labels to choose the next task. Do not infer that a stated issue count represents separate product identities. Do not infer that the short message's omission of review rows means none exist. A thread can remain concise while the complete snapshot supplies the fuller evidence needed for a source-owner handover.

If the audit cannot run, the command says the evidence could not be read rather than inventing an empty result. If the read succeeds but Slack delivery fails, that is a separate delivery stage. The run is recorded and delivery faults are logged through the app's diagnostics. Repeating the whole audit is not automatically the correct way to resolve a posting problem; first establish which stage actually failed.

Use the full HTML attachment and authenticated saved view

The current command records a detailed audit snapshot with its merchant context, sections, totals, and capture time. When saving succeeds, the Slack summary includes a login-required web audit link. That destination preserves what was observed on the run rather than pretending a later read is the same historical evidence. An authorized operator can use the saved view to inspect review findings and detailed context beyond the short reply.

A complete HTML audit can also be uploaded to the channel when the relevant Slack installation matches the workspace and includes file-write permission. The attachment includes issues, review items, passed checks, and informational results. It is a full audit artifact, not a promise of a separate PDF for this deterministic command. If the installation or permission is absent, the command cannot rely on that upload path.

The file and web view serve different collaboration needs. An attachment can be shared within the appropriate authorized working context; an authenticated saved view gives an app-based place to inspect the snapshot. Neither should be used to expose another client's merchant information in the wrong channel. Check the audience before forwarding an audit, especially when the output contains product names, account configuration, or business operating details.

A snapshot is historical evidence. Once a source correction has been made, the old file still describes the old observation. A later audit establishes a new checkpoint. Keep their timing clear when comparing them rather than expecting an attached file to update itself. A saved record can support accountability precisely because it does not silently rewrite what the team saw before the repair.

The full output remains a review surface rather than authorization for every conceivable change. A provider reason can contain guidance, an app card can contain a recommendation, and an unavailable result can explain a missing source. The operator must select the supported process appropriate to the target. Access to a complete report should make the next action more informed, not remove the confirmation boundary for live advertising edits.

A full feed audit costs more than an aggregate status check

The current builder starts fourteen independent provider-reading functions together, covering account information, product and aggregate data, performance, and applicable programmes. That concurrency reduces elapsed waiting compared with doing all independent reads serially. It does not make the work one API operation. Several functions can paginate, some perform more than one request, and authorization and delivery have their own operations.

The catalogue and processed-product passes fold pages into tallies rather than retain a giant catalogue for every check. Value maps are bounded, and the same read data supports several findings. That keeps the audit's data handling more manageable than asking each card to fetch its own product population. Individual check functions operate on the assembled evidence rather than independently repeating provider queries.

The builder also consults local requirement, taxonomy, and feature-support information. These references help checks use shared definitions. Their presence does not eliminate provider reads, and their absence should not produce invented passes. The useful public explanation is that the audit combines provider evidence with declared checks and references; it should not claim to be a zero-storage, zero-computation operation.

For a simple disapproval overview, use the Products command. For a broad prelaunch review, the additional audit work can be appropriate. For an explanation of an already-known card, a conversational reply may reuse established evidence. Matching the read to the question improves both response time and provider usage without skipping information necessary for the decision.

After a source edit, choose the verification scope deliberately. A focused product read may establish the corrected value before a complete audit is useful. A later full audit can confirm broader catalogue and setup effects when those are part of the task. Repeating fourteen reading functions after every explanatory sentence adds cost without necessarily answering anything new. The owner should get the evidence needed for the requested outcome, not a ritual full audit at every turn.

Conversational follow-ups should name the unresolved evidence

A good follow-up narrows the audit into a question the available framework can answer. Ask which products carry a reported disapproval reason, which source values explain a specific recommendation, or what recent performance belongs to an identified population. Name the intended market, parent scope, period, and metric when they change the interpretation. The assistant can then select the relevant fields rather than repeat the broad command.

Creative conversation is a different need. The owner may ask for a clearer truthful description or a headline idea using product context already established in the thread. That request does not automatically require another Merchant read or keyword research. The assistant should provide useful suggestions from the available facts and ask for missing product truth if needed. Suggestions remain suggestions until a supported action and target are explicitly prepared.

If the owner wants a chart, the assistant needs actual dated metric rows, not an audit finding count disguised as a daily series. The report should keep Merchant historical value, Google Ads conversion value, and Analytics revenue labelled according to their definitions. Do not manufacture daily points from a 30-day aggregate. Request the applicable date segmentation through the reporting framework when the user asks for that detail.

For an edit, distinguish source repair from Google Ads action. The app's supported conversational edits prepare a readable proposal identifying the actual target and its parents, then require confirmation before execution. A request to repair all Merchant data cannot be fulfilled by an unrelated campaign mutation. Read the confirmation guide for the live-account action flow and its verification boundary.

A follow-up should also preserve the previous evidence's limits. If a performance read was unavailable, the assistant cannot rank products by unseen value merely because the user asks more firmly. If the catalogue was partial, it cannot state a complete count from visible examples. The correct next step is to obtain the necessary evidence or explain the precise remaining limitation while completing the parts that are supported.

Verify repair, eligibility and business performance separately

The repair checkpoint should match the original task. A corrected description needs truthful intended text in the relevant source and processed product. A fixed policy label needs the correct product-to-policy relationship. A repaired identifier needs the actual manufacturer's corresponding record. A claimed homepage needs the appropriate account context. The audit can help review these observations, but one successful check cannot certify unrelated outcomes.

Provider eligibility can lag product changes. Allow for that processing and inspect the applicable status rather than repeatedly changing the same source value. The latest aggregate and product-level evidence may also differ in timing or scope. Align the merchant, country, destination, and product population before concluding that the views contradict. When the unresolved reason changes, update the task to the new observation rather than continue repairing the old one blindly.

Business performance comes later and needs its own interval. A cleared finding does not prove recovered profit. A product can become eligible while demand, stock, targeting, and other factors still influence results. If the owner asks whether the repair improved performance, choose a defined comparison period and appropriate measure. Keep that analysis separate from verification that the intended source change was made.

Close a task with a short evidence trail: original scoped finding, confirmed source correction, latest applicable provider state, and remaining review items. Link the relevant saved audit when authorized colleagues need detail. That gives the owner a clear status while preserving enough context for a later recurrence. It also prevents a broad issue headline from returning unchanged because nobody recorded which part was actually repaired.

Use ongoing monitoring for configured recurring needs and reporting for scheduled performance updates. The on-demand feed audit is a separate investigation tool. Together, these workflows can support a useful operating routine, provided each keeps its real purpose, scope, authorization, and evidence limits clear.

Common questions about the feed audit

Is this the same as the Products command?

No. Products reads aggregate status and reasons. Feed runs the broader Merchant audit using product, account, programme, and performance evidence.

Does one failed finding mean one rejected product?

No. One finding can affect many products, and several findings can affect the same products. Verdict counts and product counts measure different things.

Are short descriptions automatically Google violations?

No. The audit's shorter-text review floors are app recommendations. They are separate from provider maximum lengths and actual reported issue reasons.

Does historical conversion value show profit lost?

No. It is tracked value for the selected historical population. The finding does not include corresponding spend or establish future lost profit.

Does no failure headline mean all sources were checked?

No. Inspect the complete audit for review and informational results, and consider unavailable or conditional evidence.

Will the command change the feed?

No. It gathers and reports evidence. Source corrections and supported confirmed advertising edits are separate processes.

Why can the audit take longer than a status overview?

It reads broader evidence and can paginate catalogue and processed-product data. Parallel retrieval reduces waiting but does not remove that work.

Where are the complete findings?

Use the saved authenticated web audit when available and the complete HTML attachment when the matching Slack installation has file-write permission.