WiseTrack — B2B Mobile Measurement & Analytics
Bounded outcome evidence
Not customers.
A separate fact from the pilot/onboarding apps.
One API example; not platform-wide.
Observed attribution difference — not a causal estimate of fraud reduction.
Problem & Users
App teams needed trustworthy attribution and product-performance reporting across SDKs, APIs, and partner integrations.
Users: App product, growth, and analytics teams; measurement partners.
Role & Ownership
Product Manager — product ownership, specifications, roadmap choices, and cross-functional delivery.
Key Action
Used pilots as a learning pipeline; prioritized evidence-led analytics and integration work over feature breadth.
Key Decisions
- Evidence: pilot integrations surfaced SDK, attribution, and reporting issues. Trade-off: treating pilot volume as traction would create a faster commercial story but a weaker learning signal. Decision: use pilots as a learning pipeline and keep pilot/onboarding separate from paid adoption. Result: ~10 apps entered pilot/onboarding before the first confirmed paying client.
- Evidence: one representative session-overview API was recorded at about 1.2 seconds on the existing MySQL analytical path. Alternatives: keep optimizing the existing workload or move analytical queries toward ClickHouse. Trade-off: migration effort and coordination versus reporting responsiveness. Decision: prioritize the coordinated ClickHouse migration. Result: that recorded API example improved to about 0.25 seconds.
- Evidence: competitor research and KPI review showed that not every available MMP feature or metric was equally relevant, observable, non-redundant, or supported by partners. Decision: specify attribution, events, callbacks, cohorts, and reporting selectively instead of copying feature lists; reject or defer metrics when the evidence was weak.
Decision evidence, made visible.
Analytics Performance Decision
One representative session-overview API was recorded at approximately 1.2 seconds on the existing MySQL analytical path.
Migration effort and delivery coordination versus reporting responsiveness and analytics experience.
Prioritize a coordinated migration of the relevant analytical workload toward ClickHouse.
Evidence boundary: this is one recorded API example, not a claim that every query or every part of the platform improved by the same amount.
Measurement Semantics Map
App SDK
What is captured, when it is captured, and what context travels with the event.
Events & Attribution
What an event means and how attribution should be interpreted.
Analytics / Cohorts
Which behaviors belong together and what question each metric answers.
Reporting
Whether customers can understand a number and use it confidently in a decision.
Callbacks & Integrations
Whether meaning stays consistent when data moves into another system.
If two reasonable users can read the same metric and make different assumptions about what it means, the product definition is not finished.
Pilot integrations surfaced issues across SDK, attribution, and reporting, reinforcing the need for consistent definitions across the product flow.
Delivery & Technical Approach
- Personally led comparative product research across major MMP/analytics products and translated findings into attribution, reporting, cohort, fraud, and roadmap decisions.
- Authored and drove detailed specifications across attribution, event analytics, callbacks, cohort models, and KPI/reporting design while working with tracker/SDK/API, MySQL/ClickHouse, and early fraud-control context.
- Coordinated backend, Android, frontend, design, SDK, infrastructure, business, and customer-facing delivery.
- 01App SDK
- 02Events & attribution
- 03Analytics / cohorts
- 04Reporting
- 05Callbacks & ecosystem integrations
Outcome / Impact
Bounded results are summarized in the evidence cards near the top of this case.
Constraints & Boundary
- 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.
Scope note: ~10 apps were pilot/onboarding, not paying customers; Alibaba was the first confirmed paying client. Performance and fraud examples are specific recorded cases, not universal claims.
Reflection & Next
- 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 infrastructure decisions become product decisions when they directly change reporting latency, trust, or the ability to learn from customers.
Next: Strengthen customer-level outcome measurement around SDK onboarding, attribution trust, reporting adoption, and commercial retention while keeping performance claims tied to specific evidence.