Appstack

View saved version →

---
name: appstack-mcp
description: >-
  Best practices for using the Appstack Analytics MCP connector efficiently —
  correct tool call order, exact Cube measure/dimension naming conventions,
  and how to resolve a company name to app scope. Use whenever connected to
  the Appstack MCP server and asked for attribution/analytics data, ad spend,
  installs, revenue, integrations status, onboarding progress, dashboards,
  user journeys, or to create/manage standard links.
---

# Using the Appstack Analytics MCP connector well

The Appstack MCP server exposes real attribution and analytics data — installs,
ad spend, revenue, integrations, dashboards, user journeys, and standard links.
Every tool call costs a round trip; guessing instead of discovering wastes
several of them and often fails outright. This skill exists to cut that down
to as few calls as possible.

**The one rule that matters most: never guess a measure, dimension, or filter
value. Discover it first.** A guessed measure/dimension name fails; a guessed
filter value silently returns an empty result, which looks like "no data"
rather than "wrong input" — much harder to debug after the fact.

## Always start here

Call `whoami` **first**, before anything else, in every new session. It
resolves in one call:

- Which app_id(s)/app_name(s) the connection has access to.
- Each app's own organization_id/organization_name.
- Whether this is a project-scoped credential (`scope: "project"`) or a
  platform-admin one (`scope: "all_organizations"`).

Don't call `list_dimension_values` or guess app scope from a natural-language
company name — `whoami` already has it.

### Resolving a company name (platform-admin scope only)

If asked about a specific company by name (e.g. "give me the ad spend for
Carrots") under `all_organizations` scope, call `find_organization("carrots")`
— **do not** scan `whoami`'s full app list by hand looking for a name match.
`whoami`'s app list for platform-admin scope can run into the hundreds of
apps across unrelated organizations; `find_organization` resolves a
partial, case-insensitive name match to the actual organization_id and its
apps in one call. Only fall back to scanning if `find_organization` finds
nothing and you suspect "Carrots" might actually be an app name, not a
company name.

## Never guess a Cube measure or dimension name

Before calling `query_metrics` with a measure/dimension you haven't already
confirmed exists, call `list_metrics` (schema) or `list_dimension_values`
(valid values) first — unless you already have that schema in context from
earlier in the same session, in which case reuse it instead of re-fetching.

`list_metrics` is two-step: with no argument it returns a compact index of the
available views (name, description, measure/dimension counts); call it again
with `view="<name>"` to get that view's measures and dimensions. There is more
than one view — `events_view` holds ad-network and attribution metrics
(impressions, clicks, CTR, CPM, spend, installs), `eac_cohorts_view` holds
cohorts by install date — so never conclude a metric doesn't exist after
reading a single view.

**Concrete example of the failure mode this prevents:** the install-count
measure is `events_view.install` — **singular**, not `events_view.installs`.
A plural guess (the more natural English form) fails outright rather than
being auto-corrected. Treat every measure/dimension name as unconfirmed until
`list_metrics` has actually shown it to you, even ones that seem obvious.

Measures and dimensions confirmed to exist on `events_view` (there are more —
call `list_metrics` for the full set, this list is not exhaustive):

- Measures: `events_view.install`, `events_view.total_spend`,
  `events_view.revenue`, `events_view.trial_started`,
  `events_view.in_app_purchase`.
- Dimensions: `events_view.app_id`, `events_view.app_name`,
  `events_view.source_type` (e.g. filter `equals` `"non_organic"` for
  ad-attributed activity), `events_view.country`, `events_v

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: appstack-sdk
description: >-
  Integrate, review, or troubleshoot the Appstack mobile attribution SDK on
  Swift/iOS, Kotlin/Android, React Native, Flutter, or Unity. Use for SDK setup,
  event taxonomy, enhanced app campaigns, attribution, and supported Superwall
  or RevenueCat integrations.
---

# Appstack SDK

Appstack measures installs and post-install events for ad attribution and
campaign optimization. It is not a general event aggregator: send only events
and parameters that serve attribution or signals intended for ad networks.

## Start with the task and installed version

For an **existing app**, identify the platform and resolved Appstack SDK version
before using a code example. The references describe current APIs; compare the
installed version with its release notes or API documentation before applying a
call shape. React Native 2.x and 3.x have incompatible `configure` and
`sendEvent` signatures; its platform reference has a migration map. Do not turn
a review or bug fix into an SDK upgrade unless the user requests one or the fix
requires it.

For a **new install**, look up the latest stable version in the platform registry
and select that exact version. Do not use dynamic versions such as Gradle `+`.
For Unity's Android dependency, use the native version declared by the installed
Unity package.

Load the relevant references for the task:

| Task | Read |
| --- | --- |
| Install, initialize, use an SDK call, or debug platform behavior | The matching platform reference below |
| Design, send, or review events; revenue or matching parameters | [Event design](references/event-design.md) and the platform reference for code |
| Connect Superwall or RevenueCat; attribute paywall revenue | [Partner integrations](references/partner-integrations.md) and the platform reference for code |
| Review an integration or diagnose missing events/attribution | [Review and troubleshooting](references/review-troubleshooting.md) and the platform reference |

Platform references contain the install and call syntax. Use their signatures,
not a call shape remembered from another platform:

- Swift / iOS: [references/swift.md](references/swift.md)
- Kotlin / Android: [references/kotlin.md](references/kotlin.md)
- React Native: [references/react-native.md](references/react-native.md)
- Flutter: [references/flutter.md](references/flutter.md)
- Unity: [references/unity.md](references/unity.md)

Load another task reference only when the app or request needs it. Unity has no
official Appstack integration with Superwall or RevenueCat.

## Rules shared by every platform

- Configure once at app startup before sending events or reading attribution.
  Reconfiguration does not change the key, log level, or user ID. The customer
  user ID setter may run before configuration.
- Get separate development and production keys from **SDK** in the Appstack
  dashboard, and use the key for the build's environment. Deprecated `isDebug` and
  `endpointBaseUrl` options do not select the environment; use `logLevel` for
  diagnostics.
- `INSTALL` is automatic. Never send it manually.
- Prefer standard event types. Custom-event syntax and return values differ by
  platform; React Native 3.x passes the custom name directly and has no `CUSTOM`
  event type.
- Send only JSON-representable event parameters. Check computed numbers for
  `NaN` and `Infinity`; a type annotation alone cannot catch them.
- Enable Apple Ads attribution only on iOS 15+ after configuration. If the host
  app requests ATT permission, call it after the ATT callback so an authorized
  IDFA can be captured.

For a new integration, verify events on the Appstack **SDK** page before enabling
downstream ad-network integrations. For a review, report only issues present in
the app; the review reference is a checklist, not a mandate to add every feature.

Referenced files: 9 — file references are metadata, not package contents.

View saved version →

---
name: appstack-support
description: >-
  Decide whether an Appstack question needs a live call with support or can
  just be sent as a message, and how to book a call when it does. Use
  whenever the user asks to talk to Appstack support, is stuck on a
  multi-variable setup question (e.g. full ad campaign setup), or you find
  yourself about to say "it depends, we'd need to look at it live" more than
  once in the same conversation.
---

# Booking a call with Appstack support

Appstack support is reachable two ways: a live call, or a message
(`support@appstack.tech`). Most questions should go to the second — a call is
for the minority of cases where live back-and-forth actually saves time over
async messages.

## Book a call when

- There are **3+ interdependent settings or decisions** to sort out together
  (e.g. a full ad campaign setup).
- **The right answer depends on live data** and would change the
  recommendation (e.g. when to switch optimization events, campaign
  structure) — not a question with one fixed answer.
- It's a **strategy question** that's faster to iterate on live than over
  several back-and-forth messages.

**Signal to watch for:** if you catch yourself writing "it depends, we'd need
to look at it live" more than once in the same conversation, that's the cue
to book a call instead of continuing to message.

## Just message support when

- It's a **factual question with a clear, documented answer**.
- It's **troubleshooting where the cause can be diagnosed** from what's sent
  (screenshots, logs, IDs) — no back-and-forth needed to see it.
- It's **anything product/how-to related**.

## Booking a call

- Link: https://calendar.app.google/T8bxZ6Tp3foVAncm9
- Available hours: **4:30 PM – 9:30 PM CET**
- For everything else: `support@appstack.tech`

Referenced files: 1 — file references are metadata, not package contents.