Trust & Safety in Personalized Offers

Responsible Personalization

Botsi picks the offer and paywall each user of a subscription app sees, from options the app team approves. Showing different users different offers raises fair questions: what data drives the choice, who sets the limits, and who checks the result. This page answers them.

01

What Botsi Personalizes

An offer is everything the user is asked to agree to: the plan, its price point, the trial, any discount, and when it appears. The paywall is the screen that presents it. Each app team builds a set of offers and paywalls in advance. For each user, Botsi’s offer model picks one from that set.

Botsi is not a dynamic pricing engine. Airlines and ride-share apps compute a new price for each moment; Botsi never computes a price. It cannot show an offer the app team did not build, and it does not create App Store or Google Play offers. Introductory offers, promotional offers and offer codes stay Apple and Google objects that the team sets up.

Botsi chooses among offers the app team approved. It never generates, computes, or adjusts a price.

02

Will Users See Different Prices?

Sometimes, yes. If the app team includes an annual plan, a monthly plan and a 50% first-year discount in its offer set, two users can see different prices, because they see different offers. A user who gets a free trial and a user who gets a discounted first year also pay different amounts in their first year.

What does not happen: a user seeing a price the team did not set. Every price point in every offer is one the app team chose and entered in the App Store, Google Play, Stripe or Paddle. Teams that want everyone to pay the same price can keep one price point and let Botsi personalize only the plan, trial, timing and paywall design.

Charging different users different prices for a digital subscription is lawful in most markets, and the rules vary by jurisdiction. The Botsi FAQ covers the legal and brand questions in detail.

03

Compliance as Infrastructure

The rules on personal data in automated decisions vary by jurisdiction and keep tightening. Using personal data such as age, gender, race, nationality, or location applied as a demographic proxy to decide what a person is offered is prohibited or materially restricted in a growing number of markets.

The European Union’s General Data Protection Regulation restricts the use of personal data in automated decision-making that materially affects individuals. The California Consumer Privacy Act gives consumers rights over how businesses collect and use their personal information, including in automated decision-making. Canada’s Personal Information Protection and Electronic Documents Act, Australia’s Privacy Act, and Brazil’s Lei Geral de Proteção de Dados impose analogous constraints.

Botsi builds these requirements into how the offer model operates and updates them as legislation changes, so app teams do not track each market’s rules on their own. Botsi is SOC 2 Type II compliant.

04

What Drives the Choice, and What Does Not

Botsi decides from device-level, behavioral and interaction data: how a user engages with the paywall, their session patterns, their in-app behavior. These signals reflect engagement and intent. Botsi never receives demographic data, and the exclusion is part of the architecture, not a setting a product manager can switch off.

Data CategoryExamplesBotsi’s Use
PII / DemographicAge, gender, race, nationality, inferred income, location as demographic proxyNever Used
Device-LevelDevice type, OS version, platform, session contextUsed
BehavioralPaywall interactions, session frequency, in-app engagement patterns, feature usageUsed
InteractionTime-on-screen, scroll depth, paywall return visits, CTA engagementUsed

Behavioral data reflects what a user does in a product. Demographic data reflects who they are. Botsi chooses offers on engagement, not identity.

05

Limits the App Team Sets

A revenue-maximizing system with no limits will push hardest on the users who show the most intent. Botsi works inside limits the app team sets: which offers exist, which price points they carry, which segments to exclude, and an off-switch that returns every user to the team’s current paywall.

Every deployment runs against a randomized holdout that keeps seeing the current paywall. App teams see every offer, how often each one is shown, and what it earned, so an offer that hurts renewals or refunds shows up in the numbers and can be pulled.

The app team decides what can be offered. Botsi decides which of those offers each user sees, and a holdout shows whether it worked.

06

Why One Offer for Everyone Fails

Across app categories, between 1 and 4 percent of downloads convert to paying subscribers. Many of the people who engage and never pay found value in the product. The single offer they were shown did not fit them at that moment: the price was too high, the commitment too long, or the trial too short.

1–4%Average download-to-paid conversion rate across subscription app categories
96%+Of downloads that never convert to a paid subscription
↑ LTVWhen subscribers are on an offer that fits them, rather than one they tolerate

Matching each user to an offer that fits grows the paying population. A user who would never commit to a year may take a monthly plan. A user who is unsure may take a longer trial. Subscribers who chose an offer that fits renew at rates that reflect real satisfaction, and the app earns more from a broader base instead of squeezing a small one.

Botsi’s Personalization Commitments

The rules that govern every offer Botsi chooses.

No PII. Ever.

Offer decisions use only device-level and behavioral data. Age, gender, race, nationality, and any derived demographic attribute are excluded from Botsi's decision signals by architecture, not policy.

Client-Set Offers and Prices

Every offer a user can see, and every price point in it, is one the app team built and approved. Botsi chooses among them. It never generates a price.

No Protected Attributes

Botsi cannot access or infer demographic identity, so it cannot choose offers on protected attributes. That removes the most direct forms of discriminatory targeting.

Full Client Visibility

App teams see every offer, how often each one is shown, and every outcome against the holdout. Botsi is transparent infrastructure, not a black box.

Outcome Monitoring

Every deployment is measured against a randomized holdout, and teams can exclude segments or switch Botsi off at any time.

Compliance Built In

Botsi is SOC 2 Type II compliant. Requirements from GDPR, CCPA, PIPEDA, and other frameworks are built into how the offer model operates, not bolted on afterward.