Two purchase actions appear in Google Ads after an app team connects a measurement partner. The campaign report looks stronger, but the payment system has not recorded a corresponding increase. Before changing bids, deleting an import or blaming an SDK, establish what each number represents. A second observation is not necessarily a second purchase, and a discrepancy is not sufficient evidence of duplicate collection.
To diagnose duplicate app conversions in Google Ads, map each business milestone to its event senders, conversion-action IDs and campaign goal membership. Separate repeated collection from overlapping observations and report aggregation. Then verify which actions actually contribute to the disputed report and optimization configuration. Neither a “secondary” label nor a transaction ID proves that every possible overlap has been resolved.
This guide is for app founders, growth leads and UA operators deciding what to repair before the next budget decision. Its diagnostic register and acceptance workflow are original editorial recommendations. Platform behavior comes from the linked Google documentation. The examples focus on Android app measurement; they are not instructions for changing a private account without its owner's authorization.
Four situations that can look like duplicate app conversions
Start by naming the suspected failure. These cases require different evidence and different corrections.
Situation What must be established Appropriate next investigation --- --- --- Distinct observations The two numbers measure different milestones or populations Clarify definitions and label the report Repeated collection One business event is emitted or forwarded repeatedly within a path Trace the producing implementation and supported duplicate handling Overlapping conversion actions Separate actions represent some of the same underlying business activity Inspect action identity, sender coverage and campaign use Aggregation error A report adds overlapping observations and calls the sum unique outcomes Correct the calculation and decision label
Google documents app-conversion sources including Firebase/Google Analytics, Google Play and third-party app analytics. Their names are not interchangeable evidence definitions. Its Google Play measurement guide describes Play measurement of downloads and in-app purchases, while other app paths can observe first opens or different in-app events.
An install download and an SDK first open can therefore be valid observations of different points in a journey. Their difference alone does not establish a broken duplicate filter. For that particular boundary, use the separate Google Play installs versus first opens guide.
The useful diagnosis is specific: “the dashboard adds two actions that may observe the same successful purchase,” or “the purchase callback sends twice after one receipt.” Those statements identify a testable boundary. “Google is double counting everything” does not.
Build an action inventory before removing anything
Export the current conversion-action configuration and capture the campaign settings before edits. Keep a dated, access-controlled record; redact customer identifiers, credentials and commercially sensitive detail before sharing it outside the authorized team.
For every disputed milestone, create one row per conversion action. Record the account and action ID, app identifier, source, upstream event definition, responsible sender, value/currency meaning, counting rule, relevant windows and current optimization setting. Add the campaign or reporting calculation that consumes it. Similar display names are a reason to investigate, not a reliable join key.
Use three separate ownership fields. The product or analytics owner defines the business event. The engineer or measurement provider owns its collection and forwarding path. The media operator owns how the campaign uses the resulting action. One agency may fill several roles, but the evidence should still distinguish them.
Define the event in business language before comparing counts. Does “purchase” mean a successful payment, a purchase-screen tap, an initial subscription payment, a renewal or all of those? Does value mean a recorded sale or a projected amount? An action can have a technically functioning feed and still answer the wrong commercial question.
A useful row ends with an explicit decision: retain as an independent milestone, retain for comparison, investigate its event generation, or review its optimization role. Do not begin with “delete the smaller source.” The smaller observation may have narrower coverage rather than poorer implementation, and removing it may destroy a useful diagnostic view.
If the real decision is whether to add or replace a measurement provider, the Firebase versus MMP framework addresses that procurement question. Duplicate diagnosis should not become an automatic software purchase.
Check campaign use as well as primary and secondary labels
An action's optimization label is only part of the evidence. Google says primary actions contribute to bidding when their standard goal is used by the campaign. Secondary actions normally appear in All conversions for observation. Actions included in a custom goal can be used for bidding regardless of their primary or secondary setting. Google also notes that primary actions not used for optimization may help predictions. Primary and secondary conversion actions.
Consequently, “make it secondary” is an incomplete remediation instruction. Review the actual campaign configuration, including any applicable custom goal, and verify the resulting report. A general help page does not establish that every campaign type or account exposes identical goal controls; inspect the controls available in the account being investigated.
Separate two questions in the audit. First, does the disputed action contribute to the report total the team is using? Second, is it part of the campaign's selected optimization configuration? An inflated dashboard calculation can exist without a demonstrated bidding-configuration problem. Conversely, a tidy dashboard does not prove that the campaign consumes the intended signal.
Write the intended configuration in plain language: “This campaign should optimize toward the validated successful-payment milestone from the agreed source; the alternative observation remains available for comparison where supported.” Then list the IDs and settings that implement that intent. Do not assume the written intention matches the account.
Choosing installs, an in-app action or value is a separate strategic decision. The Google App campaign goals guide covers that choice; changing the economic goal simply to make a duplicate warning disappear can create another problem.
A newly visible action does not prove an unauthorized bidding change
Google documents automatic creation and enablement of app conversion actions when supported App Attribution Partners send data through the App Conversion API. It also describes a one-time enablement of hidden firstopen and inapppurchase actions. Those automatically enabled actions default to secondary. The documented automation does not apply to Firebase conversions. Automatically enabled app conversion actions.
If an unfamiliar action appears, record its source, creation or observed appearance time, goal placement and current setting. Ask whether a provider connection or event feed changed. Its presence can be an expected measurement change rather than evidence that someone intentionally added a bidding target.
Still inspect the current campaign use rather than relying on the default. A default describes initial behavior, not every later account change. Equally, do not disable every newly visible action as a housekeeping exercise. Decide whether it is a useful observation, an unintended event definition or a configuration requiring correction.
Google's third-party import documentation says newly imported actions begin reporting from import time. Treat any proposed replacement as a reporting boundary to document. Do not promise that creating a cleaner action will reconstruct the old action's history or make a before-and-after series directly comparable.
Compare equivalent observations before estimating overlap
Choose a comparison question first. For example: “Do these two actions observe the same successful-payment milestone in this app over the same reporting period?” A complete answer needs more than similar totals.
Document scope differences individually: event definition, app, population eligibility, reporting date basis, time zone, processing maturity and attribution treatment. Keep unmatched differences visible. Do not silently change production windows to force a reconciliation; the window may be part of the campaign's approved economic decision.
Google's app-conversion comparison guidance recommends checking settings such as platform, app, value, counting and conversion windows before comparing actions. It distinguishes All conversions from the corresponding conversion-time view. It also identifies reinstall and purchase-definition differences that can explain disagreement. That guide compares actions inside Google Ads; it is not a complete reconciliation specification for an MMP dashboard versus Ads.
Use Google's separate App campaign conversion-window documentation to interpret click, view, engaged-view and post-install boundaries where relevant. The existence of several windows does not mean every action or campaign uses them in the same way. Record the actual settings and the business reason for them.
Counts are the first reconciliation task. Values need a second review of currency, units, included transaction types and adjustments. Two event streams can agree on activity while disagreeing on money, or disagree on activity for legitimate coverage reasons. Keep that financial review separate from the question of repeated event collection.
Why transaction IDs and Count One are not universal repairs
Two popular shortcuts deserve particular care when the problem involves app imports.
A transaction ID has a documented scope. Google's transaction-ID guidance explains duplicate handling for repeated conversions with the same ID within the same conversion action in its tag/online and offline measurement context. It does not establish universal deduplication between independent Firebase and MMP app actions. Nor does it justify pasting web-tag code into an app integration.
For the exact SDK, API or partner path, ask which identifier is accepted, what event it identifies, where duplicate handling occurs, and how scope is defined. Obtain the integration's current documentation or a provider-supported answer. Never put personal information into an identifier or use one static value for unrelated transactions. A mechanism intended to suppress repeats can also suppress legitimate activity when identity is wrong.
Count One changes counting semantics; it does not establish cross-source identity. Google's counting-options guide describes counting per conversion action. It also says count changes affect future reporting and that app-install count settings cannot be edited. “Every” can be appropriate for genuinely repeated purchases; replacing it merely to lower a suspicious total can hide real business activity.
A high repeat-rate diagnostic is not by itself proof of duplicate collection either. The same Google guide describes traffic contexts in which repeat rate can be elevated without overcounting the Conversions or All conversions columns. Validate the event path rather than treating a single diagnostic ratio as a verdict.
The corrective question is therefore narrower: “Which documented mechanism prevents a repeated observation of this exact business event in this exact path?” If the answer is unknown, preserve that uncertainty and escalate to the responsible implementer. A cleaner-looking total is not acceptance evidence.
A fictional overlap calculation shows what the total cannot tell you
Suppose an Android team spends $12,000 during a defined reporting period. Action A reports 100 successful-payment observations and Action B reports 80. Its internal dashboard adds them and displays 180 purchases at $66.67 each.
That calculation is arithmetically correct for summed observations: $12,000 ÷ 180. It is not yet a cost per unique successful payment. The team has not established the overlap.
Under a deliberately simplified assumption that each action contains one record per genuine payment, both cover the same eligible universe, and their only uncertainty is overlap, the union could range from 100 to 180 payments. Full overlap of B within A produces 100; no overlap produces 180. The corresponding arithmetic spans $120 to $66.67 per payment.
Real attributed reports may not satisfy those assumptions. They may contain aggregate or modeled observations, unequal coverage, incompatible time bases or repeats within an action. If so, even those illustrative bounds are not defensible estimates of unique outcomes. They are a demonstration of missing information, not a substitute for reconciliation.
The exercise yields an operational decision: the dashboard cannot authorize a scale-up using “180 customers” until the event and identity assumptions are supported. It does not establish fraud, wasted spend or how campaigns actually optimized. An account can need reporting repair before anyone can justify a tracking or bid change.
Apply the same discipline to revenue. Two overlapping value streams cannot simply be added and labeled business return. The mobile app ROAS guide explains the additional revenue and cohort reconciliation needed before return claims support budget decisions.
Correct the narrowest broken boundary, then verify it
Choose a correction based on the evidence rather than applying several simultaneous fixes. Preserve the starting exports and a dated decision record. Define which operator can authorize each change and which other campaigns or reports depend on it.
Proven problem Responsible workstream Evidence needed for acceptance --- --- --- Dashboard sums overlapping actions as unique outcomes Analytics/report owner Revised calculation, explicit population label and reconciled sample or stated limits Business event is emitted repeatedly App engineering and measurement provider Authorized test trace showing the intended event and supported duplicate behavior Campaign uses an unintended action or goal Media operator Before/after action IDs, campaign settings and the intended report contribution Two sources measure different milestones Product and analytics Approved definitions and separate reporting labels Overlap remains unobservable Decision owner Explicit limitation and a budget decision that does not require unsupported uniqueness
For an event-path repair, rehearse the relevant lifecycle cases in an authorized test environment: a successful event, a failed attempt, a retry, and a genuine second transaction when the product permits one. Define the expected observation for each. Do not fire artificial production purchases to improve a report or treat test traffic as acquisition performance.
For a campaign-setting correction, preserve a clear transition date and avoid bundling it with unrelated creative, geographic and budget changes. Google warns that bidding models need time to adapt to conversion-configuration changes; its campaign-specific goal guidance discusses that dependency. There is no editorially defensible universal recovery period or promised performance response for an unknown account.
Agree on acceptance before observing the result. Name the action, event definition, owner, evidence location, expected report behavior and remaining limitation. If a source transition is involved, use the broader MMP migration checklist to preserve responsibilities and reporting boundaries beyond this one duplicate concern.
Bring the disputed decision to a measurement conversation
Sharply Labs' mobile app growth work includes event-quality review, reporting reconciliation and measurement ownership alongside paid acquisition. Its broader growth services provide the commercial context for connecting measurement work to campaign decisions. The useful starting point is the decision currently blocked, not a demand to make every platform total match.
For an established app team with suspected overlapping Google Ads conversions, bring a redacted action inventory, the relevant campaign goal settings, a sender diagram and the budget or agency-scope decision those numbers are meant to support. Include the definitions and time basis behind the disputed report. Do not send customer-level records or credentials through a general enquiry.
Discuss the conversion evidence with Sharply Labs. The initial conversation can identify the first unresolved evidence gap, its responsible owner and a bounded validation agenda. Account access, engineering changes and deeper implementation require an agreed scope. The conversation does not promise complete attribution, historical correction, lower acquisition costs or improved campaign performance.