Security and data access at Monetisation, read-only by design

The principle, read and never write

Monetisation exists to analyse revenue and recommend changes. It does not need to make those changes itself, so it never asks for the access that would let it. Every connection is read-only. Every change to prices, plans, coupons or content is made by your team, in your own systems.

This keeps the risk simple to reason about. The worst a compromised connection could expose is read access to data you chose to share. It cannot be used to charge a customer, cancel a subscription or alter a price.

How each source connects

Restricted billing keys

Your billing platform lets you create a restricted key and set each permission to none, read or write. Monetisation's setup guide lists the exact read permissions it needs, and nothing else. You create the key in your own account, so you can inspect its permissions and revoke it at any moment. A key with write permissions is not needed and should not be used.

OAuth read scopes

For analytics, CRM and ad platforms, Monetisation requests read scopes through the provider's standard consent screen. You see the scopes before approving. Access can be revoked from the provider's settings or by disconnecting the source in Monetisation.

Product database

If you connect a product database for usage data, create a dedicated database user with read-only rights on the tables you want analysed. Many teams point it at a read replica. If you prefer not to connect a database, upload usage events as CSV.

Encryption

• In transit. All traffic between your browser, Monetisation and connected sources uses TLS.
• At rest. Stored data, including connection credentials, is encrypted at rest. Credentials such as API keys and connection strings are encrypted separately and are never shown again after you save them.

AI and your data

Monetisation uses AI for the opportunity engine and the AI analyst chat. Your data is processed to answer your questions and to build your own revenue model. It is not used to train AI models, ours or anyone else's.

The AI analyst only sees the revenue model of the workspace you are in. It cannot read other workspaces, and other customers' questions cannot reach your data.

Access control inside your workspace

Roles

Seats depend on the plan: 2 on Starter, 5 on Growth and 20 on Scale.

SSO with SAML

On Scale, sign-in can be enforced through your identity provider with SAML. Members join and leave access through your existing directory process, so offboarding happens in one place.

Audit log

On Scale, the audit log records who did what and when: sign-ins, sources connected and disconnected, roles changed, exports, experiments started and settings changed.

Data retention and deletion

• Retention controls. On Scale, you set how long raw imported data is kept. Older raw data is removed on schedule, while aggregated metrics needed for trends can be kept or removed according to your setting.
• Disconnecting a source. Reading stops at once. You choose whether to keep or delete data already imported from it.
• Workspace deletion. An owner can delete the workspace from the settings. The workspace and its data are deleted.
• Account closure. Cancelling a subscription stops billing at the end of the paid period. Deleting the workspace removes the data.

Documents for procurement and legal review

Scale includes the documents a security or legal team usually asks for:

• Data processing agreement (DPA)
• Security review pack, describing access control, encryption, data flows, retention, incident handling and how sub-processors are selected, by category
• Invoices with company details, for finance and procurement records
• 99.9 percent uptime SLA and priority email support

We do not claim certifications such as SOC 2 or ISO 27001. The review pack is written so your team can assess the controls directly against its own questionnaire.

What we ask of you

Security is shared. A few practices on your side keep the setup tight:

• Create the billing key with only the listed read permissions.
• Use a dedicated read-only database user, not an admin login.
• Review team roles when people change jobs, or enforce SSO on Scale.
• Revoke keys and OAuth grants for sources you no longer use.

Questions a security review usually asks

Teams evaluating Monetisation tend to ask the same handful of questions. Short answers:

• Can a Monetisation user see data from another company? No. Each workspace is isolated, and the AI analyst only reads the revenue model of the workspace in use.
• Who inside our company can connect a source? Owners and admins. Analysts and viewers cannot add or change connections.
• What happens if we revoke the billing key? Reading stops at the next refresh. Existing analysis stays until you delete it, and the source shows as disconnected.
• Does the website snippet collect personal data? The snippet used for pricing page and paywall variants on Growth and Scale assigns visitors to a variant or holdout and records conversion events. It does not need names or email addresses.
• Where do sub-processors appear? The security review pack lists sub-processors by category and purpose.
• Can we keep using the product with a narrower set of sources? Yes. Every source is optional. Many teams start with billing data alone and add others later.

Why this matters for the estimates

Read-only access also shapes how Monetisation works. Because it never changes your billing, every experiment based on a billing change is one you make yourself and Monetisation measures. The method behind each number is set out on how estimates work. For what the analysis covers, see pricing optimization software and revenue optimization software.

Questions

Security and privacy questions go to [email protected]. Run a sample audit from the homepage to see the product before connecting any data; the sample reads public pages only. See pricing for what each plan includes.