Prepare an App campaign by identifying the app, the action you want users to take and the measurement source that can record that action. An install, a first open and an in-app purchase are different outcomes. Use an app-readiness record to connect the creative promise to a testable conversion signal before advertising.
For a business app, the most useful opening question is practical: what should someone do after discovering it? A download may be the immediate objective, while a completed booking may be the business outcome. Write both down without pretending that a store download proves the later action occurred. The campaign brief and the measurement brief must describe the same journey.
Which App campaign task are you preparing?
App campaign options include installs, engagement and pre-registration. The campaign overview distinguishes these tasks. Select the intended route before preparing assets. Reaching people who already use an app is a different brief from introducing an available app or promoting an upcoming release.
The published-app route requires an app available on Google Play or the Apple App Store. That documented starting point applies to the available-for-download route discussed here. Pre-registration has its own setup, so do not interpret the existence of that subtype as permission to advertise any unfinished app through an install campaign.
App campaigns can promote apps across multiple Google properties. Google tests combinations of supplied creative and store-listing assets. These delivery and asset functions make the store listing part of the creative review. Check the name, screenshots and description against what the release actually provides. A polished advertisement cannot correct a misleading listing or an unavailable destination.
Which signal represents the action you actually want?
Google Play measurement covers downloads and in-app purchases only. Measuring first opens or in-app actions requires code access or a third-party analytics tool. Use the Google Play conversion guide to distinguish those routes. A campaign report should not describe every imported action as a download, nor assume that every desired event is available directly from Play.
Automatic Google Play in-app purchase measurement requires a linked developer account. Only Analytics events marked as key events are eligible for import. Those measurement prerequisites belong in the readiness record beside the account and data source. Ask the owner to show the actual link and event selection; a similar-looking property name is insufficient evidence.
Primary conversion actions are biddable, while secondary actions are observation-only. The conversion configuration instructions make that distinction consequential. Decide which action should guide bidding and which should provide additional context. An event can be interesting for analysis without representing the business outcome the campaign is intended to pursue.
Original app-action signal contract
The following hypothetical example concerns a booking app. It is a proposed specification and test exercise, with no claim about an existing app or campaign result. A product owner wants new users to make a valid booking enquiry. The table makes each stage explicit rather than collapsing the journey into a single installation figure.
| Journey stage | Working definition | Candidate evidence to inspect | Decision before activation |
|---|---|---|---|
| Store download | App downloaded through the relevant store route | Selected store conversion source | Name this as a download, not a completed enquiry |
| First open | App opened after installation | Chosen analytics event and test trace | Establish the measurement route separately |
| Enquiry started | User begins the booking request | Event definition and trigger location | Decide whether it is diagnostic or a bidding goal |
| Enquiry completed | Valid request reaches the agreed completion state | Test request and corresponding event | Exclude mere button taps from the definition |
| Repeat app use | Existing user returns for another task | Defined event in the chosen system | Separate acquisition from engagement analysis |
Complete a short contract for the final row you choose as the main objective. Include event name, business meaning, triggering screen, data source, account owner, primary or secondary role and the evidence retained from a test. Keep implementation identifiers in the private specification rather than in public promotional copy.
For the fictional completed-enquiry event, write down what must be true before it fires. A visible confirmation screen may be part of the design, but the product team must decide whether it corresponds to a valid stored request. Then test a cancelled journey as well as a completed one. The two should not be casually labelled as equivalent conversions.
Record duplicate-event questions explicitly. If both the app and another connected system report a similar event, ask the implementer to show how the selected conversion definition handles the relationship. Do not add every available event to the bidding goal simply because it appears in an import list. Keep the goal understandable to the person assessing campaign results.
Before selecting the goal, ask the product owner to complete two short statements: “This event tells us that…” and “This event does not establish…”. For the fictional enquiry, a valid completion may establish that a request was stored, while leaving its commercial suitability for a later review. Keep that distinction in the report specification. Then ask the implementer to show where the event definition makes that boundary real. If the event actually fires when a user merely opens the enquiry screen, rename it as a diagnostic action or change the implementation before using the stronger completion description.
How do creative readiness and measurement readiness connect?
Create an asset-to-action note for every major promise. If a video demonstrates an enquiry flow, verify that the current release offers that flow and that the campaign destination is the intended app. If an image features a specific function, ask the product owner to confirm its availability in the advertised release. Record unresolved differences before approval.
Review the store journey on the relevant device using approved test data. Inspect the listing, destination and first-use experience together. Note any account requirement or access step that affects the advertised task, while avoiding unsupported assumptions about country eligibility or campaign availability. The campaign overview is a product explanation, not a country-specific approval decision.
For purchase-led apps, keep the revenue interpretation precise. Google Play subscription conversion measurement records only the first purchase and first payment value. That documented limit means the selected measurement route should not be described as a complete subscription-revenue ledger. Write the reporting definition in language the business owner can understand.
What evidence belongs in the handover?
Retain the selected app identity, campaign task, asset list, event contract and measurement-source record. Add a test narrative explaining the action taken and the observation made. A screenshot of an event name proves less than a trace connecting an agreed test journey to the corresponding recorded action. Keep customer data and account credentials out of the handover copy.
Give unresolved items an owner and a specific question. “Tracking needs work” is too vague; “confirm whether the completed-enquiry event fires only after a valid request is stored” is actionable. Use that record to decide whether the campaign brief is ready for account-level checks and approval. A complete draft brief does not itself authorise spending or publishing advertisements.
For wider planning, see Google Ads, app and web development and business systems. To discuss your app’s customer journey, get started with the store destination, intended action and signal contract. Those materials make a scope discussion concrete without turning an untested event into a performance promise.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.