Signing an agency agreement does not make an app-growth program ready to operate. The team is ready only when the business can prove who owns each account, which access is necessary, what data may authorize a decision, who can change spend or measurement, and how work will return to the company if the relationship ends.
This is the gap between procurement and performance. A polished kickoff can still leave the agency unable to publish, the client unable to audit changes, finance unable to reconcile results, and product teams surprised by event or store-page requests. The remedy is an onboarding acceptance contract: a small set of evidence-backed gates that both sides must pass before material spend moves.
The short answer: how should you onboard a mobile app marketing agency?
Onboard a mobile app marketing agency by keeping business ownership of core accounts, granting the least access needed for the agreed work, freezing a measurement baseline, assigning decision rights, and testing the full operating loop before changing meaningful budget. Treat access, data, creative, store assets, product events, reporting, change control, and exit handover as acceptance criteria rather than kickoff tasks.
A useful onboarding is complete when both sides can answer five questions with evidence:
Can the agency do the contracted work without owning the company's durable assets?
Can the client see, audit, and revoke every material permission?
Do the parties use the same definitions for installs, activation, value, cost, and reporting periods?
Is one named person accountable for every recurring decision and exception?
Could the company continue operating if the relationship ended tomorrow?
If the answer to any of these is unclear, delay the affected change. Do not compensate for missing controls by granting broad administrator access or moving accounts into an agency-owned structure.
Teams still comparing vendors should first use the mobile app marketing agency selection framework. Teams deciding whether to outsource at all should resolve the agency-versus-in-house operating model before onboarding begins.
Replace the kickoff checklist with an onboarding acceptance contract
A checklist records activity. An acceptance contract records the condition that must be true before a dependency is considered ready. That distinction matters because "invite sent" is not the same as "correct role accepted and tested," and "dashboard shared" is not the same as "finance can reproduce the denominator."
Build one register with these fields:
Field What it must establish Example evidence Failure response --- --- --- --- Asset or decision The account, data object, workflow, or recurring choice in scope Ad account ID, analytics property, store app, creative queue, budget decision Stop and name the missing object Business owner The employee accountable for durable control Named owner and backup Assign ownership before access Agency role The work the agency is authorized to perform Campaign operator, analyst, creative reviewer Remove permissions outside scope Acceptance evidence Proof that the workflow works end to end Test login, export, approval, change log, reconciled sample Repair and retest Decision deadline When an owner must approve, reject, or escalate Agreed operating calendar Use the defined escalation path Exit condition What must be returned, exported, or revoked Asset register, history export, access removal record Hold final acceptance until complete
The register becomes the common control plane for growth, product, analytics, finance, legal, creative, and the agency. It should link to the signed scope, but it should remain operational: a person joining the program should be able to use it without interpreting proposal language.
Gate 1: keep durable assets under business control
The app company should normally remain the owner of its ad accounts, store accounts, analytics properties, attribution configuration, pixels or tags, audiences, creative source files, domains, billing relationships, and historical exports. The agency receives access appropriate to the contracted job.
This is consistent with current platform account structures. Google Ads documents that a client account retains its data and can unlink from a manager account; ownership by a manager is a separate status that should be granted only when it is actually needed (Google Ads account ownership). Apple Ads separates account administrator, campaign-group manager, read-only, finance, and API roles (Apple Ads user invitations). TikTok Business Center lets an advertiser approve partner access and choose Admin, Operator, or Analyst permissions for an ad account (TikTok ad-account access).
Business ownership does not mean every employee needs administrator rights. It means the company can identify the durable owner, recover the asset, audit partner access, and continue operating without relying on an external party's login.
Create an asset register before sending invitations:
System Durable business owner Agency's minimum working role Proof to retain --- --- --- --- Ad platform Growth or marketing lead, with approved backup Role required to build, analyze, or publish within scope Account ID, owner, partner ID, role, acceptance date App Store Connect Account Holder and internal app administrator App-specific role only if store work is in scope App access, role, expiration/review date Google Play Console Account owner or internal administrator App-level permissions where practical User, permission set, expiration/review date Analytics Internal analytics or product owner Analyst or editor according to the work Property ID, role, data restrictions Tags and measurement Internal technical owner Publish or edit only when implementation work is contracted Container/property ID, environments, approval route Creative source Internal brand or creative owner Workspace access to assigned projects Rights, editable files, naming and archive rules Billing Internal finance owner Read-only or finance role only when necessary Payer, invoice access, tax and approval route
Apple states that the App Store Connect Account Holder is the person who initially enrolled and is the only user who can transfer that role; other access is assigned through roles (App Store Connect roles). Google Play likewise distinguishes owner, administrator, and user access, and supports account-level or app-level permissions plus access expiry (Google Play users and permissions). These controls are reasons to design access deliberately, not reasons to copy the same broad role across every system.
Gate 2: grant the least necessary access and test it
Permission design should begin with tasks, not titles. "Agency" is not a permission level. A media buyer may need to build and publish campaigns but not change billing. An analyst may need reports without user administration. A creative partner may need asset access without audience exports.
For each task, document:
The action the person must perform.
The platform object on which the action occurs.
The lowest role that permits the action.
Any sensitive cost, revenue, audience, or user data exposed by that role.
The person who approves the grant.
The date the permission will be reviewed or removed.
Google Analytics currently separates Administrator, Editor, Marketer, Analyst, and Viewer capabilities and can restrict access to cost or revenue metrics (GA4 access management). App Store Connect also supports limiting a user's access to specific apps when the role allows it (App Store Connect app access). Use those distinctions where they match the work.
Then test access from the invited user's account. The acceptance evidence is not a screenshot of the invitation. It is a successful, bounded action: the operator can view the intended campaign group, produce the agreed report, upload an asset into the correct review state, or open the correct app without seeing unrelated properties. Record the result and any exception.
Never ask a partner to share a personal password, impersonate an employee, or work through a generic credential. If a platform does not offer the exact granularity you want, document the extra exposure and decide whether the work justifies it.
Gate 3: freeze the pre-change evidence baseline
An agency needs a baseline, but "last month" is not a baseline definition. Before strategy, bids, campaign structure, conversion configuration, store assets, or creative rotation changes, freeze a reproducible evidence window.
The baseline should record:
Exact start and end times, time zone, currency, and tax treatment.
Account, campaign, market, platform, and app-version scope.
Install or first-open definition and the downstream event used for activation.
Revenue or value source, refunds or reversals, and cohort maturity.
Attribution source, window, model, and known consent or privacy limits.
Media cost source, agency fees excluded or included, and any missing spend.
Product releases, outages, pricing changes, promotions, store experiments, and major creative launches.
Raw exports or immutable snapshots needed to reproduce the view.
A baseline is a comparison reference, not proof that a later change caused an outcome. If platform-reported conversions, product analytics, an attribution provider, and finance records disagree, preserve the disagreement. The onboarding task is to define which source answers which question and who owns reconciliation.
The mobile app marketing audit provides a broader diagnostic order when the evidence system is already unreliable. The mobile app marketing dashboard framework covers the recurring reporting contract after onboarding.
Gate 4: define the measurement contract before optimization
The measurement contract turns ambiguous metrics into governed definitions. It should fit on one page and include, for every decision metric:
Metric Required definition Decision it may support What it cannot prove alone --- --- --- --- Install or first open Source, deduplication, attribution window, platform Delivery and acquisition volume User quality or incrementality Activation Exact event, eligibility, time window, exclusions Early quality and funnel diagnosis Long-term value Retention Cohort entry, return event, maturity, identity Product or audience follow-up Causal impact of media Revenue or value Source, gross/net treatment, refunds, maturity Economic review Future realized value without uncertainty Cost Included platforms, fees, credits, currency, tax Spend control and efficiency arithmetic Incremental profit Forecast value Model version, training population, update date Scenario planning Observed realized value
For each metric, name the system of record, calculation owner, refresh delay, expected exceptions, and escalation path. If the agency introduces a derived metric, the formula and inputs belong in the register. A label such as "quality score" or "blended efficiency" is not acceptable without a definition that another analyst can reproduce.
Do not change conversion actions or event mappings simply to make a dashboard agree. First establish whether the difference comes from identity, attribution, timing, eligibility, currency, refunds, or implementation. Only then approve a configuration change with an owner, expected consequence, rollback condition, and annotation date.
Gate 5: assign decision rights, not just deliverables
A statement of work may say that the agency manages campaigns and the client supplies creative. It still does not say who can raise daily spend, pause a market, reject a claim, alter a conversion event, or decide that evidence is insufficient.
Create a decision-rights matrix for recurring choices:
Decision Recommends Approves Executes Must be consulted Evidence required --- --- --- --- --- --- Budget reallocation within an approved envelope Agency Internal growth owner Agency Finance when guardrails change Current spend, quality, maturity, constraint New market or channel Agency or internal owner Named executive/budget owner Assigned operator Legal, product, analytics Readiness, policy, tracking, creative, economics Campaign or ad pause Agency under defined conditions Pre-authorized or internal owner Agency Creative/product if relevant Trigger, scope, expected risk, rollback Creative claim or format Creative team or agency Brand/legal owner Assigned publisher Product and store owner Rights, substantiation, platform requirements Store-page change Product marketing or agency Store owner Authorized app-store user UA, product, legal Hypothesis, markets, test plan, release conflict Event or conversion change Analytics/product owner Measurement owner Technical owner Agency, finance, product Specification, QA, impact map, rollback Reporting-definition change Analyst or agency Measurement and finance owners Report owner Growth lead Formula, historical impact, effective date
The exact names will vary. What matters is that one accountable approver exists, pre-authorized boundaries are explicit, and silence has a defined escalation path. An agency should not infer authority from access.
Gate 6: test the whole operating loop before material spend changes
A role can work in isolation while the system fails as a whole. Run one low-risk operating rehearsal that crosses the real dependencies. For example:
The agency drafts a campaign or a bounded change request.
The creative and policy evidence is attached using the agreed naming convention.
The correct internal owner approves or rejects it in the expected channel.
The operator executes only the approved change.
The change appears in the platform history and shared decision log.
Cost and agreed outcomes appear in the reporting layer after the documented delay.
The analyst reproduces one calculation from source data.
The team closes the decision with an owner, next review date, and rollback condition.
This rehearsal is not a performance test. It proves that the operating system can carry a decision without losing ownership, context, or evidence. If the loop fails, repair that dependency before increasing the consequence of the next change.
Organize the first operating period around evidence states
A universal 30-, 60-, or 90-day plan ignores app maturity, attribution delays, creative capacity, product cycles, and budget. Use evidence states instead. They can occur quickly or slowly depending on the program.
State A: control ready
Every durable asset has an internal owner and backup. Agency access is role-based, tested, and recorded. Billing, security, and app-store recovery paths are known. The exit register exists before campaign changes begin.
State B: measurement ready
The baseline is frozen. Event, cost, value, attribution, and cohort definitions are documented. Known discrepancies have owners. The team knows which reports are operational, which are directional, and which questions require stronger causal evidence.
State C: workflow ready
Budget, campaign, creative, store, product, analytics, and incident decisions have owners and response paths. One end-to-end rehearsal has passed. Reporting calculations and annotations can be reproduced.
State D: learning ready
The team has a prioritized question, a bounded change, a decision date, and a rule for act, hold, repair, or stop. Creative and product capacity can support the test. No unresolved control or data issue makes the result uninterpretable.
Do not call onboarding complete because a calendar milestone arrived. Call it complete when the relevant acceptance evidence exists.
Build creative, store, and product handoffs into the same system
Mobile acquisition crosses surfaces. An ad may set an expectation that the store listing, onboarding flow, pricing, permissions, or first product experience must fulfill. If each team operates from a separate backlog, the agency can optimize the handoff it sees while the user encounters a different promise.
For every planned acquisition message, record:
Audience and market.
Claim and supporting evidence.
Ad asset and usage rights.
Destination store page or product page.
App version and in-product experience.
Activation event expected to represent first value.
Owners for creative, store, product, analytics, and approval.
Conflicting experiments or releases.
Expiration or review date.
This does not require the agency to own every surface. It requires the operating contract to expose the handoff. If the engagement includes only paid media, the agency can still flag that store or product evidence is missing; the internal owner decides whether to pause, repair, or proceed with the limitation documented.
Define reporting acceptance as reproducibility
A dashboard is accepted when the intended reader can trace a number to its definition and source, not when the charts look complete. Test at least one reporting period by asking finance, growth, and the agency to reproduce:
Included spend and excluded costs.
The count and value of the primary outcome.
The cohort or attribution date used.
Currency conversion and refund treatment.
The difference between source-native, blended, and finance views.
One annotation for a material campaign, product, or measurement change.
Differences are not automatically errors. They become dangerous when they are invisible. The report should display source, refresh time, and limitation close to the decision it informs.
Agree change control and incident response before the first incident
Document which changes require approval, which are pre-authorized, and which may be made to limit immediate harm. Define an incident as an event that threatens spend control, account access, measurement integrity, policy status, app availability, user trust, or data exposure.
The incident record should capture detection time, affected assets, immediate containment, owner, evidence preserved, stakeholder notification, recovery decision, and post-incident action. Avoid fixing an access or policy problem by creating replacement accounts, sharing credentials, or obscuring ownership. The operating contract should make the compliant route easier than improvisation.
Design exit readiness on day one
Exit readiness protects continuity and often improves the relationship while it is active. Keep a living handover register containing:
Business-owned account IDs and current partner roles.
Campaign, audience, exclusion, conversion, and naming logic.
Editable creative files, licenses, claims evidence, and performance annotations.
Store assets, experiments, and release dependencies.
Event specifications, tag/container versions, and change history.
Reporting definitions, queries, exports, dashboard ownership, and known gaps.
Open tests, decisions, incidents, and unresolved platform cases.
Revocation order, final export, and acceptance owner.
When the engagement ends, remove access in a dependency-aware order after needed exports and transfers are verified. Google Play supports removing users and setting access expiry, while platform partner structures offer their own revocation controls. Record who verified each removal. Do not delete evidence or history that the business needs to operate or meet its obligations.
Commercial terms and handover scope should have been evaluated before signature; the mobile app marketing agency pricing framework helps normalize what a proposal includes and excludes. Onboarding turns those terms into testable controls.
A fictional onboarding acceptance example
Consider a fictional subscription app that has signed an agency to manage Apple Ads and Google Ads App campaigns while the internal team retains Meta, product analytics, and store ownership. The agency proposes an immediate restructure. The client instead uses the acceptance gates.
The asset register shows that one Google Ads client account is owned by an old manager account, the Apple Ads invitation grants broader campaign-group access than the scope requires, and the activation event changed meaning in the latest app release. Finance also reports net subscription revenue by payment date while the growth dashboard uses attributed gross trial value by install date.
The correct onboarding decision is not to average the numbers or start the restructure. The company resolves Google Ads ownership, narrows Apple Ads access, versions the activation definition, and labels the two revenue views for different decisions. The agency then rehearses a campaign change through approval, execution, history, reporting, and decision-log closure.
No performance claim follows from this repair. The value is that the first media decision will be made inside a system that the business controls and can interpret.
Failure states that should delay affected spend
Delay the relevant change when any of these conditions remains material:
The only administrator or recovery path belongs to the agency or a departed employee.
Shared credentials are required to perform routine work.
The client cannot see or revoke the agency's access.
The primary conversion changed without an impact map or baseline annotation.
Cost, value, currency, refund, or cohort definitions cannot be reproduced.
No person can approve budget, creative claims, store changes, or event changes.
The agency can publish but the client cannot audit the change history.
Creative rights or claims evidence is missing.
A store, product, or measurement dependency makes the proposed test uninterpretable.
There is no export and revocation plan for material accounts, data, or creative.
A delay can be scoped. Missing store access may block a store experiment without blocking an already approved campaign analysis. The decision record should identify the affected work, the owner, the repair evidence, and the condition for resuming.
The practical next step
Start with the accounts and decisions that can change spend or measurement. Build the asset register, map least-necessary access, freeze the baseline, define the metric contract, assign decision rights, and rehearse one operating loop. Only then authorize the first consequential change.
For established app teams that have selected an agency or are transferring one, Sharply Labs can review the signed scope, account inventory, event map, reporting requirements, creative and store ownership, and decision calendar. The output is a bounded onboarding-readiness map, acceptance gaps, and a first-decision plan. It is not a promise of lower CPI or CPA, higher ROAS, faster scale, revenue growth, approval, or account stability. Discuss a mobile app agency onboarding review.