Verify each measurement layer instead of treating a green setting as complete tracking
Is my Google Ads tracking set up correctly? An agency guide to account settings, website evidence and reliable reporting
Check the account's measurement configuration, the intended conversion actions, the click-to-landing journey and the collected business event. Correct settings are necessary evidence, but they do not certify that every website event reaches the right destination.
Define what correct tracking means for this client
Begin with the business event the client needs to measure. Completed purchases, initial enquiries, calls and offline sales can all be legitimate outcomes, but each requires a specific definition and collection path. An agency should ask which outcomes drive the client's decisions and which are supporting diagnostics. Then establish the connected account, relevant website and linked analytics property. A broad request to check tracking can otherwise produce a list of settings without answering whether the client's actual sales or leads are represented. The first result should name the investigated outcome and scope, rather than issuing an account-wide certificate from one successful API read.
Define the decision that depends on the measurement. The client might need to trust a weekly report, support bidding, validate a site migration or investigate a sudden decline. A report-definition concern can be resolved through correctly selected outcomes, while an implementation concern needs collection evidence. A campaign optimization question may require current goal settings as well as action metadata. Keep those purposes distinct. The agency can still conduct a wider review, but each finding should state what it checked and which decision it informs. This prevents an unrelated configuration recommendation from being presented as the cause of a specific reporting discrepancy.
Write the expected behavior in ordinary language. For a purchase, one completed transaction should produce the intended event with the correct value, currency and identity at the agreed destination. For a lead, the event should correspond to the intended submission or business stage, rather than an incidental page view or button interaction. For an offline result, the source owner should establish the actual upload process and event meaning. These expectations guide the verification work. They are not facts the assistant can infer from a conversion name alone. A readable measurement map lets the client and implementation owner agree on what success would look like before changing anything.
Retain a clear scope of evidence. The app can inspect supported account settings, configured actions and reportable outcomes. Some audit checks parse configured URLs, while others read provider diagnostics or performance. Those checks are valuable, but they do not automatically test the live form, checkout, redirects and every external integration. The agency should explain which layers were verified and identify the remaining owner-led checks. That is a useful complete answer to the request, not an excuse to avoid investigation. Accurate boundaries allow the client to act on the findings without mistaking a partial green result for proof that the entire measurement journey is healthy.
Map the separate measurement layers
Separate the account, destination, collection and reporting layers. Account configuration establishes settings such as auto-tagging and conversion-action roles. The destination journey establishes whether the user and relevant click information reach the intended page. Collection establishes what the website or integration sends after the business event. Reporting establishes how the selected source attributes and presents those outcomes. Each layer can be correct while another is wrong. An enabled account setting cannot prove a redirect preserves information, and a working event trigger cannot prove a management report selected the right action population. The investigation should trace the relevant dependencies instead of treating all tracking facts as one toggle.
Create a concise map for the client. Name the business event, its source path, intended Ads action, related GA4 event where applicable and the owner of each implementation. Include the report definition that the agency normally uses. This map makes overlapping measurement visible: a native purchase action and an imported purchase action can both exist without their names explaining whether they represent the same transaction. The map also makes missing ownership visible. If nobody can verify the website trigger or import process, an account API review alone cannot close the question. Ask the client to involve the appropriate owner for that specific unresolved layer.
Read the relevant configuration and outcomes before expanding into every connected system. A clear account-level question may need only a focused setting read. A sudden purchase decline may need named action contribution and collection checks. A paid-traffic attribution problem may point toward the landing journey. The generic reporting framework can discover supported fields and relationships, allowing the assistant to choose the required surface. Local capability checks avoid calls that cannot answer the question. The agency should not routinely run Merchant inventory scans, keyword reports and policy audits simply because they are available while the actual concern is a form event.
Keep observations separate from interpretations in the working record. “Auto-tagging is enabled” is a configuration fact. “The controlled landing journey retained the relevant parameter” is a verified destination fact. “The test submission reached the intended event destination” is collection evidence. “The selected primary action reported outcomes during this period” is reporting evidence. An agency recommendation combines those facts with the business requirement, but should not erase their distinctions. This makes handovers clear and allows a later reviewer to see which layer needs rechecking after a site or account change.
Read account configuration without overstating it
Read the current account setting relevant to the question. Auto-tagging, tracking templates and conversion-tracking configuration have different meanings and editability. A successful current read establishes the provider's reported state at that time. It does not reconstruct historical settings or prove every downstream system works. The audit's no-tracking check combines tracking configuration or an absence of configured actions with recorded conversion activity. Interpret that actual condition rather than reducing it to “zero conversions means no tag.” An account can have a configured measurement path and no outcomes in a selected window, or a measurement issue despite some recorded activity.
Auto-tagging is important to the click-information journey. Google's auto-tagging guidance describes how click information is added to destination URLs and explains that redirects need to preserve it. The account's enabled state is therefore one part of the investigation. The website owner still needs to verify the relevant live path. A client whose account passes the setting check can have a redirect or parameter-handling problem downstream. Explain that dependency plainly rather than calling the entire tracking setup correct solely because the account switch is on.
Enhanced Conversions for Leads has separate configuration and implementation signals. The audit reads whether the account setting is enabled and whether the relevant data terms are accepted. Those facts do not prove that the tag sends the required user-provided data through the intended implementation. The account's conversion-tracking settings include read-only output, and accepted terms involve a human consent process. Do not advertise a simple API toggle that completes this setup. The agency should describe the observed signals and assign the missing implementation or owner action accurately. A working downstream test remains necessary for the specific business event being investigated.
Preserve access and provider failures as operational limitations. A failed setting read is not an off setting. An expired account authorization is not proof that tracking was removed from the website. The app should explain which surface could not be inspected and keep any independently verified facts separate. This prevents a connection problem from turning into an unnecessary measurement change. For an agency portfolio, distinguish client access tasks from account configuration tasks in the handoff. The next step should resolve the specific missing evidence instead of rerunning the entire audit and hoping a more convenient result appears.
Select and inspect the intended actions
Use the conversion catalogue to inspect action names, categories, types, primary roles, status and any associated GA4 event metadata. Configured actions with no activity are still relevant to establishing the intended measurement map. A performance report alone may not show them. Current metadata and dated contribution are separate reads with separate conclusions: configuration identifies what exists, while reporting identifies observed outcomes in the selected period. The assistant should retain both without claiming that the existence of a purchase action proves checkout collection works. The client can then see whether the intended event has a corresponding account configuration before the implementation owner verifies the event path.
Resolve named selections exactly and handle ambiguity. “Contact Form” can exist more than once or be confused with a similar action. The framework normalizes case and spacing for exact-name matching rather than choosing a partial match arbitrarily. If several actions share the selected name, request the relevant distinction. This is safer than selecting whichever action has the largest reported value and assuming it represents the client's intent. Keep explanatory labels readable and avoid adding raw resource numbers to client-facing action names. The internal target identity should remain precise even when the visible description uses plain names and source details.
Choose the outcome family deliberately. All primary conversions includes the applicable selected primary actions; purchases narrows to primary purchase categories; broad leads combines selected primary lead categories. Calls and offline groupings can overlap with lead categories, so their totals should not be added as if they were independent populations. A named action can answer a more specific business question. Secondary actions stay outside the normal primary view unless explicitly requested. The assistant should explain that selection when it materially affects the result and preserve it through a requested chart or comparison rather than changing definitions mid-conversation.
Check whether a report's value actually means purchase revenue. All primary conversion value can include valued non-purchase actions, including leads or calls. The presence of money in a result does not certify a checkout event. Use primary purchase-only value for a purchase question, or label the broader selected value accurately when the user requests it. Do not silently remove one primary action because the agency suspects overlapping measurement; the tool should report the requested population faithfully. Investigate the source design separately. The agency duplication guide explains that distinction in detail.
Review roles, counting and values independently
Primary and secondary roles describe the configured outcome selection, while counting settings describe how each action counts conversions after an interaction. Neither fact is a unique-person identifier. Several legitimate business events can occur in one journey, and several primary actions can contribute to a report. A role review should identify the intended reporting and optimization use, with campaign goal context where relevant. Do not present the current primary flag as an exhaustive account-wide bidding explanation. If the client's concern is a misleading management total, a clearly selected report may answer it without any live configuration change.
The current audit uses category-based recommendations for counting and ecommerce readiness. Those are application review policies, not a universal proof that every differing client setup is broken. For ecommerce, the readiness recommendation prefers a selected web purchase source and reviews competing primary contributions. Its source ranking does not establish which collection path is healthiest on this client's website. A native action can be incorrectly implemented, while an imported action can represent the intended event accurately. The agency should inspect the actual measurement map and evidence before applying a recommendation. Read the finding as a prompt for the specific configuration review it performed.
Counting many can be appropriate for repeated real purchases, while one per interaction can fit a particular lead definition. The business event and source restrictions determine the supported choice. A counting change does not repair a duplicated trigger or add transaction identity to a website signal. The bulk builder discovers its enabled eligible actions and skips locked source/type combinations; its executable set is not automatically identical to every audit finding. Show the actual proposed actions clearly. The counting review is useful for that configuration branch, but its successful fix should not be described as a complete website tracking repair.
Values require a separate implementation review when the client expects transaction-specific revenue. Confirm the intended currency and value meaning, and ask the source owner to verify the actual transmitted behavior. A configured default value is not proof that every purchase's real value was sent. A named action's reported value may be appropriate for one business objective and misleading for another. Keep that interpretation separate from counting and role choices. The agency can propose supported settings after verification, but should not change several unrelated fields simply because the original request used the broad word tracking.
Verify click information through the landing journey
Trace the intended paid landing journey with the website owner. Establish the ad destination, any redirect chain and the final page that the user reaches. The account's current configured URL can be read, but a configured field is not proof of the live HTTP behavior. A redirect, URL rewrite or application route can handle query information differently from the original destination. The appropriate controlled test should observe that path and the relevant information it retains. Do not claim the assistant performed a live browser or network verification unless that verification actually happened through a supported tool and its evidence is available.
Parameter preservation and page availability are distinct checks. A destination can load successfully while dropping information needed for attribution, and a URL can retain parameters while leading to an unusable page. The client needs both facts when the concern spans traffic attribution and conversion collection. The agency should assign each check to the owner who can observe and repair it. A provider destination-policy finding can identify reported concerns, but it does not replace every live test. Conversely, a manual page visit does not establish that every ad-specific URL path behaves identically. Use the actual relevant destination and selected context.
Check consent and collection behavior through the appropriate implementation process rather than assuming every visit should produce the same visible analytics result. The business and implementation owners need to understand how the site behaves for the relevant user journey. The performance tool cannot infer that behavior from a single aggregate discrepancy. A controlled test should document what was observed without exposing unnecessary personal information in Slack. The agency can then relate those findings to the report and decide whether a technical repair is required. A short explanation of verified behavior is more useful than speculative blame assigned to the browser, website or ad platform.
If the problem is verified at the destination layer, keep its repair separate from account edits. Enabling auto-tagging cannot by itself repair a redirect that discards information. Changing a final URL can move traffic to another page, but the new page still needs appropriate verification and a precise supported proposal. The catalogue marks the generic final-URL-to-HTTPS action unavailable because its required destination verification is not available in that path. Do not advertise that unavailable action as a universal tracking fix. The owner can verify the working destination and then use the applicable supported edit flow for the exact asset.
Review templates, suffixes and manual tags
Tracking templates, final URL suffixes and final URLs are different settings. Clearing one does not imply the others changed. A template can involve a third-party tracking path, while a suffix can append relevant parameters to the destination. Inspect the exact fields and their applicable scope before proposing removal. The current account clear-template action changes that selected template and retains the final URL suffix. The proposal should describe that effect faithfully. An agency should not tell the client that all tracking parameters were removed when only one account setting was cleared.
The landing-page tag audit parses configured final URLs for manual campaign tags. It distinguishes tags that describe a paid campaign from conflicting unpaid-source tags and preserves unparseable URLs as reviewable rather than silently passing them. These findings concern the configured URLs the check read. They are not proof of the final resolved live URL, the website's actual analytics classification or every redirect. Associated historical cost describes the selected URL rows; it does not establish money lost through misattribution. Use that evidence to open a focused attribution review and involve the relevant source or website owner when the actual behavior remains unverified.
Recognized vendor patterns can help identify a likely origin for a template or tag, but they do not certify the client's integration health. The audit has specific recognition logic rather than knowledge of every possible third-party implementation. An unfamiliar pattern should remain a review question. Do not infer that an unrecognized template is malicious or unnecessary solely because the app cannot name it. Ask the owner why it exists and which downstream process depends on it. A supported clear-template proposal can then be made when the client deliberately chooses that effect and understands the retained settings.
Follow the agency landing-tag guide for the configured URL branch and keep the actual live journey evidence separate. If the client wants to remove conflicting tags from several assets, show each supported target and exact effect. A campaign setting and an ad URL replacement are not interchangeable. Preserving parent names and a clear current-to-requested change makes the proposal understandable. Do not combine external redirect work with executable Ads effects in a way that suggests one confirmation automatically publishes the website repair.
Verify collection with the implementation owner
For the selected business event, ask the implementation owner to observe the actual trigger and destination. A purchase should correspond to the intended completed transaction, not simply visiting a generic page. A form event should reflect the agreed submission or stage, not an incidental click unless that is deliberately the metric. The controlled test should establish what fired, where it was sent and which relevant value or identity accompanied it. Aggregate Ads activity cannot supply those facts on its own. The agency can coordinate the process and interpret the results, while the owner of the site or integration supplies the collection evidence.
Repeated collection and missing collection need different verification. A duplicated trigger can send the same business event several times, while an incomplete implementation can miss valid events. Transaction identity also needs correct consistency for the same event and distinctness for separate events. A static identity can create undercounting even when the field appears present. Do not repair a diagnostic by filling a placeholder and assuming the business-event problem is solved. The controlled process should test the relevant repeated and new-event behaviors and record the actual findings in the authorized working context.
Offline paths need the source owner's evidence as well. A configured upload action can be listed and its observed contribution reported, but the account catalogue does not certify the CRM's export, matching or event meaning. Establish the intended event and process before interpreting a gap as failed collection. Calls deserve the same care: a telephone-link event is not automatically a completed tracked call. Choose the actual corresponding event when comparing sources. The assistant can suggest likely names from an available event list, but the owner should confirm the mapping when it is not already established.
Keep implementation verification privacy-conscious and concise. The client-facing explanation should state the event behavior and outcome of the test, without dumping customer payloads, personal data or unrelated account details into Slack. Use the authorized implementation tools and business records for detailed evidence. A failure should receive a precise handoff: this event path, this observed behavior and this required repair. The app's account-setting changes remain separate from source publishing. A complete tracking review identifies both sets of work and the evidence required to close them rather than declaring success after the easiest available toggle.
Compare Ads and GA4 using explicit definitions
Ads and GA4 comparisons can reveal useful patterns when the measures and scopes are explicit. Primary purchase count can be compared with GA4 purchases, while primary purchase value can be compared with GA4 purchase revenue as separately labeled series. Broad primary conversions can be compared with selected GA4 key events when requested. A named Ads action can be compared with a confirmed GA4 event. Preserve each source's definition, traffic scope and dates. The framework should select compatible measurements from its library rather than block useful source comparisons or equate every field with a similar name.
Google's clicks-and-sessions troubleshooting guidance explains that clicks and sessions are different measures and can differ without a technical defect. It also identifies implementation and landing-journey concerns that can warrant investigation. A click-to-session discrepancy therefore needs interpretation rather than an expectation of exact equality. The agency should establish the relevant paid traffic scope and observe the destination or collection behavior when evidence points there. A ratio between two aggregate measures is a useful signal, not a proof that every unmatched click was lost by the website.
Choose the GA4 event deliberately for lead or call comparisons. A probable name can be suggested, but the client should confirm the corresponding business event when the mapping is unknown. An event count does not automatically represent unique leads, and a telephone click does not certify a call. The same confirmed selector should remain available for follow-up requests. If the client asks for total paid traffic rather than one paid channel, use the applicable aggregate scope rather than returning a single channel and describing it as the total. The selection is part of the result, not an implementation detail the assistant can change invisibly.
Revenue scope also affects return. All-traffic GA4 revenue divided by advertising cost is a blended ROAS or MER view, rather than the same attribution definition as an Ads purchase return. Label it accordingly when the client requests it. Do not compare unrelated spend and publisher revenue merely because both are currency. A combined chart can show the selected compatible source measures without summing them into one total. The agency should explain the meaningful difference and investigate any unresolved collection concern separately, avoiding a simplistic assertion that the sources must match exactly for tracking to be correct.
Align reporting periods and change evidence
State the exact dates behind a rolling period and distinguish it from last month. Use the selected account time zone and identify whether the last day is completed or partial. The reporting framework can retain period context through a follow-up, so a request for the same chart should not restart with an unrelated date default. Current-year chart labels should be readable rather than raw provider date keys. For weekly views, an actual date range helps the client interpret the period. Clear labels prevent a timing misunderstanding from being mistaken for a tracking defect.
Choose the date basis for outcomes deliberately. Conversion-date reporting shows when an outcome occurred; interaction-date reporting relates it to the earlier advertising interaction. A delayed or offline result can affect these views differently. Keep that basis consistent within a comparison and state the intended interpretation when cost and outcomes are discussed together. A recent decline in one basis is not automatically a missing-event problem. Review reporting maturity and the selected action contribution before changing configuration. The agency should not promise an exact source match after casually mixing different date bases.
Read available change evidence when timing matters. A role change, template update, new action or site release may align with a reporting shift. Account change history is bounded and does not include every external website or integration modification. Current settings do not prove their historical state. Ask the relevant owner for release records or collection evidence where needed. The change-history workflow supports the account-side branch, but it is not a complete archive of the business's measurement environment. Keep the source of each timing fact clear.
Distinguish correlation from a verified cause. A reporting shift after a deployment is a useful investigation clue, while a controlled event test can establish the affected collection behavior. A correct account setting after a repair is configuration evidence, while mature future reporting can show the subsequent pattern. These facts complement each other without becoming interchangeable. Do not declare a release guilty solely because it is the nearest timestamp, or declare the repair complete solely because a chart becomes smaller. The agency's conclusion should identify the evidence that actually supports the mechanism and retain unresolved layers as specific tasks.
Follow an illustrative agency review
Consider a fictional investigation by Theo Vale at Birch Media for the invented Cedar Home Workshop. These names and events are illustrative and do not describe a customer result. The client says tracking looks wrong after a website change. Theo confirms that the concern is primary purchase measurement in the connected Ads account and its linked GA4 property. The assistant reads the relevant action catalogue and selected daily outcome contributions for the completed comparison periods. Auto-tagging is enabled, but the agency does not treat that fact as proof the new website preserves click information or sends the intended checkout event.
The configured URL review shows a manual-tag concern on one destination branch. Theo asks the website owner to verify the actual paid landing journey, while the analytics owner checks the selected purchase event. The live test identifies a redirect behavior that needs repair. A separate action breakdown shows that the management report previously included valued non-purchase primary actions under a revenue-like label. The agency corrects the report definition separately from the website task. It does not claim that changing the label repairs collection, or that the redirect defect explains every difference between the two source totals.
The client also asks for the counting settings to be reviewed. Theo interprets the audit's category recommendation against the business measurement map and prepares only the supported action the owner actually chooses. A source-restricted action remains an external task. The proposal describes the named conversion and exact counting change, while the redirect repair stays assigned to the website owner. Clear separate effects prevent the client from believing that one Confirm and Execute click publishes all changes across Ads, the site and analytics. The app verifies the supported account configuration; the owners supply the collection and destination evidence.
After the external repair and approved setting work, Theo reviews fresh mature reporting under the agreed purchase definition. Ads and GA4 remain separately labeled, with the relevant traffic and date scopes. The final explanation states what was verified at each layer and which differences are still attributable to definitions rather than a proven defect. The example demonstrates the agency's practical value: turning a broad tracking complaint into a measurement map, focused reads, clear ownership and specific closure evidence. A reusable framework supports the process without hardcoded rules that assume every client's event name and website path are identical.
Use focused Slack investigation
Start with an outcome-specific request: “Check the configured purchase actions and auto-tagging for this account, then show primary purchase outcomes for the selected completed period.” Supply or confirm the relevant dates and business definition. The assistant should select the supported fields and relationships rather than treating the sentence as permission to run every account tool. If the channel lacks the required account connection, explain the requirement politely and provide the supported connection flow. A missing connection is not a clean tracking result. The agency can also use /ppctor audit for the broader configured review, interpreting each finding according to its actual test.
Follow up against the established evidence. “Show the named purchase action separately,” “compare it with the confirmed GA4 event,” and “which configured URLs carry conflicting tags?” are focused questions with different relevant surfaces. Reuse the verified dataset for sorting and supported visuals when it already contains the needed scope. Read again when the user changes the period, requests another source or needs current settings for an edit. The assistant should preserve the context of references such as this action and the same dates, while asking a narrow question if the referent is genuinely ambiguous.
Creative assistance belongs naturally beside the reads. The assistant can draft a handoff to the website owner, write a client explanation or propose a controlled-test checklist from the verified findings without an additional API call for each sentence. Those drafts should not claim unperformed tests. A request for actual configuration or measured outcomes still requires the appropriate read. This distinction improves both speed and usefulness: the model interprets and communicates known facts conversationally, while tools retrieve missing evidence. Ordinary discussion should not automatically launch Keyword Planner or unrelated reports.
For a requested chart, select the compatible series and grain from the data framework and aim for one readable native chart. A longer period can use weekly or monthly aggregation when daily detail was not requested. Explicit daily detail beyond the native limit can require multiple charts with the limit explained. Do not split a single metric arbitrarily without telling the client why. A graph can reveal timing, but it should not upgrade an unresolved collection hypothesis into a verified cause. Keep the source labels, outcome selectors and date interpretation alongside the visual.
Assign precise repairs and closure evidence
Turn each finding into a task with a target, owner and verification method. Account settings belong to the supported Ads edit flow. Website redirects and triggers belong to the implementation owner. Analytics event mapping belongs to the relevant analytics configuration owner. An offline import needs its source owner. The client should see which tasks can be executed in the app and which require work elsewhere. A vague instruction to fix tracking conceals these boundaries. A precise task says what behavior was observed, what desired behavior is required and which evidence will establish completion.
Choose the smallest repair supported by the evidence. A report-label problem needs a report-definition correction. A conflicting configured tag needs its exact supported target or external source repair. A redirect defect needs website work. A counting policy mismatch needs a reviewed setting change. Do not mutate unrelated goals or clear every template because one branch failed. The agency's plan can describe the wider measurement design conversationally while preparing only the live effects the client selected. Local capabilities and dependency rules establish what can be planned without broad provider discovery, while actual targets still need focused current-state checks.
Define closure separately for each layer. A successful desired-state read closes a supported configuration effect. A controlled live journey can verify the destination behavior. A test event can verify collection. A reproducible report under the agreed definition can verify selection and presentation. Later mature outcomes provide follow-up evidence but do not replace those immediate checks. A deployment alone does not prove provider receipt, and a provider total alone does not prove every source path. The agency should retain the actual evidence rather than relying on an owner saying “done” without the relevant verification.
Keep the client's explanation concise and practical. State the verified issue, completed effect and remaining external task. Avoid internal JSON, provider version lines and unnecessary customer data. The fuller working record can preserve useful technical details for the authorized implementation owner. When a repair is incomplete, say which specific layer remains unresolved and what will resolve it. That is more useful than a generic warning or an account-wide tracking-failed label. It also keeps the agency's next testing steps aligned with the affected behavior instead of continuing unrelated tests while a known dependency remains broken.
Approve supported account changes clearly
A supported live proposal should show the exact target and change on separate readable steps. For an account setting, name the connected account and desired setting. For an action setting, name the conversion action and current-to-requested value. For an asset URL change, preserve its meaningful parent hierarchy. Keep internal identifiers out of the explanatory labels. The client must be able to distinguish a template clear from a suffix change and a counting change from a role change. A technically correct request with an ambiguous description is still an unsafe approval experience.
Include the notice: “No changes have been made yet. This proposal expires in 15 minutes.” Preparing the proposal does not send the mutation. The connected owner confirms through Confirm and Execute, after which authorization and relevant current settings are checked again with supported validation. If the target or parameters change, prepare the revised proposal rather than applying an old confirmation to a new effect. A multi-effect request must display every intended supported step clearly. An overly broad request should be divided without silently dropping later tasks or claiming the entire measurement plan was executed.
Make the in-progress state clearly visible after confirmation. Then report the actual execution and available verification for each effect. A read-back verified auto-tagging state establishes that setting, not the website journey. A verified counting change establishes the requested account configuration, not transaction-level deduplication. If a write was sent but complete verification failed, preserve that state and avoid automatically replaying it. A focused current-state review can establish the next safe action. The client should never have to infer whether a click was received or whether a second click might create an unwanted repeated operation.
Separate the execution result from business recovery. A successful account update may be part of the repair, while the external implementation and reporting follow-up remain pending. Show those tasks distinctly. The agency approval guide describes the shared flow, and this tracking investigation supplies the actual setting and source boundaries. Clear completion gives the client confidence in what changed without promising that all historical data was rewritten or that every future event will be measured perfectly. Verification should be scoped to the evidence it actually obtained.
Maintain an evidence-based measurement routine
Keep a measurement map for each client that records the intended business events, source paths, primary and diagnostic selections, reporting definitions and responsible owners. Update it when the website, source integration or account goal changes. This is practical context for a later Slack conversation and a new agency reviewer. It does not replace current-state reads or implementation tests when a change makes them necessary. The map should help identify the relevant layer quickly, allowing a focused investigation instead of repeated broad scans and speculative conclusions.
Review outcomes under consistent periods and definitions. If the client intentionally changes the selected primary population, document that change rather than presenting the new total as a continuous series with the old definition. Keep source comparisons labeled and preserve the confirmed event mapping. Current metadata can guide the report, while historical interpretation may need the recorded earlier configuration. A clean chart is useful only when its underlying meaning is stable. The agency should make these changes understandable to the client without adding a wall of implementation detail to every normal response.
Use alerts and anomaly signals for their supported conditions as prompts for investigation. A sudden outcome decline can arise from traffic, business behavior, configuration or collection. The signal does not identify the cause by itself. Start with the relevant action contribution and period, then expand to the layer the evidence points toward. Reuse verified datasets for presentation and avoid unrelated reads. If a known defect affects the next test, repair and verify it before continuing dependent testing. This routine keeps the agency's work focused on resolving the actual client concern rather than accumulating disconnected green checks.
A trustworthy answer to “is tracking set up correctly?” states the verified scope: which account settings were read, which actions and definitions were selected, which live journey and event behavior were tested, and which supported changes were confirmed. It identifies remaining external checks without disguising them as a completed universal audit. The reusable framework handles fields, conditions, relationships and supported edits, while the agency supplies the business interpretation and ownership. The client receives a clear measurement record and a practical next review, with confidence grounded in specific evidence rather than the appearance of one passing setting.