Show the right offer
to each user

Integration typically takes under a day. Botsi is API-first: your app or server creates a profile for each user, requests the paywall Botsi predicts for them, and reports impression and purchase events back. There is no SDK rewrite, no paywall redesign, and no migration off the tools you already run. Registering your price points and paywalls is largely a one-time setup, so most of the engineering work lands before go-live rather than after.

Yes, and it integrates seamlessly. There is a documented path for exactly this:

• Create a Botsi profile
• Call Get Paywall for the prediction
• Render your own SwiftUI or Jetpack Compose paywall from the returned data
• Send the impression event
• Complete the purchase through StoreKit or Google Play Billing and validate it with Botsi

See Native Mobile Paywall Display in the docs. If your team already built the paywall, the decision point Botsi plugs into usually exists in your code already, which is the part most integrations have to create.

Growth or monetization owns it. In practice that is an hour or two a week once you are live: approving the offer set, and reading results. Engineering is involved for the integration and then effectively done — there is no ongoing build.

No. Botsi charges a fixed subscription bracket, never a percentage of what you earn. That gap widens as you grow: a percentage vendor gets more expensive in lockstep with every dollar you earn, while a fixed bracket is a known number you can forecast, and it only changes when you move brackets, not with every good month. It also makes payback obvious, because you are comparing one known number against measured incremental revenue instead of arguing about which base a percentage was calculated on.

Our Agency Partner program does include a partner revenue share, but that is a partner arrangement and has nothing to do with what customers pay.

Yes. Botsi never invents a price or bypasses in-app purchase. Every price a user sees is a real store product you already created and Apple or Google already approved, and every purchase still completes through StoreKit or Play Billing exactly as it does today. What Botsi varies is the selection: which of your pre-approved paywalls, offers, and price points to show each user. That is mechanically the same paywall and offer testing that RevenueCat, Superwall, and Adapty already run inside the platforms' rules, so it does not introduce a new store surface.

To be clear, neither Apple nor Google endorses or certifies Botsi, and the price points you create set the ceiling on what can be shown. Botsi decides which approved option fits each user, never a number outside your catalog.

The reason these reviews go smoothly is that the hard parts are handled inside the product rather than left on your desk. Botsi is GDPR compliant and SOC 2 compliant. It uses only the data you send it, never demographic or special-category data such as age, gender, or race, and never cardholder data, because purchases complete through StoreKit, Play Billing, or Stripe. All data travels over TLS and is encrypted at rest with AES-256.

Compliance built in means the regulatory rules from GDPR, CCPA, PIPEDA, and comparable frameworks are embedded in how the pricing engine operates and updated as legislation evolves, rather than bolted on afterwards: Botsi cannot access or infer demographic identity, and every price sits inside a range you approved, which removes the most direct forms of discriminatory pricing and takes a large share of the burden off your team.

We would still rather audit realized outcomes than treat clean inputs as settling the question. Reviewers will want depth, so the GDPR, fairness auditing, contract, and security answers below go further, and we will join a call with your counsel where that speeds things up.

The lift is measured against a concurrent, persistent randomized holdout, not a before-and-after snapshot. A slice of your traffic stays on your existing static pricing while the rest is optimized, and the reported number is the difference between the two groups. Because both groups live through the same season, the same store changes, and the same marketing, outside effects hit both arms and cancel out. Pre and post comparisons cannot separate real lift from seasonality, which is exactly why Botsi does not rely on them.

For transparency you get the holdout definition, the measurement window, and a dashboard that reports the model arm against the baseline arm side by side with the split size and the statistical confidence, plus scheduled data exports so your own analysts can check the underlying transactions.

The honest cost of doing it this way: a true holdout means deliberately leaving a control slice un-optimized, so you forgo some revenue there to earn a trustworthy number, and reaching significance takes time and volume. A holdout-measured result is more conservative than a flattering pre and post read, and that is the point.

If your team wants a couple of static price tests, RevenueCat Experiments and Superwall targeting can do that, and a strong data science team could build rule-based tests and static cohorts over a few quarters. We will concede that openly.

What Botsi adds is a per-app machine learning model that predicts individual lifetime value and continuously selects the right paywall, offer, and price for each user, with a maintained holdout and compliance guardrails around it. Botsi is the decision layer that sits on top of your paywall renderer, not a replacement for it, so nothing you already pay for gets thrown away and nothing gets migrated.

The honest line: a team that only wants a static test or two does not need Botsi, and an in-house build can approach some of the lift given quarters of effort. Botsi's edge is time to value, continuous per-user decisioning, and compliance that stays maintained instead of bolted on.

Botsi aims to increase both conversions and revenue, so typically our clients see no impact to paid marketing, or a positive impact. Botsi optimizes for higher ARPU and LTV, which gives your paid marketing campaigns a higher-quality signal, and more of it, to optimize against.

Botsi learns from live traffic rather than a large historical archive, so what matters is a steady flow of paywall impressions and purchases, not years of stored data. There is a genuine minimum volume below which a per-user model will not beat a single well-chosen price. Apps with an established subscription funnel and steady paywall traffic are generally in range, and we will tell you where you sit before you integrate rather than sign you up to prove a point.

And because the guarantee means you do not pay without measurable revenue improvement, you are not funding the learning curve with subscription fees, though you do spend setup time.