The questions support actually gets

"No data is showing"

Three checks, in order — one of them is almost always it:

1. Ask the verify endpoint. It answers the question directly — did events arrive in the last N minutes? Run it (or ask your AI agent to) with the same credentials the app starts with:

   curl -s "https://shfpcykkzmzijpimpsrd.supabase.co/functions/v1/verify?minutes=60" \
     -H "x-app-id: <app-slug>" -H "x-api-key: <api-key>"

   "events_received": true means data is flowing and the problem is in what you're looking at (see checks 2–3). false comes with a hint naming the likely cause — usually wrong credentials or the app never flushed (events upload every ~15 seconds and immediately on backgrounding; force-quitting from the app switcher right after a tap can lose that tap's batch).
2. Is the SDK-carrying version actually live? The SDK only exists in builds that include it. If the integrated version is still in review — or your users are on older versions — those users are invisible. This is a hard limit, not a bug: users on old app versions never appear.
3. Are you filtered out? Internal users (your marked devices, all simulators) are excluded from every metric by default. If you're testing on your own marked device, the charts will ignore you — flip the include-internal toggle, or check the Live tab, which shows internal users with an INTERNAL badge.

"The numbers don't match App Store Connect"

They're not supposed to match exactly, for three honest reasons:

• Downloads ≠ first opens. App Store Connect counts downloads; FolioKit's "new users" are people who opened the app with the SDK inside. Some people download and never open; some open days later. The gap is real behavior, not measurement error.
• Old versions are invisible. Until a user updates to a build containing the SDK, they exist in ASC's numbers but not in FolioKit's. Expect a drift that shrinks as the update rolls out (watch the app-version breakdown on Overview).
• Time zones. FolioKit days are UTC; App Store Connect reports in Pacific time. Daily numbers will never line up edge-to-edge — compare weeks or months, not single days.

Note that FolioKit's Revenue tab can show Apple's own download and proceeds numbers (via the App Store Connect connection) next to SDK data — that's the honest way to see both truths at once.

"The numbers don't match RevenueCat"

For subscription events these should match — the SDK and RevenueCat share one user ID, so there's no identity mapping to drift (how the join works, and why connector-based stacks can't say this). Where legitimate differences appear:

• Internal filtering: FolioKit excludes your own devices and sandbox noise from metrics by default; RevenueCat's dashboard shows everything.
• Since-when: the webhook streams events from the day it was connected. Earlier revenue only appears if it was imported as history — imported days are labeled as such.
• Time zones, again: FolioKit is UTC; check what your RevenueCat dashboard is set to before comparing single days.
• Gross vs net: FolioKit's revenue events carry RevenueCat's gross prices. Apple's net proceeds are a separate, smaller number shown separately (the full explainer) — make sure you're comparing gross to gross.
• Paying users in FolioKit means currently entitled (reconciled daily against RevenueCat), which equals RevenueCat's active entitlements count — not "everyone who ever paid".

If gross subscription events genuinely disagree, that's a bug — tell us.

"Do I need an ATT prompt?"

No. Nothing the SDK does is "tracking" in Apple's definition — no IDFA, no fingerprinting, no cross-app data. Apple Search Ads attribution comes deterministically from Apple's own AdServices framework, and paid-social measurement uses SKAdNetwork, which is anonymous and aggregate by design. The precise version of this claim — including what FolioKit deliberately won't do — is on the SDK facts page.

"How do I delete my data — or a test user?"

• A test user (your own device, a tester): open the Live tab, click the user, mark as internal. They're excluded from every metric from then on. Simulators are flagged automatically. This is almost always what people actually want — the history stays inspectable but stops polluting charts.
• Actual deletion (a user's data, an app's data, or everything): email contact@foliokit.io. Your events are yours — exportable on request and deleted on request, as the data & privacy page commits. A self-serve export/delete UI is on the status page as coming; until it ships, a human does it promptly.

"What does it cost?"

FolioKit is free during early access, and early-access pricing is still being finalized — we won't invent a number here just to have one. What's already decided: you'll hear about pricing from a person before anything changes, your data stays yours (exportable, never sold) regardless, and early-access users won't be surprise-billed. Opinions on what it should cost are genuinely welcome: contact@foliokit.io.

"Which AI agents work? Do I need one at all?"

Any coding agent that can read and edit your project — Claude Code, Cursor, Windsurf, Copilot agents — can follow the integration prompt; it's plain instructions, not tool-specific magic. No agent? The integration guide is written step-by-step and a human can follow it in well under an hour. The agent path exists because it's the path that also verifies itself.

"Is the API key in my app a secret?"

No — it's designed to be shipped. The key is send-only: it can append events for your app and read nothing. Someone extracting it from your binary could at worst send you junk events (which internal filtering and anomaly detection make visible). Keys that can read anything never go inside an app.

"Why don't my landing-page numbers match my hosting analytics?"

Adblockers. Brave and most content blockers block the tracking request entirely, so those visitors are invisible to FolioKit's snippet while your server logs still count them. This is documented honestly in the web tracking guide — treat web numbers as a directional floor, and trust ratios more than totals.