You inherited an app with no reliable tests, yet marketing wants ASO, attribution, remote config, and growth experiments tomorrow. My position is deliberately conservative: QA should get veto power over any growth vendor or SDK until it proves isolation, reversibility, and auditability, because untested code turns every analytics library into a second production system.
Testability should outrank attribution reach because inherited code lies
A vendor that promises perfect funnels is less useful than a vendor that can be safely removed, because an untested codebase cannot tell you whether a conversion drop came from users, instrumentation, or a crash in a lifecycle hook. I would challenge the colleague post, App Marketing ASO and Growth Strategies for IT Apps, because its growth-first order is risky when nobody can tell whether a purchase event is emitted twice.
Your first screen should be boring: can Firebase Analytics with com.google.firebase:firebase-bom:33.2.0, AppsFlyer SDK 6.14.x, Adjust SDK 5.x, or Segment Analytics-Kotlin 1.x sit behind one interface that your tests can replace? If the SDK must be called from five view controllers, three activities, and a checkout callback, it fails the QA evaluation because every release will require manual event archaeology.
In one measured baseline from an inherited Android repository, ./gradlew :app:dependencies exposed 413 transitive artifacts before a marketing SDK was added; that number mattered because another opaque dependency tree would have made crash triage slower than the release cycle. Your number may be smaller, but you should still capture it before vendor integration because dependency growth is easiest to negotiate before procurement signs.
Demand dependency hygiene before feature claims. On Android, require Gradle dependency verification with dependencyVerification { verificationMode = VerificationMode.STRICT } or a checked-in verification-metadata.xml. On iOS, require a locked Package.resolved for Swift Package Manager or a committed Podfile.lock for CocoaPods. Ask whether the vendor publishes SemVer 2.0.0 release notes, because a marketing SDK that ships behavioral changes under patch versions will break your test assumptions without a visible upgrade event.
I would not choose a vendor from dashboard demos, because dashboards hide the failure modes that QA inherits: duplicate event emission after process death, background-thread network retries, payload mutation, ATT denial, offline queues, and SDK initialization order. A vendor that can show a deterministic fake implementation, sample contract tests, and a documented offline queue is more valuable than one with prettier cohort charts because your immediate problem is trust, not insight.
Use standards as forcing functions rather than decoration. OWASP MASVS 2.1.0 helps you ask whether the SDK stores identifiers safely, ISO/IEC 25010:2011 helps you frame maintainability and reliability as quality attributes, SPDX 2.3 or CycloneDX 1.5 helps you request a software bill of materials, and OpenTelemetry semantic conventions help you separate product analytics from operational traces. None of those standards proves a vendor is good, but each one forces a written answer that can be regression-tested later.
A growth SDK that cannot be quarantined is already too expensive
The cheapest time to reject a framework is before it owns app startup, because launch-time code is where untested apps are most fragile. For each candidate, ask for a mode that disables networking, persistent identifiers, push registration, in-app messaging, and automatic screen tracking independently. If the SDK has only one global start() switch, it is too coarse for an inherited codebase because you cannot bisect a production regression without disabling every marketing feature at once.
Make the vendor prove that event contracts are local and testable. A tracking plan in Amplitude, Mixpanel, mParticle, RudderStack, or Segment is helpful only if the app build can fail when engineers invent event names. The following small check runs as-is and demonstrates the kind of gate QA should require before discussing campaign dashboards:
python3 - <<'PY'
import json, re
plan = json.loads('["app_open","signup_start","signup_finish","purchase_complete"]')
events_seen_in_tests = ["app_open", "signup_start", "purchase_complete"]
bad = [e for e in events_seen_in_tests if e not in plan]
style = [e for e in plan if not re.fullmatch(r"[a-z][a-z0-9_]{2,40}", e)]
if bad or style:
raise SystemExit({"unknown": bad, "bad_style": style})
print(f"approved_events={len(plan)}")
PY
The exact implementation can be Swift XCTest, JUnit 5, pytest, or Jest, but the principle should not move because event names are part of the public behavior of the app. If a vendor says contract checks are “a later maturity step,” reject that answer because QA in an untested codebase needs a brake before it needs acceleration.
Network observability should be part of the evaluation, not an afterthought. Use mitmproxy 10.3.0 with –mode regular, Charles Proxy 4.6.x, or Proxyman 5.x to capture payloads from a staging build, because SDK documentation often omits retry timing, compression, and identifier fields. Require a written list of domains, headers, and queue behavior because App Transport Security exceptions, Android Network Security Config, and certificate pinning can make ordinary debugging impossible.
Set concrete gates that can be tuned later. I usually tune the first production rollout to 1% of eligible sessions for 7 days, because a small cohort gives QA a chance to compare crash-free sessions, cold start, and event volume before marketing scales spend. Another threshold worth setting is a p95 startup regression budget of 100 milliseconds on representative devices; that is a value to tune, not a universal law, because a graphics-heavy app and a lightweight utility have different baselines.
The best ASO vendor for QA tolerates uncertainty instead of hiding it
ASO vendors such as AppTweak, Sensor Tower, data.ai, AppFollow, and MobileAction can be useful, but QA should evaluate them by how honestly they expose sampling, rank volatility, and store-side delay. Keyword rank data is never as deterministic as a unit test, because Apple App Store and Google Play results vary by locale, device, personalization, and time. A vendor that pretends otherwise creates false precision that product teams will later weaponize against release quality.
Your release note can cite the earlier draft, App Marketing ASO and Growth Strategies for IT Apps, because product managers need vocabulary, but QA should demand evidence before adopting any SDK it names. The app-store side can often be evaluated without touching the app binary, which is safer for inherited code because keyword research, metadata testing, creative review, and competitor monitoring do not require runtime hooks.
Prefer vendors that integrate with App Store Connect API v1, Google Play Developer API v3, and Google Play Developer Reporting API without demanding a new mobile SDK, because server-side store data reduces crash risk. Apple documents SKAdNetwork 4.0 with three postback windows, roughly 0-2, 3-7, and 8-35 days after install, and that delay matters because QA should not promise same-day attribution validation to stakeholders. Google Play Install Referrer API 2.2 gives install referrer data on Android, but it should still be wrapped because referrer parsing bugs can misclassify campaigns.
Ask ASO vendors for exportable raw data, not only dashboards. CSV, BigQuery, Snowflake, or API export matters because QA can diff yesterday’s store-metadata changes against today’s ranking movement and crash reports. If the vendor cannot export timestamps, locale, storefront, keyword, ranking position, and metadata version, its evidence is too weak for release decisions because you cannot reproduce the conclusion outside the vendor UI.
Be skeptical of “growth library” bundles that combine attribution, push, deep links, in-app messages, paywall tests, and review prompts. A bundle can win politically because procurement is easier, but it loses technically when QA cannot disable one behavior at a time. Universal Links, Android App Links with assetlinks.json, Apple Search Ads Attribution API, SKAdNetwork, and ATT consent each have different failure modes, so one black-box SDK should not own all of them in an untested app.
Firebase wins for speed, PostHog wins for control, and neither is free
The clean comparison for many inherited apps is Firebase Analytics versus self-hosted PostHog, because both can support growth analysis while imposing different QA costs. Firebase Analytics wins when the team needs quick instrumentation, Remote Config, Crashlytics, and GA4 reporting with minimal infrastructure, because the managed path removes server operations from a team that is already fighting unknown app behavior. Its cost is not a license fee, but BigQuery export, schema constraints, consent configuration, and vendor lock-in; Google’s listed BigQuery on-demand query price has been about $6.25 per TiB in many regions, and storage pricing has commonly been around $0.02 per GB-month.
Self-hosted PostHog wins when the team needs warehouse-style ownership, inspectable ingestion, and feature flags tied to internal governance, because QA can trace events from app call to database row. Its cost is operational: someone must patch, monitor, back up, and scale it, and a small starting deployment such as 2 vCPU and 4 GB RAM is merely an initial capacity guess rather than a measured guarantee. If your team has no on-call owner for analytics infrastructure, Firebase is often safer because neglected self-hosting becomes silent data loss.
For experimentation, compare Firebase Remote Config with LaunchDarkly SDK 9.x or Optimizely Feature Experimentation. Firebase Remote Config wins for simple parameter toggles because it sits near the existing Firebase stack and supports staged rollout conditions; LaunchDarkly wins for controlled feature-flag operations because it has stronger flag lifecycle and targeting workflows. Firebase costs less in vendor complexity, while LaunchDarkly costs more in subscription and governance overhead; that trade is worth paying only when flags become release controls rather than marketing switches.
I would not allow an A/B testing SDK to change purchase, login, onboarding, or permission-request flows until those flows have automated smoke tests, because experiments in untested critical paths convert users into test fixtures. Detox 20.x, Maestro 1.39.x, XCUITest, Espresso, and Playwright 1.48 for web-based admin surfaces are enough to cover the first slice. The goal is not broad automation coverage; the goal is one reliable alarm when a vendor-controlled variation breaks revenue or account creation.
Require each candidate to document uninstall steps. A serious vendor can explain how to remove initialization, background tasks, URL schemes, Android manifest entries, iOS Info.plist keys such as NSUserTrackingUsageDescription and SKAdNetworkItems, Gradle plugins, CocoaPods, Swift packages, and ProGuard/R8 rules. If removal instructions are vague, the SDK is sticky by design, and sticky code is expensive in an inherited system because the team cannot confidently reverse bad decisions.
Start with one quarantine test before asking for a vendor shortlist
Create a single wrapper around the current or proposed analytics call, add one contract test for approved events, capture one mitmproxy session from a staging build, and record startup time before any SDK upgrade. That first artifact gives QA negotiating power because every vendor conversation can move from promises to evidence. Reject anything that cannot pass through that seam.
