How Pliero calculates its results
Every number on your results page comes from a statistical model, not a spreadsheet pivot. Here's exactly what that means and why it matters.
Why the authorization rates are “model-adjusted”
When you see Off-session: 78.2% vs On-session: 92.5%, those are not raw counts from your data. They are the authorization rates predicted by the model, holding all other factors constant.
Here's why that matters. Suppose your off-session payments are concentrated in Germany, and Germany happens to be a harder market for your card mix. A raw rate would combine both effects: “off-session payments authorize less, and also German issuers are stricter today.” The model separates them. The off-session rate we show is the effect of being off-session specifically — net of country, card brand, amount range, and every other dimension in the model.
Technically: for each payment in your dataset, the model predicts an authorization probability given its full feature vector. The focal rate is the average predicted probability for payments in that segment. The reference rate is where those same payments would land if you switched the focal variable to its reference value, leaving everything else unchanged. This is the Average Marginal Effect (AME) approach — standard in applied econometrics.
What is the reference segment?
Each finding compares one segment against a reference. The reference is always the most common level for that dimension in your data — not an industry benchmark. All comparisons are internal to your own payment history.
For example: if 70% of your payments are on-session, then on-session becomes the reference for session type. Off-session, the focal segment, is compared against that reference. If your on-session rate is 92%, an off-session rate of 78% means something real — it can't be explained by “on-session just happens to have better cards.” The model has already accounted for that.
What does confidence mean?
Confidence reflects how statistically certain we are that the gap is real and not random variation in your data.
| Level | What it means |
|---|---|
| High confidence | p < 0.01 and at least 100 payments in the segment. Very unlikely to be noise. |
| Moderate confidence | p < 0.05 and at least 100 payments. Statistically significant — worth acting on. |
| Limited confidence | Below those thresholds. The gap may be real but we don't have enough data to be sure. |
The p-value is a Wald test on the model coefficient for that segment. A p-value of 0.01 means there's a 1% chance you'd see a gap this large or larger if nothing was actually wrong. We only surface findings with p < 0.05 — no arbitrary effect-size thresholds on top.
How the monthly impact estimate works
The estimate answers: “if this segment authorized at the reference rate, how much more revenue would pass through each month?”
All three inputs come from your data directly. The rates are model-adjusted as described above. The average transaction value is the mean amount (in EUR) for payments in that segment. The result is extrapolated to a monthly figure based on the time range in your export.
This is a lower-bound estimate. It assumes the only change is fixing the specific issue — no improvement to other dimensions. In practice, some fixes (like enabling network tokenization) improve multiple dimensions at once.
What model does Pliero use?
Pliero fits a single logistic regression model on your payment data using Iteratively Reweighted Least Squares (IRLS). The outcome variable is whether each payment was authorized. Every available dimension — session type, 3DS outcome, card brand, card country, funding type, recurring flag — enters the model simultaneously.
Using one model for all dimensions means each finding is isolated. A country finding reflects the country effect net of the card brand distribution in that country. A 3DS finding reflects authentication friction net of the session type mix. There is no double-counting.
The model requires at least 100 payments per segment level to include that level in the analysis. Segments with fewer payments are excluded rather than shown with unreliable estimates. If the model detects complete separation (a segment with 0% or 100% authorization rate), the Wald test is suppressed for that segment and it is shown as a descriptive observation only.
What happens to my data?
Your CSV is uploaded directly to an encrypted private store. It is used only to run the analysis and is not shared with any third party. Uploaded files are automatically deleted after 30 days.
The analysis results (aggregated statistics and model outputs) are stored in your account so you can revisit them. No raw transaction data is retained beyond the 30-day window.
Security
Your payment data is sensitive. Here is exactly how Pliero handles it.
Encrypted storage, private access
Uploaded files are stored in a private, encrypted blob store. They are never publicly accessible. Only the analysis pipeline can read them, and only with a server-side credential that is never exposed to your browser.
Your data is isolated
Every query Pliero runs against its database is scoped to your account. There is no way to retrieve another merchant's data through the application. We do not pool or compare data across merchants — your analysis is entirely self-referential.
No third-party data sharing
Your transaction data is never sent to any third party, used to train models, or shared in any form. The only external service that handles your data is the encrypted blob store used for upload transit — it receives the raw CSV and nothing else.
Automatic deletion
Raw uploaded files are automatically deleted after 30 days. After deletion, only the aggregated analysis results (the statistical outputs, not your transaction records) remain in your account for reference.
Custom analysis and implementation support
Pliero's self-serve tool covers the most common authorization leakage patterns. Some situations benefit from deeper work — a more granular model, a bespoke segmentation, or hands-on help implementing a fix with your payment provider or engineering team.
We work directly with merchants on:
- →Custom model runs on your full transaction history — no volume cap, finer segmentation
- →Routing and retry strategy review — evaluating your current logic against the data
- →Stripe configuration audit — 3DS settings, network tokens, card updater, off-session setup
- →Implementation support — working through findings with your payment provider or dev team
- →Before/after measurement design — defining the right evaluation window and success criteria
If you're interested, email hello@pliero.com with a brief description of what you're trying to solve. We'll respond within one business day.