Android repeat sessions
Shows that Android users already rely on mobile web enough to justify native consideration.
Suggested event: android_mobile_reply_session_returned
KPI page
Android ReplyPilot Keyboard KPIs
Android ReplyPilot Keyboard KPIs should prove Android demand before native keyboard work. The strongest KPIs are Android mobile web repeat sessions, selected copied drafts, copy-back friction reports, permission comprehension, shared entitlement success, selected editable insertion, keyboard fallback usage, and manual final posting clarity. This is roadmap planning and should not be treated as current Google Play availability.
Last updated: July 11, 2026. These are rollout metrics, not customer outcome claims.
Measurement purpose
What this metric set should prove
Use these KPIs to decide whether Android keyboard work solves a real Android insertion problem. The team should not treat native implementation as the fix when the underlying issue is weak reply quality or unclear positioning.
Core metrics
Which events should be measured?
Android selected draft copy
Shows that the generated drafts are useful before keyboard insertion is introduced.
Suggested event: android_selected_draft_copied
Copy-back friction rate
Measures complaints about switching apps, pasting, or composer handoff.
Suggested event: android_copy_back_friction_tagged
Permission comprehension
Measures whether users understand keyboard boundaries before install or onboarding.
Suggested event: android_keyboard_permission_understood
Leading indicators
What should move before roadmap priority changes?
Android users already complete mobile web
The keyboard should improve a proven workflow rather than rescue an unproven one.
Insertion friction is specific
The problem should be app switching or composer insertion, not generic dissatisfaction with draft output.
Entitlement reuse works
Account, quota, billing, and revoke behavior should remain server-side before native rollout.
Manual approval remains understood
Users should know the keyboard inserts selected text but does not publish the social reply.
Decision rules
How should these metrics guide the roadmap?
Build after Android evidence
Do not prioritize Android keyboard until Android-specific repeat usage and selected copy are visible.
Delay on permission anxiety
If permission comprehension is weak, improve explanation and keep mobile web fallback prominent.
Keep output editable
Selected insertion should place editable text and leave facts, tone, and CTA pressure under user control.
Keep store status honest
Do not imply Google Play availability until a shipped native surface is verified.
Instrumentation guardrails
Keep metrics honest
Keep metrics as product signals
Label metrics as TypeToSell rollout and safety signals, not customer outcome claims, revenue lift, reply-rate guarantees, ranking proof, ratings, or reviews.
Separate generated from selected
Track generation starts separately from selected copy or insertion so the team does not confuse curiosity with real workflow completion.
Keep final posting outside TypeToSell
Measure draft handoff and copied or inserted text, but do not instrument TypeToSell as the system that presses the final public platform button.
Related reading
Connect metrics to audits and execution
Android keyboard readiness audit/audits/android-replypilot-keyboard-readiness-auditAndroid keyboard benchmark/benchmarks/android-replypilot-keyboard-readiness-benchmarkAndroid keyboard workflow/workflows/android-replypilot-keyboard-workflowAndroid keyboard technical spec/specs/android-replypilot-keyboard-technical-spec
FAQ
Metrics questions
What KPI proves Android keyboard demand?
Android repeat sessions plus selected copied drafts and copy-back friction prove demand better than broad mobile traffic.
What should Android keyboard never measure as success?
It should not measure automatic posting because TypeToSell keeps final publishing manual.
Is Android ReplyPilot Keyboard available now?
This KPI page is roadmap planning and should not be treated as current Google Play availability.