> ## Documentation Index
> Fetch the complete documentation index at: https://helium-mintlify-create-navigation-structure-42614.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Revenue tracking

> Track and analyze subscription revenue

Revenue tracking connects your purchase and subscription data to Helium so it can **attribute revenue to specific paywalls, experiments, and triggers**. Without it, Helium can track paywall opens and user interactions, but can't tell you which paywall actually drove a subscription.

Revenue data flows *into* Helium from your payment platforms via webhooks.

***

### **Supported Sources**

| Source                             | How it connects | What it sends                                                          |
| :--------------------------------- | :-------------- | :--------------------------------------------------------------------- |
| **RevenueCat**                     | Webhook         | Purchases, renewals, cancellations, refunds, billing issues, and more. |
| **App Store Server Notifications** | Webhook         | Apple purchase, renewal, and refund events directly from Apple.        |
| **Google Play RTDN**               | Pub/Sub         | Google Play purchase and subscription state changes.                   |
| **Stripe Connect**                 | Webhook         | Stripe subscription and payment events.                                |

You can connect **multiple sources**. If you use RevenueCat as a wrapper around App Store and Google Play, you typically only need the RevenueCat integration. If you process payments directly, connect the platform-specific webhooks instead.

***

### **RevenueCat**

The most common integration. RevenueCat aggregates purchases from all stores and forwards them to Helium in a single webhook.

#### Setup

1. Go to **Integrations** → **Revenue Tracking** in the Helium dashboard.
2. Copy the **webhook URL** and **authorization token**.
3. In RevenueCat, go to **Integrations** → **Webhooks**.
4. Add a new webhook with the URL and token from Helium.
5. Select the events you want to forward.

#### Event Mapping

| RevenueCat Event        | Helium Type                |
| :---------------------- | :------------------------- |
| INITIAL\_PURCHASE       | subscription\_start        |
| RENEWAL                 | subscription\_renewal      |
| CANCELLATION            | subscription\_cancel       |
| NON\_RENEWING\_PURCHASE | purchase                   |
| UNCANCELLATION          | subscription\_reactivation |
| BILLING\_ISSUE          | billing\_issue             |
| EXPIRATION              | subscription\_expiration   |

Helium normalizes all RevenueCat events into a standard schema with fields like revenue\_usd, product\_id, store, and app\_user\_id, so metrics work consistently regardless of the original store.

***

### **App Store Server Notifications**

For teams that don't use RevenueCat and want purchase data directly from Apple.

#### Setup

1. Copy the webhook URL from the **Revenue Tracking** tab in the Helium dashboard.

2. In **App Store Connect**, go to your app → **App Information**.

3. Paste the URL into the **Production Server URL** field.

Apple will send purchase, renewal, refund, and subscription state change events directly to Helium.

***

### **Google Play Real-Time Developer Notifications**

For teams processing Google Play purchases without RevenueCat.

#### Setup

1. In the **Revenue Tracking** tab, create or connect a **Cloud Pub/Sub topic**.

2. In the **Google Play Console**, go to **Monetization Setup** → **Real-Time Developer Notifications**.

3. Configure it to publish to the Pub/Sub topic from step 1.

Google Play will send purchase and subscription state changes to Helium via the Pub/Sub topic.

***

### **Stripe Connect**

For teams using Stripe for web-based or Apple Pay subscriptions.

#### Setup

1. In the **Revenue Tracking** tab, connect your Stripe account.
2. Helium receives subscription and payment events via Stripe webhooks automatically.

#### Avoiding Double-Counting

If you use **both RevenueCat and Stripe Connect**, RevenueCat may also forward Stripe events. To prevent double-counting, the Revenue Tracking tab lets you choose which source Helium uses for Stripe revenue:

| Setting            | Behavior                                                                           |
| :----------------- | :--------------------------------------------------------------------------------- |
| **Stripe Connect** | Helium uses Stripe's webhooks directly. Stripe events from RevenueCat are ignored. |
| **RevenueCat**     | Helium uses RevenueCat's webhook for all revenue, including Stripe.                |

Pick one source per store — don't send the same purchase from both.

***

### **What Revenue Tracking Enables**

Once connected, revenue data powers several features in Helium:

| Feature                     | How revenue data is used                                                      |
| :-------------------------- | :---------------------------------------------------------------------------- |
| **Paywall attribution**     | See which paywall a subscriber converted on.                                  |
| **Experiment metrics**      | Compare revenue per variant — ARPU, conversion rate, trial-to-paid, and more. |
| **Trigger-level analytics** | Break down revenue by trigger to see which entry points drive the most value. |
| **Subscription lifecycle**  | Track renewals, cancellations, and refunds attributed to specific paywalls.   |
| **Monitoring**              | Revenue metrics on the dashboard (MRR, ARPU, LTV projections).                |

***

### **Key Points**

* Revenue tracking is **inbound** — purchase platforms send data to Helium, not the other way around.
* All revenue events are **normalized** into a standard schema, regardless of source.
* **Pick one source per store** to avoid double-counting (especially Stripe via RevenueCat vs. Stripe Connect).
* Revenue data is **linked to paywall sessions** using user identity — this is how Helium attributes a subscription to the specific paywall that converted the user.
* Events are processed and available in metrics **within minutes** of being received.