Unsure about your Google Analytics data?

1) Connect Tag Assistant and confirm your browser appears in DebugView. 2) Complete the test journey and record the order ID. 3) Review the purchase event and the tags sending it to each destination. 4) Reload the confirmation page and return to it from your browsing history: record any new submissions. 5) If retries are expected, request evidence of deduplication for each destination. Use the reconciliation check to compare totals with the store: there is no universal 5% margin that validates an implementation.

Open in your property: DebugView

You can mark this as verified if: The order has a stable identifier and does not generate additional purchases in the destinations reviewed. Any expected resubmission has a verified deduplication mechanism.

Investigate further if: One action fires two tags for the same destination, the ID changes on reload, or resubmissions occur without verified deduplication.

Keep DebugView open in one tab and browse the site in another as a new visitor: home, a category and a blog article. No add_to_cart, begin_checkout, add_shipping_info or purchase should appear in the event stream. Then open product A and add it to the cart: one add_to_cart should appear when you click the button. Click that event and open the items parameter or item tab in the details on the right: the name or ID should match product A. Without emptying the cart, visit the home page and another category: no new add_to_cart should appear. Open a different product B and add it: a second add_to_cart should appear with product B in items, not A. Finally, open the cart and click through to checkout: begin_checkout should appear once. Return to the home page and check that it does not repeat.

Open in your property: DebugView

You can mark this as verified if: No content page fires cart or checkout events; each add_to_cart appears once with the product just added; begin_checkout appears only when entering checkout and does not repeat while browsing.

Investigate further if: An add_to_cart or begin_checkout appears when the home page loads, repeats while browsing or contains the previous product's data.

1) List the actions available in your store: view a product, add or remove items, open the cart, begin checkout, provide shipping or payment information, and confirm a purchase. 2) With debugging enabled, perform those actions and verify their events: view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info and purchase, as applicable. 3) Repeat relevant journeys by device and payment method. 4) Use historical reports to identify breaks or differences and compare them with activity volume. An isolated zero or a step omitted by design does not prove a fault.

Open in your property: DebugView

You can mark this as verified if: Expected events appear when their actions are performed, and steps that do not apply are documented.

Investigate further if: You perform an expected action and its event does not arrive, repeats or contains incorrect data. Comparison across devices or payment methods shows a difference you have not yet explained.

1) Request the inventory of authorized containers and destinations. 2) Visit the home, product and checkout pages with Tag Assistant. 3) Compare detected IDs with the inventory. 4) For each additional tag, verify its purpose, owner and destination. Several valid IDs or a tag with multiple destinations may coexist: the count alone does not prove duplication. 5) Document any unknown ID before proposing its removal.

Open in your property: Data streams

You can mark this as verified if: Each container and destination has a known purpose, and events reach the intended properties without unintended duplication.

Investigate further if: A destination has no owner, a previous property is still receiving data by mistake, or two implementations send the same action to the same destination.

1) List the parameters each event needs under the measurement plan, such as page type or logged-in status. 2) In Tag Assistant, select the event that fires the tag and review variable values at that moment. 3) Compare the parameters received in DebugView. 4) Do not require data that does not yet exist at that step, such as the identity of someone who has not signed in. A value configured in a tag does not by itself prove receipt: if the interface cannot confirm it, ask for the sent request or corresponding log to be reviewed.

Open in your property: DebugView

You can mark this as verified if: Parameters required for that action have correct values when sent, and there is evidence they were received.

Investigate further if: Data that should be available is missing, values from a previous action arrive, or the variable is populated only after the event is sent.

1) Define which pages and virtual views your measurement plan counts. 2) Browse a sample including product, cart and checkout with debugging enabled. 3) Verify one page_view per intended view, with correct page_location and page_title. 4) If duplicates occur, check whether automatic measurement and a manual tag cover the same view. Mechanisms may coexist for different journeys; what must be avoided is sending the same view twice.

Open in your property: DebugView · Data streams

You can mark this as verified if: Each intended view generates one page_view with the corresponding URL and title.

Investigate further if: A view is duplicated, an intended view is not recorded, or the event retains the previous URL or title.

1) Compare the names sent with the recommended names for implemented actions, respecting case and underscores. 2) In DebugView, review items and product identification; for purchase, also review transaction_id, value and currency when a value is reported. 3) Compare products and metrics in Ecommerce purchases. 4) If an event is absent from a recent list, reproduce its action or extend the date range before concluding it is missing. An empty report requires a review of configuration, filters and available data.

Open in your property: DebugView

You can mark this as verified if: Implemented actions use the intended names, their parameters identify the products, and reports receive the necessary data.

Investigate further if: Names do not match recommended events, products are unidentified, or required parameters fail to arrive in a verifiable test.

1) Confirm how your team distinguishes tests from customer traffic: a separate property, internal traffic rules or another documented criterion. 2) Check that it covers the environments and networks used for testing. 3) Verify filter status and effects before activating them; active exclusion permanently affects processed data. 4) Review hostnames and explain any that are not production hosts. Not every business has a fixed office IP, and a filter in testing mode may be a deliberate validation step.

Open in your property: Data streams · Data filters

You can mark this as verified if: A documented, validated approach separates or identifies tests without mistakenly excluding customer traffic.

Investigate further if: Test environments contaminate decision-making reports, or a filter excludes valid traffic. No method has been defined yet, or its effect has not been verified.

1) Make a coordinated test purchase and record its ID. 2) Verify the transaction_id sent in purchase. This may be the visible order number or another stable identifier with a documented mapping. 3) Reload the confirmation page and check that any resubmission retains the ID and is handled correctly at each destination. 4) Review a sample of historical orders. Do not reject an ID solely because of its format or use aggregate reports as the only evidence that no resubmissions occurred.

Open in your property: DebugView

You can mark this as verified if: Each order maps to a unique ID that does not change when the same purchase is resent and contains no personal data.

Investigate further if: The ID is empty, changes between submissions of the same order, is reused across different purchases or cannot be linked to an order.

1) Coordinate a test purchase and verify that it appears in DebugView. 2) Check that value is numeric and currency is the code of the currency sent, such as ARS, USD or BRL. 3) Under Google Analytics' definition, value is the sum of price × quantity for the items, excluding shipping and tax: shipping and tax are reported separately. 4) Compare the same components on the receipt. 5) When comparing reports, check the property's currency and whether the metric deducts refunds or includes other revenue. Do not compare Total revenue with sales records without reviewing its components.

Open in your property: DebugView · Property details

You can mark this as verified if: The amount, currency and order components are consistent with the event definition, and the comparison uses the same basis.

Investigate further if: value arrives as text, uses cents instead of units, has the wrong currency or includes components outside its definition.

1) Record a product's list price and discount. 2) Enable debugging and complete the test. 3) Compare price, quantity and discount with the transaction details. The price sent must reflect the discount applied to the item. 4) Review view_item and add_to_cart if available: a difference may be valid when a coupon is applied or the variant changes later. 5) If purchase does not appear, check debug mode and whether the event is sent from the server before concluding it is missing.

Open in your property: DebugView

You can mark this as verified if: price matches the unit price sold, and any variation during the journey has a documented cause.

Investigate further if: List price is sent although a different price was charged, the discount is deducted twice, or the price cannot be linked to the item purchased.

1) Coordinate tests covering your store's discounts and charges. 2) Record value, shipping, tax and the items' price and quantity. 3) Check that value equals the sum of item amounts after discounts, excluding shipping and tax. 4) Review how these components reconstruct the receipt, including any surcharge requiring separate treatment. 5) If price already reflects the discount, do not deduct it again. Cart discounts need a consistent allocation across items; document rounding differences. A consistently applied rule can still be incorrectly defined.

Open in your property: DebugView

You can mark this as verified if: The components reconcile with the transaction, discounts are applied once, and tax, shipping, charges and rounding follow documented criteria.

Investigate further if: A discount or charge is duplicated, value includes incorrect components, or the items do not explain the purchase value.

1) In a coordinated test, add and remove a product; then buy two others, including more than one unit of one product. 2) Check that items contains only the purchased products, with correct identifiers and quantities. 3) Compare a sample of units by product with the store, using the same periods, order statuses and refund criteria. A different ranking of best-selling products is a signal to investigate, not automatic proof of an error.

Open in your property: DebugView

You can mark this as verified if: The test purchase items match the order, and historical differences have an explanation or a documented investigation.

Investigate further if: A removed product appears, items are missing, quantities do not match the order, or differences in units remain unexplained.

1) Confirm whether your implementation measures product lists and how it preserves their context. If not applicable, leave the item pending and record the explanation outside the checklist. 2) Enter through a category or recommendation and follow a product's journey. 3) Review item_list_name in the events and items where the plan requires it. 4) Compare with list reports using compatible metrics. Not every purchase starts from a list, and a (not set) row needs context.

Open in your property: DebugView

You can mark this as verified if: The list is retained at the defined steps, and purchases without a list have an explanation consistent with the journey.

Investigate further if: The list changes or disappears where the plan requires it, or the report does not explain the origin of purchases that did start from a list.

1) Document which order status purchase represents in your business and when a sale is confirmed; include deferred payment methods if used. 2) Compare a sample of IDs and statuses with the events sent. Clicking pay is not enough to prove a purchase. 3) Review full and partial refunds and their refund transaction_id if this measurement is within scope. 4) To test a decline or cancellation, work with your team using the gateway's authorized test environment and methods. Do not use test cards in production. 5) A difference in totals requires reviewing dates, statuses, filters and duplication before assigning a cause.

You can mark this as verified if: Purchases match the defined status, and measured refunds can be linked to the corresponding order and amount.

Investigate further if: purchase is sent for a failed attempt, an expected refund is not recorded, or its ID or amount does not match the order.

1) Compare the linked account with the one your business uses, including links through a manager account where relevant. 2) Review auto-tagging and any tracking template or suffix. 3) Confirm these settings match the campaign plan. 4) Compare a period with actual activity and available campaign data. Seeing google / cpc alone does not prove the link works, and a missing campaign name may have several causes. If you lack permissions, ask the account administrator to verify.

Open in your property: Google Ads links

You can mark this as verified if: Linking and tagging match the intended accounts, and configuration and data support that they work.

Investigate further if: The wrong account is linked, expected tagging is disabled, or campaign information is missing without an explanation.

1) Take a campaign's final URL and test whether its redirects preserve a test parameter, such as gclid=TEST123; append it with ? or & as appropriate. This checks parameter transport, not a real advertising click. 2) With your team, review the Google tag and the conversion linking mechanism appropriate to the installation. 3) Compare campaigns with real data in Analytics. 4) If the parameter disappears, investigate where and whether the information was captured earlier; do not conclude from the final URL alone. Clicks and sessions are not equivalent metrics.

You can mark this as verified if: The journey correctly preserves or processes the intended identifiers, and comparison with real campaigns supports the implementation.

Investigate further if: A redirect removes information before it is captured, or campaign data is missing without a verified explanation.

1) Review the agreed convention for each platform and campaign type. 2) Compare a sample of published links with that convention. 3) Look for variations caused by case, abbreviations or spelling errors in reports. 4) Distinguish accidental changes from valid combinations, such as paid and organic traffic from the same network. A channel does not need to be reduced to one row. 5) In Google Ads, check that UTMs and tracking do not conflict with auto-tagging or your implementation's rules.

You can mark this as verified if: Sources, media and names identify campaigns without accidental fragmentation, and exceptions are documented.

Investigate further if: The same campaign uses variants by mistake, expected parameters are missing, or names prevent results from being compared.

1) Identify the payment domains used in your journeys. 2) Review which may generate unwanted referrals and whether they are handled correctly. Do not exclude partners or media that genuinely bring visits. 3) Compare a journey before and after returning from the gateway and review the session source. 4) Analyze data after changes, because a referral exclusion does not rewrite history. Referral exclusions do not replace cross-domain measurement across your own domains.

Open in your property: Data streams

You can mark this as verified if: Payment gateways do not receive acquisition credit simply because the visitor returns from payment, and tests support the treatment.

Investigate further if: A payment gateway appears as the source because of the checkout return, or the journey loses session information that remains unexplained.

1) List the domains you control where measurement covers the same journey. Do not add a third-party gateway where you cannot install your tag. 2) If the journey crosses different domains, review configuration and transmission of the _gl parameter where applicable. 3) Verify identifier and session continuity with your team; the address bar or absence of referrals is not sufficient evidence on its own. 4) Subdomains also need compatible cookie configuration. If this case does not apply, leave it pending and document the reason outside the checklist.

Open in your property: Data streams

You can mark this as verified if: Tests show measurement continuity across the intended domains, without unexpected self-referrals.

Investigate further if: Configuration omits a necessary domain, identifiers are lost, or unexplained self-referrals appear.

1) Record the share of (not set) in Source / medium and Landing page, and of Unassigned in the channel group. 2) Also review Direct and compare equivalent periods. 3) Relate changes to campaigns, consent, checkout and tag releases. There is no universal 5% threshold that determines whether measurement is correct. 4) To investigate, review tag configuration order, session parameters and event contents. If an event is not visible in DebugView, first verify debugging and consent conditions.

You can mark this as verified if: You know how these rows have changed, their verified causes and which differences still need investigation.

Investigate further if: A relevant variation remains unexplained, or a test shows lost source, session or page information.

1) Confirm with your team which states should apply to the visitor and test region. 2) Start a test session without previous preferences. 3) In Tag Assistant, check when the initial state is set and when tags use it. 4) Test accepting, rejecting and not interacting. 5) Review analytics_storage, ad_storage and the other configured types. The state must be available before a tag acts on it; the test is not simply a count of banner events.

You can mark this as verified if: Tags use the intended state from their first execution, and changes reflect the visitor's choices.

Investigate further if: A tag uses an incorrect state or acts before the consent it needs is available.

1) Confirm whether the implementation is basic or advanced. 2) Test the journey before and after accepting. In basic mode, Google tags may remain blocked until consent is given. In advanced mode, they may send cookieless signals under denied consent. 3) Compare behavior with the agreed mode. 4) Review each tag's additional conditions before proposing changes. Blocking a tag is not automatically an error; enabling advanced mode does not guarantee access to modeling either.

You can mark this as verified if: Tags behave according to the documented mode and respect consent states in tests.

Investigate further if: Actual configuration contradicts the agreed mode, blocking prevents an intended submission, or data or identifiers inconsistent with the consent state are sent.

1) Test accepting, rejecting and changing a previous choice. 2) Check that the updated state reflects each choice before submissions that depend on it. A Granted-to-Denied update is valid when someone withdraws consent. 3) Look for repeated updates that reset identifiers or contradict the choice. 4) Using an identifiable test campaign, compare acquisition data while accounting for filters and processing times. A filtered or non-consented test may not appear in the report; absence alone is not enough to diagnose the cause.

You can mark this as verified if: Each choice leaves the correct state, and no identity or source changes caused by inconsistent updates are detected.

Investigate further if: The state does not reflect the choice, is overwritten without an action that explains it, or a test shows information loss coinciding with an incorrect update.

1) Coordinate a test purchase with a known ID. 2) Identify whether purchase is sent from the browser, server or both. 3) Review IDs and retries in each source's logs. 4) Check the result in Analytics once data has been processed. An aggregate row does not reveal every submission that may have been deduplicated. 5) If the purchase does not appear, investigate filters, consent, debugging and processing; do not change reporting identity just to complete the checklist.

Open in your property: DebugView

You can mark this as verified if: Submissions for the same order map to a stable identifier, and the result does not include duplicate purchases.

Investigate further if: The same order uses different IDs, resubmissions lack verified handling, or an additional purchase is recorded.

1) Confirm which events should pass through the server and which property they reach. 2) Perform a test action and follow its requests from browser to destination. 3) Check whether an independent installation also sends the same action directly to the same property. 4) Identify the purpose of each request: the platform's auxiliary signals are not necessarily duplicate events. If you cannot distinguish them, ask the technical team to verify.

You can mark this as verified if: The journey matches the documented architecture, and no second implementation sends the same event by mistake.

Investigate further if: The same action is sent through two independent installations without a design that justifies it, or some traffic uses incompatible identity paths.

1) Use a test profile without existing cookies and test rejection, acceptance and withdrawal of consent. 2) Check that the state received by the server matches the browser. 3) With your team, review whether responses write Analytics cookies, including FPID if used, when analytics_storage is denied. 4) Compare the tags that run and the data sent with the agreed basic or advanced mode. Network requests under denied consent alone do not prove non-compliance: you need to review what is sent and how it is configured.

You can mark this as verified if: States are transmitted and server tags adapt their behavior; they do not write Analytics cookies when their storage is denied.

Investigate further if: The server receives an incorrect state, overwrites it, or a tag writes cookies or sends identifiers contrary to consent configuration.

1) Confirm when the change went live and which part of measurement it modified. 2) Save comparable periods of users, sessions, purchases and revenue before and after. 3) Also record campaigns, promotions, site changes and consent changes. 4) Compare with store orders and sales. 5) Explain which variations have supporting evidence and which remain unresolved. A metric changing on the activation date does not by itself prove the new measurement caused it.

You can mark this as verified if: A documented comparison includes dates, definitions, context and limits to interpretation.

Investigate further if: A variation is presented as business growth or measurement recovery without testing those explanations.

1) Confirm which actions are sent through both browser and server. If the implementation uses only one source, document that this item does not apply. 2) Coordinate a test and identify copies by event_name and event_id. 3) Viewing server submissions in the test tool may require a test code configured by the integration administrator. 4) Review available deduplication signals and submission logs. A difference between Meta and the store, or an aggregate percentage above zero, does not by itself verify deduplication of that purchase.

You can mark this as verified if: Copies of the same action share the intended identifiers, and there is evidence they are treated as a single event.

Investigate further if: Copies use different IDs, a required identifier is missing, or unexplained duplication is observed.

1) Open Purchase details and find the event match quality assessment for server events. 2) Review recommendations and missing or invalid parameters. 3) Compare with the data your business can validly send under the appropriate consent. Not every identifier is available on every visit. 4) Document the status and relevant improvements with the integration owner. The score does not validate the purchase amount, deduplication or a business result.

You can mark this as verified if: The assessment has been reviewed, with no unaddressed formatting errors in the parameters that should be sent.

Investigate further if: Data has invalid formatting or relevant recommendations remain unreviewed. If there is insufficient data to assess, leave the item pending.

1) Coordinate a test purchase with an identifiable order. 2) Review value and currency and, where relevant to the integration, contents or content_ids. 3) Compare amount, currency, products and quantities with the receipt and the account's value definition. 4) If the event is sent only from the server, request the log or a test from that source. No warnings in Diagnostics does not prove the amount is correct, and a ROAS difference across platforms does not identify the cause.

You can mark this as verified if: The data sent represents the order, and the value criteria used for comparison are documented.

Investigate further if: Required parameters are missing, the currency or unit is incorrect, other products appear, or the amount cannot be reconciled.

1) Identify the actions campaigns use for optimization. 2) Review their status, last received data and any diagnostic warnings. 3) Compare with a period when conversions were expected, allowing for processing time. 4) If there is no recent data, investigate activity and the measurement source before concluding it is broken. 5) Record unresolved alerts and who should review them.

You can mark this as verified if: Relevant actions receive the expected data, or the lack of activity has a verified explanation.

Investigate further if: An action with expected activity stops, alerts remain unresolved, or no one can explain its status.

1) Identify the conversion source. 2) If it uses a Google Ads tag in Google Tag Manager, compare its conversion ID and label with the intended action; resolve variable values when fields are not literals. 3) If it comes from Analytics, review the property, event and linked account. 4) Consider measurement through a manager account if your organization uses one. 5) Verify the submission in a coordinated test. Do not change IDs during the self-check.

Open in your property: Google Ads links · Key events

You can mark this as verified if: Configuration points to the intended action and account, and the test supports that destination.

Investigate further if: The ID, label or link corresponds to another action, account or property without a documented reason.

1) List actions representing the same sale, such as an Ads tag and an Analytics import. 2) Review which are primary and which goals each campaign uses. 3) Check that two copies of the same purchase do not feed optimization by mistake. 4) Also review custom goals: they can use secondary actions for bidding. 5) Document why a campaign uses purchases, leads or other actions. Multiple actions can be valid when they represent different outcomes; do not decide by counting primary actions across the entire account.

You can mark this as verified if: Each campaign uses the outcomes defined for its goal without counting the same sale twice through duplicate sources.

Investigate further if: Two copies of the same purchase feed optimization, or actions unrelated to the campaign's goal are included.

1) Open each relevant action and record whether it counts One or Every/All conversions, depending on the interface label. 2) For sales, check whether you need to count every purchase. For leads, assess whether to count one per interaction or each outcome. 3) Document the criteria with the campaign manager. 4) Review order identification separately: choosing One does not replace purchase deduplication and may hide distinct valid purchases.

Open in your property: Key events

You can mark this as verified if: Counting matches the business definition, and the configuration is documented.

Investigate further if: Configuration discards valid outcomes, counts repetitions with no value, or substitutes for fixing duplicates.

1) Confirm whether the implementation uses enhanced conversions and where they are managed. If not applicable, document this without marking a check you did not perform. 2) Review missing data, formatting and recent activity warnings. 3) Compare any lack of data with expected volume and consent. 4) If imports are used, review the result and a sample of rejected rows. A click-not-found warning needs investigation; it does not by itself prove the sale came from another channel.

You can mark this as verified if: The intended configuration works, and relevant alerts or upload errors have a documented explanation and treatment.

Investigate further if: Formatting errors, failed submissions or an interruption in expected data remain unexplained.

1) Review who has account access and who can read, edit, approve or publish in the container. 2) Confirm each permission matches that person's or team's current work. 3) Identify who authorizes and who publishes changes. 4) Verify the organization retains administrative access and a backup if someone becomes unavailable. 5) Document access that needs reviewing; do not remove permissions during the checklist.

You can mark this as verified if: The organization retains control, publishing owners are defined, and permissions match current roles.

Investigate further if: Publishers have no known owner, former collaborators retain access, or account administration depends on one person.

1) Review several recent versions, including the published version. 2) Check that you can identify what changed, why, who approved it and which tests were performed. 3) Check whether the record links to supporting evidence held in another tool. 4) Confirm the team knows which version to restore and how to validate a rollback. Not every detail needs to be in the version name, but it must be findable.

You can mark this as verified if: Every reviewed publication has a clear change, an owner and test evidence.

Investigate further if: It is not possible to reconstruct what was published, who authorized it or how its behavior was verified.

1) Compare active tags with the current inventory. 2) Review tags that are paused, point to old accounts or have ambiguous names. 3) Ask for their purpose and owner; a paused tag may have a valid reason. 4) Document which should be removed and which dependencies need checking first. Do not delete a tag because of its name or because it is paused.

You can mark this as verified if: Tags have a known purpose and destination; unused tags have a documented decision.

Investigate further if: Unknown destinations remain, old installation tags are active by mistake, or purposeless elements make maintenance harder.

1) Choose a completed period, allowing enough time for data processing. 2) Document dates, order statuses, currency, time zone, refunds and treatment of shipping and tax. 3) Use compatible purchase and revenue metrics; Event count, Transactions and Total revenue are not interchangeable. 4) Compare totals and a sample of IDs when available. 5) If calculating (Analytics − store) / store × 100, do it separately for each metric and only with a nonzero denominator. 6) Record the weekly review and open discrepancies. Stability does not mean correctness, and a higher total does not by itself prove duplication.

You can mark this as verified if: The comparison has a common basis, a periodic review and supported explanations or identified open investigations.

Investigate further if: Incompatible metrics are compared, criteria change without a record, or relevant differences go unreviewed.

1) Identify the check monitoring purchases, revenue or other relevant events. 2) Review its condition, frequency, segment and recipients. Analytics custom insights can send email notifications. 3) Compare the threshold with business volume and seasonality. 4) Review a previous alert or a controlled test of the monitoring system, without generating fake purchases in production. 5) Document who investigates and the response timeframe. An alert indicates a variation; its cause may lie in measurement or in the business.

You can mark this as verified if: The check has a useful condition, current recipients and evidence of operation or a controlled test.

Investigate further if: No check exists, notifications do not reach the owner, or conditions generate alerts the team cannot interpret.

1) Review the need each dimension addresses and how many distinct values it may generate. 2) Identify unique IDs or timestamps registered without a justified need; they may increase cardinality. 3) Check whether (other) appears and how much detail it groups in the report. That row may have multiple causes and does not prove a specific dimension is responsible. 4) To analyze individual orders, assess standard dimensions and, where necessary, exported data with your team.

Open in your property: Custom definitions

You can mark this as verified if: Dimensions have a documented purpose, and the available detail is sufficient for the intended analysis.

Investigate further if: Unique values consume capacity without a clear need, or aggregation prevents the report's question from being answered.

1) Open the reports you use regularly. 2) Read the data quality indicator and record whether it reports thresholds, sampling, modeling or another limitation. 3) Assess how it affects the question you want to answer. 4) Where appropriate, compare a broader date range or remove an unnecessary dimension. 5) Do not change reporting identity as an automatic fix: it can change user metrics and requires a documented decision. Using all available data does not prove all actual actions were observed.

Open in your property: Reporting identity

You can mark this as verified if: Reports support the intended analysis, and their limitations are identified and considered in conclusions.

Investigate further if: Decisions rely on hidden or incomplete detail without reviewing the data quality notice.

1) List the custom parameters you need in reports. 2) Review whether they need a custom dimension or metric, or whether a standard field already covers them. Do not register every parameter sent by default. 3) Verify name and scope: event, user or item, as applicable. 4) Confirm receipt and analyze data from after registration, allowing processing time. Registration does not reconstruct historical data. 5) If no information appears, review exploration compatibility, filters and available data before assigning a cause.

Open in your property: DebugView · Custom definitions

You can mark this as verified if: Fields needed for analysis are registered where appropriate, with correct names, types and scopes, and show compatible data.

Investigate further if: A required parameter arrives but cannot be used because its definition is missing or incorrect, or redundant fields are registered without a purpose.