Turn an account signal into a clear advisory task
Google Ads alerts for consultants: define the signal, investigate the evidence and explain the next decision
Configure useful monitoring around the scope of your engagement. Keep thresholds, measurement and response ownership explicit, then use Slack to distinguish a reported condition from a recommendation or approved live change.
Start with the engagement you actually own
A consultant's alert is useful when it supports a responsibility the engagement actually includes. You may be advising on measurement, overseeing a campaign transition or reviewing a retailer's advertising economics. Those responsibilities do not necessarily include responding to every account event at every hour. Define the monitoring purpose with the client before configuring signals, so a notification does not create an unstated promise of continuous incident response.
Ask which decisions need attention between scheduled reviews. A campaign that must remain available for a launch may need a different check from an established account where the engagement concerns monthly return. A measurement project may care about an unexpected lack of reported activity, while a product strategy project may care about Merchant issues. Begin with the client dependency, then select the supported signal that can provide relevant evidence.
Keep the authority boundary visible. A consultant can investigate and recommend without being the person entitled to approve live edits. The account's connected owner has a distinct approval role. Conversely, an owner can choose a business response that differs from the consultant's initial recommendation. Alerts should support that conversation rather than silently turning the consultant's threshold choice into permission for account changes.
Write a short monitoring agreement in ordinary language: the account scope, signals, recipient, expected review routine and decision owner. This is a practical working note, not an elaborate service contract inside a Slack message. It helps everyone understand what the configuration does and what it does not do. A clear agreement is especially valuable when several people support the same client account.
Choose a decision-worthy question
Start from a question someone can act on. “Has the campaign's reported cost per conversion crossed our review level?” can lead to a scoped investigation. “Is everything good?” has no defined metric or boundary. A useful alert does not need to explain the entire account. It needs to identify a condition that deserves attention and provide enough context for the next question.
Choose signals whose movement matters to the engagement. Cost, conversion volume, return and account or product health describe different concerns. A threshold should connect to a commercial or operational reason. If the client cannot explain why a crossing would prompt a review, the configuration may produce activity without improving decisions. More alerts are not automatically a more comprehensive advisory service.
Distinguish a fixed boundary from a relative anomaly. A fixed alert compares the observed metric with a chosen value. An anomaly workflow asks whether a result differs from a relevant historical baseline. Both can be useful, but they answer different questions. Do not describe a fixed CPA threshold as proof that today's result is statistically unusual, or a relative change as proof that it violates the client's acceptable acquisition cost.
Separate the question from the planned response. An alert about high cost per conversion may lead to measurement checks, query review, capacity discussion or a campaign decision. It should not presume that pausing is always correct. The threshold identifies the need for attention; the evidence and business context determine what advice follows.
Set the account and campaign scope
Scope determines what the metric describes. An account-level alert can show a broad condition while concealing differences between campaigns. A campaign-level alert can focus on an important offer but does not establish the health of the rest of the account. Choose the level that matches the engagement question, and make the selected account and campaign recognisable in the resulting notification.
Confirm the Slack connection before configuring client monitoring. Similar campaign names across accounts are common, especially when a consultant uses a consistent naming scheme. The connected channel should refer to the intended account. A meaningful campaign name helps the recipient recognise the offer, but duplicated names still require careful target resolution. Do not expose raw resource identifiers merely to avoid explaining the context.
Consider whether the scope will remain meaningful after a restructure. A campaign created for one short promotion may be paused when the promotion ends. Its alert can then require review rather than being copied to a new campaign automatically. A broad account signal may remain valid, but its interpretation can change when a new campaign contributes most of the spend. Configuration maintenance is part of keeping the question useful.
Keep audience and product scopes separate from campaign totals when the decision needs them. A campaign-level return figure does not identify which manually excluded product should be included. A Merchant health signal does not establish the campaign's budget setting. Use the alert as an entry point to focused data, preserving the scope of each follow-up rather than treating all account information as interchangeable.
Define the metric before its threshold
A threshold has meaning only with a metric definition. Cost per conversion divides cost by the relevant conversion count. ROAS divides the selected conversion value by cost. A conversion count can include several action types. Confirm what the client intends to measure before selecting a number, especially when the account mixes purchases, enquiries and calls.
Google's primary and secondary conversion guidance explains their different reporting roles and goal exceptions. Inspect the account's actual actions and goals rather than equating every recorded action with a purchase. For an advisory threshold, the important point is to understand the metric the configured tool uses and whether it represents the client's intended result.
A primary conversion value aggregate can contain values from non-purchase actions. That may be intentional, but it should not be described as purchase revenue without qualification. A consultant who wants a purchase-only question should ask for that scope in the investigation. Likewise, a lead count is not automatically a count of unique paying customers or completed sales. Preserve those differences in recommendations.
Check units as well as definitions. A currency threshold differs from a percentage or ratio threshold. Keep account currency visible in cost-related discussion and avoid unnecessary decimal precision. If the client's stated boundary uses a different unit from the supported configuration, resolve that interpretation before saving the alert. A valid comparison against the wrong unit is still a misleading signal.
Use the intended comparison boundary
Above, at-or-above, below and at-or-below represent different conditions. The equality boundary matters when a result lands exactly on the review level. Ask whether the client considers that boundary acceptable or actionable, then select the matching supported comparison. Do not rely on the ordinary-language phrase “around fifty” to decide a strict operator without clarification.
Use concrete examples when confirming the configuration. If cost per conversion at fifty should trigger attention, the inclusive upper comparison expresses that intent. If only a result greater than fifty matters, use the strict comparison. The client need not see a programming expression to understand the difference. A short explanation of what happens at the boundary is enough.
Choose the direction from the business concern. Higher cost may matter, while lower conversion volume or lower return may matter. A generic “performance warning” obscures those differences. Name the selected metric and condition in the configuration and response. This makes it easier to recognise a mistaken direction before the alert starts producing notifications.
The boundary is a review choice, not a universal benchmark. The same threshold can have different commercial meaning for a subscription business and a local appointment service. Keep the rationale in the engagement notes, then revisit it when pricing, margins or measurement change. Do not change the threshold simply to make a continuing problem appear recovered.
Choose the observation window
The observation window determines which data contributes to the result. Today so far, yesterday and a trailing period are different views of the account. Today is incomplete and can reflect opening hours or campaign schedules. Yesterday offers a completed calendar interval but can still depend on reporting maturity. A trailing period may smooth daily variation while including older operating conditions.
Choose the window to suit the decision. A launch availability concern can justify a near-term operational check. A commercial efficiency question may need a longer period with enough relevant conversions. A consultant should explain that choice to the client rather than treating the shortest window as automatically the most responsive or the longest as automatically the most reliable.
Keep account time zone in mind when discussing daily boundaries. A client's local day and the consultant's working day may differ. A notification near your morning can concern a different point in the account's day. State the reported window in the answer and avoid replacing it with an assumed local interpretation. This is particularly useful when a consultant supports clients in several countries.
Do not mix a rolling window with a calendar month in the explanation. A last-thirty-days result is not necessarily last month's result. If a follow-up chart uses another range, make that difference deliberate and visible. The investigation becomes harder when the alert and chart appear to describe the same interval but silently use different dates.
Separate evaluation cadence from evidence
The check interval controls how often the configured condition is evaluated. It does not change the observation window or turn the data into a live transaction stream. An hourly check of yesterday's result still concerns yesterday. Increasing the cadence cannot create new business evidence that the provider has not yet reported.
Choose cadence from the response need. A signal that the client only reviews during a scheduled weekly meeting rarely needs the same attention pattern as a critical launch condition. More frequent evaluations can be appropriate, but they should serve a decision. Avoid selecting the shortest option as a default simply because it sounds more protective.
A scheduled check is also separate from message delivery. The application evaluates the condition, records the result and queues relevant transitions for notification. The recipient should not infer that every evaluation produces a Slack message. Nor does a saved configuration establish that the first relevant notification has already reached its channel. Check the actual result and delivery when that matters.
Plan the human routine independently. If the consultant is unavailable outside agreed hours, identify who receives and investigates an important transition. An automated check can continue while nobody is actively reading the channel. That makes clear ownership more valuable, not less. Do not let a cadence setting substitute for a response arrangement the team has never agreed.
Understand firing and recovery transitions
Ordinary alerts are designed to speak when the condition changes. A newly triggered condition can produce a firing message. If the same condition remains triggered at the next check, the application can record that check without posting the same warning again. When a valid later observation returns within range, a recovery transition can be reported. This keeps continuing conditions from filling the channel with repeated identical messages.
No new warning therefore does not prove that the condition resolved. The prior firing state can remain active across subsequent checks. Read the monitoring state or ask for current evidence when the distinction matters. A consultant should not write a client update saying that an issue disappeared merely because the channel was quiet after its first notification.
Recovery describes the configured comparison, not every part of the business problem. A CPA result back within range does not prove that lead quality improved. A restored traffic signal does not certify a complete checkout journey. Keep the recovery statement tied to the metric, window and threshold. Then decide whether the advisory task needs additional evidence before closure.
Do not confuse transition state with human acknowledgement. A consultant can read a warning while its condition remains triggered. A client can acknowledge the message without approving a live edit. These are different events. The alert's state should be understood through its valid observations, while the task record captures investigation, advice and the client's decision.
Keep missing data out of healthy labels
An undefined metric is not a good result. Cost per conversion cannot be interpreted as zero when there are no relevant conversions to divide by. ROAS also needs its required denominator. The alert logic skips metrics whose necessary evidence is absent rather than treating missing arithmetic as a healthy observation. That distinction matters because a false recovery can close an advisory task prematurely.
A failed provider read is different again. The application cannot decide whether the configured condition is normal or triggered from data it did not retrieve. It retains the appropriate state and treats the evaluation as unavailable rather than inventing a successful check. The client-facing explanation should say that the evidence was unavailable, not that there was no activity.
Distinguish insufficient data from unavailable data in the follow-up. Insufficient data can mean a validly read interval lacks the volume needed for a particular calculation. Unavailable data means the relevant read did not establish the result. These conditions lead to different next steps: wait for more evidence or investigate the failed access or request. Neither automatically authorises a campaign change.
Use this distinction in client reporting as well. A blank metric should not become zero in a table simply to keep the layout tidy. State the reason when it affects the decision and avoid ranking unread targets as worst performers. A consultant's value comes from interpreting evidence accurately, including the cases where a conclusion is not yet supported.
Interpret zero spend in context
Zero spend can indicate an operational concern, but it can also reflect an intended schedule, a paused offer or the start of the account day. Ask what should have been running before treating it as an outage. A consultant overseeing a weekday service campaign needs a different interpretation from one reviewing a promotion that intentionally ended yesterday.
The zero-spend template has its own timing behaviour rather than treating midnight's empty day as immediate proof of failure. Keep the account-day context visible when interpreting it. A template signal still does not diagnose why spend is absent. It identifies the need to inspect relevant serving settings, account status and other evidence.
Check the expected campaign rather than enabling every paused campaign. A business may have inactive seasonal offers, old experiments and capacity-based pauses. Their existence does not mean the account should spend through them. If no enabled campaigns is the relevant condition, explain that directly and ask whether the owner intended to advertise now.
A supported enablement request should name the campaign and preserve the usual confirmation boundary. The alert is not permission to resume spending. If the account has another unresolved constraint, enabling a campaign may not restore delivery. Verify the requested status result and investigate actual availability separately instead of promising that a single switch repairs every cause of zero spend.
Separate Merchant health from product strategy
Merchant-related alerts concern the configured health condition and selected account context. A disapproval or health issue can matter to a retailer's availability, but it is not the same as a manual product exclusion in a campaign's listing tree. Ask which state the client wants to understand. Combining them into a single “products not running” count can conceal the repair that is actually needed.
Use the selected country and other applicable scope consistently. Product status can depend on the reporting context. A consultant reviewing one market should not describe that scoped result as the universal state of every product everywhere. If a follow-up broadens the scope, say so and keep the counts separate.
A timeout during a Merchant read is not a healthy verdict. Treat it as unavailable evidence and preserve the previous valid state where appropriate. The next task is to establish the health result, not to tell the retailer that all products are fine because no fresh issue list was returned. This is especially important when the client is preparing a promotion.
Assign the repair according to the reported cause. Feed data, website content, account requirements and campaign selection have different owners and tools. A consultant can explain the dependency and coordinate the next check. Do not offer a campaign product-selection edit as a universal repair for a Merchant policy issue that remains unresolved upstream.
Use Analytics signals with their own scope
An Analytics signal can add useful site-side context, but its property, segment and metric definition must remain explicit. Traffic sessions, events and purchase revenue are different observations. A campaign's Ads conversions are not automatically the same as a selected site's event count. Choose the signal that supports the advisory question rather than using whichever source returns a convenient number first.
Near-term Analytics monitoring and historical reporting also have different evidence. A real-time signal concerns a recent activity window with its own comparison logic. A daily historical chart concerns reported days. Do not use one as proof of the other without checking the scope. A quiet recent interval can need investigation while the historical report still looks normal.
For a lead comparison, select the corresponding event. The AI can inspect event names and suggest a likely candidate, but the client's site may use a custom name or record an event at a different stage of the form journey. A name that sounds plausible is a useful lead for investigation, not a verified equivalence. Keep the choice explicit before describing a cross-source result.
When a site-side condition changes, coordinate with whoever controls the website and measurement implementation. A supported Ads edit may be relevant later, but it does not fix a broken site event merely by changing a bidding target. Preserve the separate tasks: establish the observation, inspect the site dependency, choose a business response and approve any actual account mutation.
Control noise without hiding uncertainty
Noise usually comes from signals that lack a response purpose, overlap unnecessarily or are interpreted without their windows. Review the monitoring list with the client and ask what each configuration contributes. Two signals can both be valid, but if they prompt the same investigation every time, one may be sufficient. Simplifying the list can make the remaining messages easier to notice and act on.
Transition-based notifications already reduce repeated warnings for a continuing condition. Preserve that distinction when assessing volume. If the channel receives several messages, investigate whether they describe different conditions, different scopes or real recovery and firing transitions. Do not assume every additional message is a duplicate simply because its wording concerns the same broad account.
Keep unavailable evaluations visible in the operational record. Suppressing a noisy business alert and hiding a failed data read are different choices. The first can be a deliberate monitoring adjustment; the second can remove the evidence needed to know whether monitoring worked. The client should understand when a check could not establish its result, especially if the signal supports a time-sensitive decision.
Choose recipients and attention options deliberately. A message to an agreed working channel is different from drawing an entire channel's attention. Reserve stronger attention for conditions whose response arrangement justifies it. A consultant should not use every available mention option as a substitute for explaining urgency. Useful urgency comes from the business dependency and known evidence.
Assign who investigates and who decides
Give each important signal a named response owner. That person checks what happened and coordinates the next task. They need not be the person who approves an Ads change or repairs the website. In a consulting engagement, the consultant may investigate, the client may decide the commercial response and a developer may handle measurement. Keeping those roles separate avoids an alert sitting unattended because everyone assumes somebody else owns it.
Define the handoff when the consultant is unavailable. A signal can occur outside the consultant's working day. The client may choose to handle it internally or wait until the agreed review period. The monitoring configuration does not create a round-the-clock response team. Explain the practical arrangement before an urgent event, rather than discovering during it that nobody has authority to make the needed decision.
Ask the decision owner for business context early. A campaign may be paused because inventory is unavailable or appointments are full. Without that context, the consultant could mistake intended inactivity for a defect. The client can explain whether the observed condition is acceptable, but that explanation should be recorded rather than silently changing the threshold until the warning disappears.
Keep live approval with the authorised connected owner. The consultant's analysis can inform the proposal, and another colleague can help draft content, but execution has a specific authority boundary. Acknowledging an alert or agreeing with a recommendation does not itself execute an edit. The team should understand which later confirmation actually changes the live account.
Follow an invented consultant workflow
The following example is invented. A consultant advises North Vale Workshops on enquiry measurement and campaign efficiency. The client wants attention when the selected campaign's cost per conversion reaches its agreed review level. The consultant confirms the campaign, the relevant metric definition, an inclusive boundary and a completed observation window. The configuration is intended to prompt review, not automatically pause advertising.
A firing transition appears in the working channel. The consultant first checks whether the returned observation matches the saved scope and window. They inspect the campaign's cost and conversion evidence and ask the client whether anything changed in the offer or booking process. The client reports that a website form was updated. That business context creates a focused measurement task rather than an immediate budget recommendation.
The consultant asks for the relevant conversion actions and a selected site-side event comparison. They do not assume that every form-related event name means a completed enquiry. The website colleague checks the actual form journey. Meanwhile, the account configuration remains visible and the alert can remain triggered. A lack of another identical warning is not treated as proof that the website issue resolved.
After the site task is completed, the consultant reviews fresh evidence and the configured condition's later state. Any supported account edit is proposed separately for the connected owner. The client update distinguishes the original observation, the investigation, the website work and the later monitoring result. No part of the example claims that the alert itself diagnosed the cause or repaired the account.
Investigate with focused follow-up reads
Use the alert as a starting point for a bounded read. Ask for the metric and period needed to understand the condition, then inspect the relevant target or breakdown. A high campaign CPA does not require retrieving every product and placement in the account before the consultant can ask a useful next question. Focused investigation reduces waiting and keeps the evidence connected to the decision.
Discover available fields locally before requesting live data. The tool catalogue can explain supported metrics, resources and relationships without another provider call. Once the question is clear, retrieve the current scoped evidence. This separation helps the AI avoid repeated calls merely to learn what it can ask for, while retaining the reads necessary to establish actual account facts.
Reuse a returned analytical dataset when a chart or table asks for the same evidence. A daily series obtained for the answer can also support the requested visual. That is different from skipping a necessary current-state check before execution. Avoid duplicate reporting calls, but preserve the targeted reads needed to prepare and verify a supported edit.
When the evidence does not establish a cause, continue with the specific missing check. Ask the client about changes, inspect the relevant measurement or destination and compare suitable intervals. Do not fill the gap with an unsupported diagnosis. A useful advisory response identifies the actual next task and the evidence it will resolve, keeping the investigation practical rather than open-ended.
Write a useful Slack response
Lead with the observation in plain language: what crossed which boundary, for which scope and over which window. Then explain what that observation supports. A threshold crossing supports review of the selected metric. It does not by itself prove a broken campaign, poor traffic quality or a website defect. Keep the interpretation short enough that the client can identify the next decision.
Use names and parent context where needed. A campaign name can be sufficient for a campaign-level signal. A keyword or ad needs its group and campaign so the client can recognise it. Avoid technical IDs, undefined parent values and raw configuration dumps in the reply. The consultant can maintain detailed working evidence separately while the client sees the context needed to understand the issue.
Use a visual only when it helps answer the request. A requested chart can show the trend and selected metrics; a table can show relevant comparisons. Preserve the metric definitions and date range. When a longer requested series needs coarser grouping or separate panels under native chart limits, explain the actual presentation choice. Do not imply that a visual contains daily evidence when it only shows totals.
Finish with the concrete next task and its owner. For example, the consultant may inspect named conversion actions while the client confirms whether a booking change was intentional. Keep feedback controls at the end of the AI reply and avoid letting interface decoration obscure the task. The goal is a usable working conversation, not a polished-looking message that leaves everyone unsure what to do.
Separate a recommendation from execution
A recommendation explains a proposed response and the evidence behind it. It is not a live write. The consultant can recommend checking measurement, revising copy, changing a setting or accepting the current condition because of business context. These responses require different next steps. Do not turn every recommendation into an edit proposal before the client has chosen the intended action.
Creative advice can remain conversational. The AI can suggest headlines, descriptions or clearer explanations of an offer without calling the provider for every idea. The consultant and client can discuss those suggestions freely. Only when the owner asks to apply selected content should the application prepare a supported account operation with the exact target and complete desired material.
Explain why a setting change fits the business decision. Reducing a budget because capacity is temporarily constrained is different from claiming that a budget reduction will repair measurement. Pausing an unavailable offer differs from pausing the lowest-return campaign mechanically. Keep the reason tied to the current evidence and owner's context so the proposal does not appear inevitable merely because an alert fired.
Preserve unsupported tasks as clear handoffs. If the repair requires website work or a provider process outside the supported operation, say who needs to perform it and what should be checked afterwards. The useful analysis should not disappear because a live edit is unavailable, but neither should the application pretend that it can execute an operation it cannot support.
Review supported changes with the owner
A supported proposal should describe the exact target and each requested action visibly. A request to add keywords and enable a group contains separate logical steps. A campaign setting and a website repair also belong to different tasks. Do not compress them into a wall of text that makes it unclear what the confirmation will actually do.
Review the desired values and material side effects. A budget edit needs the correct currency or percentage interpretation. A complete RSA replacement needs all chosen creative, with the operation's treatment of paths and pins understood. A product-selection edit needs exact selected leaves and the right group context. The consultant should help the owner inspect these consequences before approval.
The connected owner uses Confirm and Execute for the prepared live change. The proposal expires after fifteen minutes and relevant settings are checked again before execution. A changed state can require a fresh proposal instead of silently overwriting another person's work. These checks keep the advisory recommendation attached to the actual current account decision.
Keep the progress state distinct from the outcome. A visible change-in-progress message confirms that processing started; it does not establish provider acceptance or read-back verification. Wait for the result before advising on another dependent edit. Repeated clicking should not become repeated execution, and an alert acknowledgement should never be substituted for the explicit confirmation.
Track the outcome without overclaiming
Record the result that was actually established. A verified edit means the supported requested state was checked. An acknowledgement can be narrower. An uncertain result after dispatch means the write may have reached the provider and needs reconciliation. These outcomes should not share one generic success label, because the consultant's next advice depends on which evidence exists.
Never automatically repeat an ambiguous creation or relative adjustment. The first operation may have succeeded even when the response was incomplete. Inspect the current target before deciding whether another request is needed. Otherwise, a repeated creation can duplicate assets and a repeated percentage adjustment can change the value again. The task is to reconcile, not to assume failure from silence.
Track later alert state separately from the edit receipt. A valid recovery observation may indicate that the configured metric returned within range, but it does not prove that the edit alone caused the change. Other account, website or market conditions may have changed. Keep the verified configuration result and later commercial evidence as separate parts of the advisory record.
Close the client task only to the extent supported. The task may be complete when the requested edit is verified and the agreed follow-up is performed. It may remain open if measurement, provider review or website work is outstanding. A concise description of what remains is more useful than declaring the account fixed while a material dependency is still unresolved.
Make the handoff usable
A handoff should allow another person to continue without repeating the entire investigation. Include the selected account and target context, the observed condition, the relevant window, completed checks and next task. Keep internal identifiers out of ordinary client-facing prose. The recipient needs to recognise the offer and understand the question, not reconstruct an API request from raw fields.
For a website or measurement task, describe the behaviour that needs checking. “Conversions are bad” is not enough for a developer. Explain which customer journey or selected event is relevant and what evidence raised the question. Do not claim the site is broken solely from an Ads threshold crossing. The handoff should preserve the distinction between an observation and the hypothesis being tested.
For an account task, include whether a proposal exists and whether it is pending, expired, executed or uncertain. An expired proposal needs fresh preparation; an uncertain dispatched write needs reconciliation. Those are different next actions. The next consultant or client colleague should not have to infer execution state from a conversational agreement earlier in the thread.
At the end of the engagement, review who owns the monitoring configurations. Disable or transfer the human responsibility as appropriate to the agreed arrangement, using the supported configuration workflow. Do not leave the client assuming that the outgoing consultant will continue responding indefinitely. Monitoring remains useful only when someone understands its purpose and owns the resulting tasks.
Maintain monitoring as the engagement changes
Review configurations when the account or business changes materially. New offers, campaign restructures, conversion-role changes and different capacity can alter the meaning of an existing threshold. A configuration that was useful for a launch may be inappropriate after the launch ends. Maintenance keeps the question relevant rather than treating saved alerts as permanent account truths.
Do not move thresholds only to silence a warning. First establish whether the business boundary changed or the condition still deserves attention. If the client consciously accepts a different acquisition cost because margins or lifetime value changed, record that reason. If measurement is broken, a looser threshold is not the repair. Keep the commercial decision and data issue separate.
Check recipients after staffing or channel changes. A useful signal delivered to a channel nobody reads can fail operationally despite successful processing. Confirm the intended working channel and attention options. The delivery arrangement should follow the response owner rather than an old default that was never revisited.
Periodically review the active list with the client. Retain configurations that support clear decisions, remove obsolete ones and keep unresolved data failures visible. Use monitoring principles and a scoped account review when appropriate, while keeping the consultant's actual engagement purpose at the centre of the routine.
Include the right evidence in client reporting
A client report should distinguish alert activity from account performance. A count of firing transitions is not a count of every evaluation or every day the condition persisted. A quiet channel is not proof that all metrics stayed healthy. Explain the configured scope and relevant states when summarising monitoring, rather than turning message volume into a score for the account.
Include the investigation and decision where they add meaning. The client needs to know what was observed, what was checked, what they chose and what happened afterwards. Do not fill the report with every skipped or unchanged check unless those details answer a question. Keep the important unavailable intervals visible when they limit the conclusion.
Use consistent periods and definitions for performance figures. If the alert used a trailing window and the monthly report uses a calendar month, state the difference. If the report compares Ads value with GA4 purchase revenue, preserve their source labels and scopes. The report should explain compatible business comparisons without pretending distinct measurement systems produce identical totals.
Keep claims proportional to evidence. “The requested status change was verified” is a supported execution statement. “The later metric returned within the configured range” is a supported monitoring statement when observed. “The change recovered all lost sales” needs evidence those records alone do not provide. The consultant's credibility comes from clear, specific conclusions that the client can assess.
Answer common advisory questions
Will a triggered alert pause the campaign?
No. The ordinary alert reports the configured condition. Investigation, recommendation and a supported live edit are separate steps. The connected owner must approve a conversational proposal before it executes. Separately configured Rules have their own triggers and modes.
Why did the same warning not appear again?
Ordinary alerts report state transitions rather than repeating the same continuing warning at every check. Inspect the current monitoring state when you need to know whether the condition remains triggered. Silence alone does not establish recovery.
Can no conversions count as a healthy CPA?
No. Without the necessary conversion denominator, cost per conversion is undefined. The metric is skipped rather than interpreted as zero. Check the relevant data and business context before advising on the next action.
Does recovery prove the problem is fixed?
Recovery means a valid observed metric returned within the configured boundary. It does not certify the whole website or establish the cause of the change. Close the advisory task only when the agreed checks support that conclusion.
Who approves a change that I recommend?
The authorised connected owner reviews the exact supported proposal and uses Confirm and Execute. Your recommendation can explain the reason and evidence, but it is distinct from that live approval. Keep the target, requested steps and outcome clear in the thread.