WiseTrack — B2B Mobile Measurement & Analytics

Context

Dec 2021 — Mar 2025 · Early startup → pilot-led validation → initial commercial adoption · Maturity: Operational.

Problem

Build a credible B2B mobile measurement product that could help app teams understand attribution and product performance while earning trust across SDK, data, reporting, and advertising-partner workflows.

Users

Mobile-app product, growth, and analytics stakeholders using attribution/reporting workflows, plus ecosystem partners involved in measurement and integration.

My Role

Product Manager; product ownership, CEO reporting, detailed specification, and cross-functional delivery — not direct manager of the full organization.

Responsibilities

• Personally led competitive research across Adjust, AppsFlyer, Adtrace, Metrix, AppMetrica, Amplitude, and related MMP/analytics patterns.
• Personally authored and drove detailed specifications for Attribution, Event Analytics, Callback, four Cohort models, and KPI/reporting design across acquisition, retention, and revenue.
• Sequenced roadmap and releases, coordinated cross-functional delivery, and supported pilot-led validation, ecosystem integrations, initial commercialization, and the early fraud-product direction.
• Designed product enablement and operating-process documentation covering training scenarios, flowcharts, role clarity, requirement approval, stakeholder workflows, and KPI/feedback loops.

Constraints

• Early-stage company with evolving organization, market evidence, and product direction.
• Approximately 10 applications were in pilot/onboarding; this was not 10 paying customers.
• Not every researched or specified capability reached production.
• Fraud evidence is preliminary and context-specific.

Product Decisions

• Use competitor/domain research to define attribution-window, reporting, cohort, and fraud decisions instead of copying feature lists.
• Treat pilot/onboarding as a learning pipeline and keep it distinct from commercial adoption.
• Prioritize analytical storage migration where representative reporting latency made the product cost visible.
• Build early fraud controls incrementally from observable anomalies rather than claim a complete AI fraud system.

Delivery & Technical Approach

• Worked deeply with tracker/attribution semantics, SDK and API workflows, MySQL/ClickHouse context, reporting models, callback/postback behavior, and early fraud controls.
• Coordinated backend, Android, frontend, design, SDK, infrastructure, business, and customer-facing delivery.
• Coordinated the analytical migration that reduced one recorded session-overview API response on roughly three years of data from about 1.2s in MySQL to about 0.25s in ClickHouse.

Product flow

1. Market & competitor research
2. Problem/specification definition
3. Cross-functional delivery
4. SDK / tracker onboarding
5. Attribution & reporting
6. Pilot feedback
7. Initial commercial adoption

Evidence / Outcome

• Approximately 10 applications entered pilot/onboarding.
• Alibaba was the first confirmed paying customer, supporting initial commercial adoption.
• One recorded session-overview API improved from about 1.2 seconds to about 0.25 seconds after the coordinated ClickHouse migration.
• An early same-app/same-channel fraud comparison showed about 20% fewer attributed installs with initial controls; this remains a preliminary context-specific comparison.

What I Learned

• In B2B measurement, product trust depends on precise definitions and data semantics as much as feature breadth.
• Pilot volume and paying-customer traction are different signals and should never be merged.
• Technical depth is most useful when it clarifies product trade-offs, not when it turns product ownership into an engineering-credit claim.

Evidence Boundary

Next Iteration

Strengthen customer-level outcome measurement around SDK onboarding, attribution trust, reporting adoption, and commercial retention while keeping fraud and performance claims tied to specific evidence.