FAQ
How Botsi works, what integration really costs you, how the lift is measured, and what your legal and security reviewers will ask. Answered straight, including the tradeoffs that are real.
What Botsi does at the paywall, how the model learns your app, and why it stays inside Apple and Google's rules.
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.
Botsi trains a custom AI model on your app's own data, so it learns your users rather than an industry average. At the decision point you pass Botsi metadata and behavioral signals tied to your own user ID, and Botsi returns the paywall, offer, and price point to show that person. The model optimizes for predicted lifetime value rather than raw conversion count, and it keeps learning and adjusting continuously, so you are not running a manual test cycle every quarter. Decisions are driven by behavior and context, never by demographic data.
Botsi uses only the data you send it. It is an API: you pass metadata and behavioral signals tied to your own user ID, and Botsi returns the price, paywall, or offer decision. Botsi does not scrape, does not buy third-party data, and does not need personally identifiable information to work. It also does not use demographic or special-category data such as age, gender, or race, so decisions rest on behavior and context.
All data travels over HTTPS with TLS and is encrypted at rest with AES-256, only necessary metadata is sent, and Botsi never receives cardholder data.
How much work integration really is, and what happens to the paywall stack you already run.
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.
No. Keep the paywall builder you already use, whether that is RevenueCat, Superwall, Adapty, or something your own team built, and let Botsi decide which paywall, offer, and price each user sees. Nothing about how your paywalls are designed, localized, or shipped has to change.
Botsi does include its own paywall builder with a visual editor, templates, localization, and remote JSON configuration if you ever want one, but adopting it is optional and not part of getting the pricing model live.
Yes, and it integrates seamlessly. There is a documented path for exactly this:
Get Paywall for the predictionSwiftUI or Jetpack Compose paywall from the returned dataStoreKit or Google Play Billing and validate it with BotsiSee 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.
Yes, seamlessly. Botsi has a server-side REST API built for web checkout pages, landing pages, and web funnels, and it supports app-to-web checkout through Stripe, where your app shows the Botsi-selected offer and Stripe takes the payment on your site. Your server holds the secret key and makes the calls, so the key never reaches the browser.
Botsi decides on web surfaces through the same API, so your pricing logic stays in one system instead of splitting in two. Step-by-step guides live in the docs under AI Pricing Web API and App-to-Web with Stripe.
Yes, seamlessly. Botsi selects the right offer for each user across the whole journey, including:
Each of those is another decision point you hand to the model, and each draws from offers you configured in App Store Connect or Google Play Console first, so nothing shown to a user sits outside what the stores already approved. You are not limited to optimizing the first paywall a user ever sees.
Botsi gives you a dashboard that shows the AI model arm against your baseline arm side by side:
Underneath that sit the standard analytics pages covering metrics, LTV, cohorts, funnels, retention, conversion, and revenue net of store commission and tax, plus scheduled data exports so your own analysts can check Botsi's reporting against your own numbers. The point is to let you audit Botsi's work rather than take a headline number on faith, so you can see where the lift is coming from and which offers are producing it.
Why per-user beats A/B, how the lift is measured, what happens on day one, and what results really look like.
A/B testing answers a different question than the one that makes you money. A price test finds the single price that performs best across your whole audience, which means it optimizes for a user who does not exist: the average of everyone. Your real users are not the average. Some would have paid more and received a discount they never needed. Others churned at a price they were never going to accept. A winning variant is one number applied to both groups, so a test has no way to tell them apart.
Botsi decides per user instead of per audience. The model predicts what each individual is likely to be worth over their lifetime and picks from the paywalls and price points you already approved, so users with high willingness to pay see a stronger offer while marginal users see the offer that actually converts them. It also never stops. A price test gives you one answer that begins decaying the moment your traffic mix, markets, or campaigns change, whereas the model re-learns continuously without anyone scheduling the next test.
The two are not in conflict. What you learned from your price tests tells you which price points belong in the catalog, and Botsi decides which of them each user sees. To be clear, Botsi runs A/B tests too, including A/B testing in the dashboard and the test that measures Botsi's own model against your baseline paywalls. What does not scale is using a test to crown one price for everyone. Testing is how you prove a change, and per-user decisioning is how you serve it.
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.
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.
Botsi starts optimizing on day one rather than sitting through a training period, and the AI models begin learning from day one. Before there is enough individual signal, the model decides at the segment level using the behavioral and contextual signals available at that moment, then graduates to per-user decisioning as each user's history builds. Brand-new users are handled the same way and for the same reason: a first-session visitor gets a decision based on context rather than personal history. The practical effect is sensible decisions immediately and sharper ones as data accumulates.
Headline lift is 30%+, and LTV lift compounds from there:
Most customers see measurable uplift inside the first 30 days. Look at the shape of that curve rather than a single number, because the shape is the honest picture: the gain builds as the model accumulates data on your users. And if an app does not see measurable improvement, the Risk-Free Performance Guarantee means the subscription is on us, so a result below the range costs you nothing. When we share results with you, they come with the sample size and the full spread, not just the winners.
What Botsi costs, why the fee is fixed rather than a cut of your revenue, and exactly what the guarantee does.
Botsi prices in fixed brackets. The published Pro tier starts at $399 a month and Enterprise is quoted directly, so you know your cost before you start and it does not move with your revenue. On top of that sits the Risk-Free Performance Guarantee, as the pricing page puts it: if Botsi's AI doesn't drive measurable revenue improvement, your subscription is on us.
Because the fee is a fixed number, the ROI math is trivial to run rather than something you have to audit. Most clients see 30x ROI within three months, and you can verify that against your own revenue without reconciling a percentage against gross bookings, store commission, refunds, and tax.
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.
The guarantee is the whole hook, so it deserves the detail rather than a slogan. The principle is simple: if Botsi does not drive measurable revenue improvement, your subscription is on us.
The specifics worth putting in writing before you sign:
holdout rather than a favorable internal readWe will also say plainly what it does not cover: it covers your subscription fee, not your team's integration time, opportunity cost, or reputational risk. We will put the measurement window, the threshold, and who adjudicates in the agreement rather than leave procurement to discover them at renewal.
How Botsi sits on top of the tools you already run, and the guardrails that keep you in charge of ARPU.
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.
Two systems assigning the same users can absolutely poison each other's reads, so the assignment layer has to be coordinated deliberately. There are a few clean ways to coexist:
Practically, Botsi's own experiments are scoped to a Placement, and every paywall decision comes back tagged with its placementId and an isExperiment flag, so it is always visible which surface Botsi is assigning on and which users sit in an experiment. Use that to draw the boundary: Botsi owns randomization on the placements you hand it, and your tool owns the rest.
What we recommend against is running overlapping price or paywall tests on the same traffic while Botsi is optimizing it, because neither result stays clean. Decide who owns experimentation on that surface before launch rather than after.
Autonomous does not mean unaccountable, and since you answer for ARPU, you keep the controls. The model only ever selects from prices and paywalls you have defined and approved, so it cannot introduce an option you did not sanction. On top of that you can:
You own the option set and the bounds, and Botsi chooses within them.
To be straight about the shape of that control: it is real but indirect, meaning you approve the set and the guardrails rather than hand-steer a price for one individual in real time. Hand-tuning each user's price is not the use case. If you need campaign-level pinning on top of that, ask us to walk through exactly what is available today.
The paywall is your highest-intent moment, so the decision call is built to be fast and, more importantly, safe when it is not. The call typically returns in about 40 ms and can take up to two seconds when the model is working harder, which is why the integration does not put it on the render path. You fetch the decision early in the user journey, right after the profile is created, and cache it, so by the time the paywall renders the answer is already in hand and nothing blocks the screen.
If Botsi is ever slow or unreachable, the paywall falls back to the Baseline Paywall you configured on the model, so a failure degrades to exactly today's behavior instead of a lost sale. Botsi is an added dependency on a critical surface and we will not pretend otherwise. The mitigation is prefetch plus a configured fallback, so the worst case is a user seeing your standard paywall rather than a blocked or blank one.
What your legal, privacy, and security reviewers need before they greenlight.
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.
Botsi is GDPR compliant and built to keep your side of it simple. Botsi processes only the signals you send, excludes demographic and special-category data entirely, and acts as a processor on your instructions, which keeps the data footprint deliberately small. Behavioral signals tied to a user ID are still personal data under GDPR even though Botsi never touches special-category data, so the framework applies and we do not wave that away.
Because predicting a user's value and selecting their price is automated processing, the Article 22 analysis, the lawful basis, the DPIA, and the user-facing disclosure sit with you as the controller, including the EU personalized-pricing notice under the Omnibus Directive. That is how the controller and processor roles work for any vendor in this position. Botsi supports that as your processor and will put the processing terms your counsel needs in writing, including a DPA and processing records, and the compliance rules are enforced in the model itself rather than left to a policy document.
Some US state laws also grant a right to opt out of profiling for significant decisions, and the setup can honor that. Excluding demographic data lowers the sensitivity rather than removing GDPR scope, and the compliant path is straightforward disclosure, which app publishers handle routinely.
Start with what is solid: Botsi excludes age, gender, race, and other protected-class data outright, which removes the most obvious form of discrimination and materially lowers risk, and bounding the approved price range caps how far any single decision can move. Device-level signals such as device type, OS version, platform, and session context are used, and country is part of the profile payload. What is never used is location applied as a demographic proxy, or any demographic attribute.
We will not overstate it beyond that. No amount of input exclusion mathematically guarantees zero disparate impact, because signals like device and location can correlate with income. So we would rather audit realized outcomes than declare the inputs clean, which means monitoring realized prices for adverse impact instead of assuming exclusion settles the question.
On explainability, you can see which paywall and price each decision selected and review outcomes at the segment level, which is genuinely useful for review and is not the same as a human-readable rule for every individual, so ask us for the exact logging and attribution available on your plan. A brand-new user with no history is exactly when a decision is least personalized and leans most on coarse signals. We would rather describe that accurately than claim a proxy-free guarantee or full white-box interpretability.
Compliance built in is not a slogan, it is how the models are constructed. Botsi bakes the regulatory rules directly into the model and its inputs: no demographic or special-category data, and pricing only inside ranges you approve, so a large share of the compliance work is carried by the product rather than left on your desk. Botsi is also GDPR compliant and SOC 2 compliant.
Alongside that, you remain the data controller and the party that creates and approves the price points, while Apple or Google act as merchant of record for in-app purchases and Stripe or your chosen provider does for web. That split is simply how app-store selling works for every vendor in this category.
The standard agreement is standard SaaS terms, and where you need an enterprise arrangement such as a signed DPA, a compliance warranty, a customer-facing indemnity, or a higher liability cap, that is a conversation we have on enterprise terms. The built-in guardrails genuinely reduce your burden, and the contract specifics are something we put in writing rather than gloss over.
PCI first. Botsi never receives cardholder data, because purchases complete through StoreKit, Play Billing, or Stripe and Botsi only ever sees non-card transaction metadata, so Botsi sits outside PCI scope. Your assessor will want to confirm that for your specific Stripe or web checkout path, and we will walk them through the flow.
On the rest, all data is transmitted over HTTPS with TLS and encrypted at rest with AES-256, the connection uses secret-key authentication, employee access follows a least-privilege model with every access event logged and subject to audit, and Botsi runs on infrastructure that meets SOC 2 Type II and ISO 27001 standards. Botsi acts as a processor on your data and aligns its practices with GDPR and CCPA.
For a full vendor-security review your procurement team will want:
We hand over what exists rather than imply a complete packet. EU or US data residency is available on Enterprise, and we will confirm exactly what that covers for your users and on which plan rather than give a mixed answer.
The questions a sharp buyer, and the public, will press on. We answer them straight, because doing so is a trust asset rather than a risk.
Charging different users different prices for a digital consumer subscription is broadly lawful in most markets today, and navigating that is our job, not yours. The classic US price-discrimination statutes, like Robinson-Patman, target competing resellers of physical goods, not consumer digital services.
Botsi carries the compliance work so your team does not have to. The rules live in the model itself: it runs only inside price ranges you approve, it excludes protected-class data, and the guardrails move as the legislation moves. You get personalized pricing without standing up a compliance program to run it.
This is also why doing it through a specialist is the safer path. What regulators struggle with is a fragmented landscape of companies each improvising their own approach. A purpose-built layer that operates inside a consistent framework, with documented guardrails and an auditable record of why each user saw the price they saw, is exactly the shape of thing that does not attract scrutiny. Your app stops being a novel question and starts being a well-understood one.
Building this yourself is not a feature, it is two permanent teams. You would own an ongoing data science effort to keep the model accurate, and an ongoing compliance effort to track evolving regulation across every market you sell in. Botsi absorbs both.
The honest part: personalized pricing is under active FTC and multi-state attention, the rules vary by jurisdiction, and you remain the seller of record. This is not legal advice and there is no regulatory all-clear for anyone in this space. Confirm legality with your own counsel for the markets you sell in, and Botsi will support that review with the guardrails and documentation it needs.
Any form of personalization can be screenshotted, and we will not pretend otherwise. What makes it defensible is how the spread is structured. Variation stays inside ranges you approve, and it works best as discounts and intro offers measured off a common public anchor rather than premiums charged above it. Decisions are driven by behavior, not identity, and promotional, regional, and cohort pricing is already routine on the App Store. Because you set the range, you control the spread, and therefore the blast radius.
We cannot promise a screenshot never goes viral, and reputational risk is real and sits outside the revenue guarantee. Our job is to keep the variation bounded and the logic explainable, so you can show the range you approved and the behavioral basis for the decision rather than pointing at a black box.
Botsi optimizes predicted lifetime value and net revenue, not raw conversion count. That distinction is the whole answer: the model raises price where it sees low price sensitivity and leans on discounts mainly for marginal users who would not otherwise convert, so it aims at non-converters rather than your existing full-price payers.
The credibility anchor is measurement. Results settle against a concurrent holdout on net revenue, so any discounts given away are already netted out of the reported number, and a positive result is net of what was discounted.
We will also be direct about the tradeoff: some would-be full-price payers can see a lower price, and average revenue per payer can dip even when total revenue and LTV rise. The promise is net-positive in aggregate versus control. It is never zero cannibalization.
Botsi is a live optimization service, so switching it off returns you to static pricing and the ongoing lift stops with it. We would rather be precise than reassuring here. Our position is that:
We will not promise an exportable, self-running model that does not exist, and we will spell out exactly what travels with you on exit in the agreement rather than leave it to interpretation.
The honest summary is that continuous optimization is a service you subscribe to, and a portion of the lift is genuinely tied to keeping it on. The flip side is that no percentage of your revenue rides on it, so the decision to renew is a straight comparison of one fixed fee against measured lift.
Bring your hardest question to a working session. You will talk through the real numbers, the holdout, and the guarantee with the founders, not a sales script.