AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

App Analytics

skill-markdavidgan-apple-dev-skills-app-analytics · by markdavidgan

Decide what to measure and how — north-star metric, activation/retention/conversion funnels, a clean event taxonomy, App Store Connect App Analytics, StoreKit/subscription metrics, and privacy-respecting instrumentation. Use when defining product metrics, designing analytics events, measuring retention or conversion, choosing a north-star metric, or interpreting App Analytics. Trigger on "analyti…

No reviews yet
0 installs
35 views
0.0% view→install

Install

$ agentstack add skill-markdavidgan-apple-dev-skills-app-analytics

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No 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.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-markdavidgan-apple-dev-skills-app-analytics)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

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 →
Are you the author of App Analytics? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

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_action in one tense — note_created, paywall_viewed, subscription_started. Pick a casing and keep it.
  • Properties over event explosion: one paywall_viewed event with a source property beats paywall_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

  1. Pick the one decision you're trying to inform.
  2. Define the metric + target + window (ties to product-spec success metrics).
  3. Instrument the minimum events to compute it, with clean names/properties.
  4. Read it as cohorts/segments, not a single global number.
  5. 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.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.