Install
$ agentstack add skill-markdavidgan-apple-dev-skills-app-analytics ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
App Analytics
Measure the few things that drive decisions — not everything you can. Over-instrumenting creates noise, privacy risk, and a dashboard nobody reads. This skill is about what to measure; performance telemetry is performance-instruments (MetricKit).
> Test for every metric: if this number moved, would we do something differently? If not, don't track it.
Start with one north-star metric
A north-star is the single number that best captures delivered user value — leading, not lagging.
- Good: "weekly active note editors", "sessions completed per user/week", "tracked workouts/week."
- Weak: raw downloads or DAU alone (vanity; doesn't capture value).
- The north-star should predict retention and revenue. Everything else is a supporting or guardrail metric.
The funnel (AARRR, pragmatically)
| Stage | Question | Typical metric | |-------|----------|----------------| | Acquisition | Are people arriving? | Impressions → installs (see asc-aso) | | Activation | Did they reach first value? | % completing the "aha" action in session 1 | | Retention | Do they come back? | D1 / D7 / D30 cohort retention | | Revenue | Do they pay? | Trial→paid, conversion, ARPU (see paywall-design, app-store-pricing) | | Referral | Do they bring others? | Invites sent/accepted, rating prompts |
Activation and retention are where most apps actually win or lose. Define your activation event precisely ("created and saved 1 note", "logged 3 days") and measure the % who hit it on day 0 — it's the highest-leverage number for a young app.
Retention is a cohort, not a percentage
Always read retention as cohorts (users who installed in week N, % active in weeks N+1, N+7…). A single "retention %" hides whether you're improving. A flattening retention curve (not decaying to zero) is the signal of product-market fit.
Event taxonomy — design it before you instrument
A messy event log is worse than none. Conventions:
- Name consistently:
object_actionin one tense —note_created,paywall_viewed,subscription_started. Pick a casing and keep it. - Properties over event explosion: one
paywall_viewedevent with asourceproperty beatspaywall_viewed_onboarding/paywall_viewed_settings/ … Same event, structured dimensions. - Track the funnel-defining events first (activation, key actions, purchase steps), then add detail only when a question demands it.
- Version the schema and write it down — undocumented events rot.
- Capture enough context to segment (platform, plan, locale) without capturing PII.
Apple's built-in sources (often enough)
- App Store Connect → App Analytics: impressions, product page views, conversion rate, installs, retention, and sessions — segmented by Source Type (Search / Browse / Referrer). Free, privacy-safe, no SDK. Start here.
- StoreKit / Subscription analytics: trials, conversions, churn, proceeds, by product — the source of truth for monetization (pairs with
storekit-purchases). - MetricKit: performance/diagnostics from the field (launch, hangs, hitches) — route to your dashboards via
performance-instruments.
Reach for a third-party analytics SDK only when you need event-level product funnels the built-ins don't give you.
Privacy is part of analytics, not a footnote
- Minimize: collect the least that answers your question. Don't log PII or precise location "just in case."
- Anything you collect must be reflected in the privacy nutrition label and, for required-reason/tracking APIs, the privacy manifest — see
privacy-manifest. Tracking across apps requires App Tracking Transparency consent. - Prefer aggregate/on-device where possible. Truthful labels are an App Review and trust requirement.
From metric to action
- Pick the one decision you're trying to inform.
- Define the metric + target + window (ties to
product-specsuccess metrics). - Instrument the minimum events to compute it, with clean names/properties.
- Read it as cohorts/segments, not a single global number.
- Change one thing, measure the move, keep or revert. Repeat.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: markdavidgan
- Source: markdavidgan/apple-dev-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.