# Multivariate Monetization

Your app likely presents users with different monetization paths: rewarded ads, interstitials, subscriptions, or paywalls. Each path brings different amount of revenue, depending on when and how it’s shown. ContextDecision uses machine learning decide which path will be the most profitable one, dynamically, based on the user's real-life context.

## Who is this for?

This strategy is ideal if your app already supports multiple monetization methods. The most common pairing is ad monetization alongside in-app purchases — such as a premium subscription or a one-time purchase to remove ads.

If that sounds familiar, you’re in luck. Replacing your ad logic with ContextDecision’s multivariate monetization unlocks a new stream of potential revenue with little effort and huge potential!

## How does it work?

Our ML model gets to decide which action has better chances of generating overall more revenue for you, for instance, watching an ad (a certain but low revenue action), or seeing an upsell (an uncertain but higher revenue action).

This allows the ML model to learn which contexts lead to revenue, and to prefer higher-yielding strategies in the future.

Based on our data, this has proven to be more profitable than always showing an ad, and doesn't increase user churn as showing an ad followed by a paywall would.

## How can I implement this?

1. If you haven't integrated ContextDecision into your app yet, head to [Getting Started](/basics/getting-started.md)
2. Next, start [Logging Conversions](/context-decision/logging-conversions.md) for the flow that ContextDecision will decide which monetization path to take
   1. When receiving the `context` object, the `shouldUpsell` boolean property indicates which monetization strategy should be taken, for example, when `true`, your app should display a paywall, and when `false`, display an ad.
3. We recommend having a cooldown mechanism if one of your monetization paths is showing a paywall, because capturing contexts close enough to each other might result in both being good moments, showing the paywall twice in a row. So a mechanism that limits the amount of paywalls per unit of time is ideal.
4. Now, when logging your outcomes, there are a few points of attention:
   1. There's no `skipped` outcome anymore, because you're now showing something to the user when `shouldUpsell` is both `true` and `false` .
   2. Before logging your outcome, log which path your app ended up taking by using a [Custom Outcome Metadata](/context-decision/advanced/custom-outcome-metadata.md), such as `"path": "ad"` and `"path": "paywall"` , in the example of a "ad vs paywall" flow.
      1. This is especially critical in case your cooldown mechanism changes the decision our ML models made, e.g. `shouldUpsell = true` but you've just showed a paywall, so you end up going with the ad path.
5. Logging [Revenue Outcomes](/context-decision/revenue-outcomes.md) becomes even more important. Since the ML model will be optimized for revenue, it's important for it to know how much revenue your ad interstitial generates, versus your paywall sales, for example.

## Best Practices

* **Track revenue whenever your flow generates income.**\
  If you can’t measure revenue precisely, use estimates — such as average eCPM (effective cost per mille) for ad impressions or average RPC (revenue per click) for ad-driven flows. These values help compare the relative performance of different monetization paths. Of course, the more accurate your data, the better the results.
* If your one of the paths of your flow is an ad banner, see [Inline Banners](/use-cases/inline-banners.md) for more tailored instructions.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.contextsdk.com/use-cases/multivariate-monetization.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.