A purchase appears in your app analytics, but Google Ads shows no corresponding conversion. The team proposes raising the budget, replacing the SDK or recreating the conversion action. None of those changes establishes where the observation disappeared. First separate a missing business event from a missing import, an attribution difference and a report that excludes a working action.
When Google Ads app conversion tracking is not working, trace one defined outcome through collection, the connected data source, the Google Ads conversion action and the campaign report. Capture the exact app, account, action and time boundaries at each handoff. Repair the first unsupported handoff before changing optimization. A successful development test does not establish that paid production traffic is attributed or used for bidding.
This guide is for Android app founders, UA leads and growth teams deciding whether to fund measurement repair, escalate a provider issue or resume acquisition decisions. The diagnostic register and acceptance criteria below are editorial recommendations, not a claim about a private account. Platform statements cite current Google documentation. This is not an implementation guide for Apple measurement or a substitute for account-specific investigation.
Start with the symptom, not the proposed fix
“Tracking is broken” can describe several different failures. Ask the person raising the issue to complete this sentence: “We expected this named action, from this app and population, in this report, for this period, and observed this instead.” If they cannot, the next task is to define the comparison.
Observed symptom First question Evidence to preserve --- --- --- No event in the source Did the defined business outcome occur and get collected? Release, event definition and development trace Event exists but cannot be selected Is the correct source connected and eligible for import? Property, account, permissions and configuration Action exists but report is empty Does this report include that action and eligible activity? Action ID, columns, filters and date boundaries Counts changed after a release Which collection or configuration boundary changed? Last comparable period and change history Counts disagree across tools Are the milestones and attributed populations comparable? Definitions, windows and source coverage
Keep this initial classification narrow. A blank purchase row does not establish zero purchases, a provider outage or a bidding defect. It establishes a reporting observation that needs an explanation.
Google offers app measurement paths through Google Analytics, Google Play and third-party app analytics. Its app conversion setup documentation identifies these as distinct data sources. Begin with the path actually configured. Advice about a website tag or landing-page conversion label may not apply to a native app import.
Build a handoff register before touching the account
Create one row for the outcome that matters to the blocked decision. Record the Android package, production release, analytics property or provider app ID, Google Ads customer ID, conversion-action ID and campaign. Display names are useful labels, but they are poor evidence that two people are inspecting the same object.
Write the business definition beside the technical event name. For a subscription app, does purchase mean successful initial payment, trial start, renewal or a tap on the payment button? A payment-screen interaction can be collected perfectly while failing to answer the commercial question. Establish the intended milestone before asking whether its count is correct.
Add the source owner, forwarding owner and media owner. Name who can inspect each boundary and who has authorization to change it. The media team should not promise an engineering correction it cannot implement; an engineer should not silently change a campaign's economic objective while repairing instrumentation.
Preserve the baseline configuration, relevant exports and recent changes in an access-controlled location. Redact customer identifiers and secrets before sharing externally. The evidence packet needs enough identity to trace configuration, not unrestricted access to customer records. Avoid sending raw payloads into a group chat merely because a provider requested “logs.”
The useful output is a specific unknown: “production release collects activation, but the linked property has not been confirmed,” for example. That statement assigns the next check and prevents parallel changes from destroying the baseline.
Check collection at the source
For a Firebase path, use a controlled development reproduction to establish whether the intended event and parameters are emitted. Google's DebugView documentation describes near-real-time inspection of development-device events, including parameters and logging errors. Check the event meaning and payload, not only whether a similarly named entry appears.
Record which build and app instance produced the trace. A staging application connected to a staging property cannot prove collection in the production app. If the code path differs by release, account state or consent choice, document the condition under which the observation was made. Do not weaken privacy settings to make a test look successful.
Keep the test controlled and isolated from production business reporting according to the property's supported configuration. The current DebugView documentation explicitly discusses developer traffic filters and warns that debug events can enter daily BigQuery exports by default. Do not assume that enabling debug mode automatically removes every test event from downstream datasets.
A passing trace closes one question: that implementation, in that context, emitted the event. It does not prove that the event is eligible for an Ads import, that it has an attributable advertising interaction or that the campaign uses it. Move to the next handoff with that limit recorded.
If collection fails, stop investigating campaign columns as the primary repair. Ask the implementation owner for the smallest reproducible collection failure. If collection succeeds, avoid reinstalling an SDK simply because the Ads row remains blank. That creates another variable without testing the next boundary.
Confirm the connection and import
For a Google Analytics path, verify the actual linked property, permissions and key-event status. Google's current app setup checklist requires the appropriate Ads and Analytics access, an active link to the correct property and events marked as key events for import. It notes that linking or key-event changes can take 24–48 hours to propagate. This is a documented configuration delay, not a universal deadline for every missing app conversion.
For a third-party path, confirm the provider link and the upstream events. Google's third-party app analytics instructions state that newly imported actions begin reporting from the time the event is imported. Do not promise that repairing or recreating an import will reconstruct historical reporting.
Those instructions also describe automatically created or enabled actions for supported App Attribution Partner data, with secondary defaults. Therefore, check whether an action already exists before creating another one. A missing item in a preferred view is not sufficient evidence that no matching action exists anywhere in the account.
For a Google Play path, confirm that the expected milestone fits the source. Google identifies Play measurement as downloads and in-app purchases in its Play conversion guide. Do not expect a custom activation milestone to appear merely because Play download tracking exists. Choosing a valid source is separate from proving its configuration.
Capture the exact observed state and timestamp. “Linked yesterday” is less useful than a dated record naming the source and Ads customer. If permissions prevent inspection, assign that gate to an authorized owner rather than claiming the link passed.
Separate action availability from campaign use
An action can exist and receive data while being absent from the headline column a buyer is watching. Google's primary and secondary conversion documentation distinguishes primary actions used with the relevant goal from secondary observations reported in All conversions. It also explains the custom-goal exception: included secondary actions can be used for bidding.
Inspect the actual campaign's applicable goal and report configuration before treating this distinction as the diagnosis. General documentation does not establish that every campaign type exposes every control. Record what is visible in the account and use the provider's supported path for that campaign.
Do not switch everything to primary merely to populate a column. That can turn a reporting investigation into an optimization change. Decide which outcome should authorize spend, then make any goal change as a separate, approved intervention with a preserved baseline.
If two actions now represent overlapping observations of the same purchase, use the dedicated duplicate app conversions diagnostic. That page owns overlap and aggregation. This workflow owns a missing or unproven handoff; the repair should not create a second ambiguity.
Reconcile the clocks and populations
A total event count in app analytics is not automatically a count of Google Ads attributed conversions. Before calculating a discrepancy, align app identity, event meaning, population, observation period, report date basis and available attribution settings. Treat unmatched definitions as unresolved comparison limits.
Google documents separate click-through, engaged-view, view-through and post-install boundaries for App campaigns in its conversion window guide. A downstream event outside an applicable boundary may not answer the same reporting question as an all-source event count. The exact current action and campaign settings still need inspection.
For window selection and lag analysis, use the complementary App campaigns conversion window guide. Do not enlarge a window merely to force totals to converge. That changes which observations qualify and can obscure the original issue.
Likewise, a Play download and a first open are different milestones. The Play installs versus first opens framework helps define that comparison. Equal counts are not a universal acceptance criterion. A defensible explanation of the difference can be more useful than a cosmetic match.
Use acceptance tests that match the next decision
Approve a repair in stages. The following gates are an editorial operating model; they are not Google certification criteria.
Collection acceptance: the intended build produces the defined event with the required meaning under the tested conditions. Record the context, parameters inspected and remaining conditions not tested. The implementation owner signs off on collection only.
Connection acceptance: the authorized owner confirms the correct source, account and event mapping. Record action identity, import or configuration time and known propagation constraints. An assumption that the right property is linked does not pass.
Reporting acceptance: the media and analytics owners inspect the appropriate report, columns, date boundaries and eligible production observations. Explain remaining differences rather than setting an arbitrary tolerance that conceals them. A development trace alone cannot pass this gate.
Decision acceptance: the commercial owner decides whether the evidence supports the proposed budget action. Tracking may be technically repaired while cohort maturity, outcome quality or unit economics still prevent a scale decision. State that separately.
These stages make an agency proposal easier to evaluate. Ask what each deliverable proves, who can verify it and what remains outside scope. A screenshot of a green status is weak acceptance if nobody can explain the business outcome or the campaign using it.
A fictional example: why an empty column can mislead
Consider an Android subscription team with 60 successful payments recorded by its payment system during a chosen period. Its analytics tool reports 54 purchase events. Google Ads shows eight observations for one secondary action in All conversions and none for that action in the headline Conversions column. These figures are invented to illustrate diagnosis, not a benchmark or Sharply Labs client result.
There are at least two investigations. The difference between 60 payment records and 54 analytics events concerns collection definitions, coverage and timing. The placement of eight Ads observations concerns action configuration, report selection and attribution eligibility. Neither difference is solved simply by dividing spend by 60 and calling the answer Google Ads CPA.
Suppose the team spent $800. Dividing by eight yields $100 per observed Ads action; dividing by 60 yields $13.33 per all-source payment. The arithmetic is correct, but the denominators answer different questions. Neither number establishes incremental acquisition cost, and neither proves that all payments came from the campaign.
A reasonable next step is to preserve the source definitions, investigate the six-record collection gap and confirm the secondary action's campaign use. Changing the action to primary before that work could change optimization without making the evidence comparable. The example's purpose is to identify separate decisions, not recommend those counts or settings.
Repair, escalate or defer expansion
Repair collection when a reproducible implementation defect is established. Repair configuration when the source identity, import or supported campaign use is demonstrably wrong. Correct reporting when the underlying observations work but the dashboard mislabels them. Keep these actions separate enough to observe their effects.
Escalate when the next boundary is controlled by Google or the measurement provider and the authorized team cannot resolve it. Send a concise packet: app and action identity, affected dates, expected behavior, actual observation, recent changes, redacted supporting evidence and the precise unanswered question. Ask what evidence would establish acceptance. Do not label ordinary uncertainty a platform outage without the provider reporting one.
Defer expansion when the proposed spending decision depends on an outcome that remains unverified. This does not prescribe stopping every campaign. The appropriate operating constraint depends on the account, risk and evidence available to its owner. A repaired event feed alone does not promise restored historical data, stable bidding or improved acquisition economics.
Bring a defined measurement question to the conversation
Sharply Labs' mobile app growth services connect acquisition, creative, ASO, attribution and retention decisions. Its growth services provide the broader commercial context for evaluating acquisition work. The useful starting point is the decision the missing evidence currently prevents.
For an established Android app team evaluating measurement or paid-acquisition support, request a conversion-evidence conversation. Bring a redacted handoff register, the affected action and the budget decision at stake. The initial conversation can identify missing evidence, responsible owners and a sensible validation scope. It does not promise a completed technical audit, platform intervention, historical recovery or campaign results; implementation and any account changes need their own agreed scope.