> ## Documentation Index
> Fetch the complete documentation index at: https://docs.regasolutions.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Statistics
> Read your shop's figures: what the radar spotted, what you bought, what it cost, at what hours it happens — and what Vinted itself says about your orders.
This is your shop in figures: what the radar spotted, what you bought, what it cost, at what hours it all happens — and, in a second tab, what Vinted itself says about your orders, account by account.
**This screen has two halves, and they do not tell the same story.**
**Monitor** is what *the tool* measured: detections, purchases, spending, speed. **Accounts** is what *Vinted* answers when asked about your orders. Both show a “success rate”, and **it is not the same rate** — see “What surprises people”.
***
## What you are looking at
| # | Control | What it does |
| -- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| 1 | The account indicator, top right | Names the account that will pay. Its tooltip: “compte\_demo will pay for the next purchase — ready to buy.” |
| 2 | The bell | Your notifications. Here: “3 unread notifications”. |
| 3 | **Administration** | REGA staff only — this button does not appear on your account. |
| 4 | The **AUTOBUY** badge, here on **OFF** | Arms or disarms automatic buying. Tooltip: “Automatic buying disarmed”. |
| 5 | The **rega** logo | Back to home. |
| 6 | The **Monitor** tab | The “measured by the tool” half. Tooltip: “Detections, purchases and spending measured by the tool.” |
| 7 | The **Accounts** tab | The “read from Vinted” half. Tooltip: “Orders read from Vinted, account by account. This half queries real accounts.” |
| 8 | **Refresh** | Reads the figures again. While reading, it says “Reading…”. |
| 9 | The left-hand navigation | Dashboard, Filters, Accounts, Orders, Watchlist, Sales, Statistics, Settings. |
| 10 | **24 h** | Period preset. Its tooltip gives the computed bounds: “14 Aug 02:55 to 15 Aug 02:55”. |
| 11 | **7 days** | The preset active in the screenshot: “8 Aug 02:55 to 15 Aug 02:55”. |
| 12 | **30 days** | “16 Jul 02:55 to 15 Aug 02:55”. Then come **90 days**, **12 months** and **Custom**. |
**The AUTOBUY badge (4) is not a setting of this page: it arms our servers.** Once armed, automatic buying survives closing the tab, closing the browser, and shutting down your machine. **The only thing that stops it is disarming it.**
Top left, the state of the radar: **RADAR ACTIVE**, **RADAR PAUSED** (as in the screenshot) or **RADAR UNREACHABLE**. A paused radar explains, on its own, a screen with no detections — no need to look any further into the statistics.
***
## The two halves — and what each one costs
This is the one mechanism to understand before using the screen.
**What it is**: the log REGA keeps for you, on its servers.
**What it reads**: your filters' detections, your purchases, your spending, how fast each purchase went, plus two counters coming from the Sales and Watchlist screens.
**What it costs**: nothing. Vinted is never queried.
**So**: change the period as often as you like, compare, experiment. It is free and instant.
**Its limit**: the log only knows **your filters**. No filter, no statistics.
**What it is**: a real read of your orders at Vinted, account by account.
**What it reads**: your orders as Vinted describes them — their state, their item price, their date — then, right at the bottom, the public profile of every connected account.
**What it costs**: round trips to Vinted. The tooltip on the long periods says so: “Long period: the first read may take several round trips to Vinted.”
**So**: pick your period **before** clicking, and let the read finish.
**Its limit**: the read stops at **60 pages per account**, roughly **1,200 orders**.
```mermaid theme={null}
flowchart TD
U(["You open Statistics"]) --> T{"Which tab ?"}
T -->|"Monitor — the default"| L["The log REGA keeps"]
L --> LC["Local, instant read
Change the period as often as you like"]
T -->|"Accounts"| V["A real read at Vinted"]
V --> V1["Your orders, page by page,
account by account — kept
in memory ~3 minutes"]
V --> V2["The profile of every connected account,
read again EVERY time you open the tab"]
V1 --> VC["Widening the period costs
Shortening it costs nothing"]
V2 --> VC
```
**Pick your tab and stay on it.** REGA never returns to “Accounts” on its own: the tab is not remembered, the screen always reopens on **Monitor**. That is deliberate — remembering “Accounts” would fire a burst of real reads simply because you opened the page. To refresh, use the **Refresh** button of the tab you are on, never the tab switch.
***
## Choosing the period (Monitor tab)
Six choices: **24 h**, **7 days**, **30 days**, **90 days**, **12 months**, **Custom**. Hover a preset before clicking: its tooltip shows the exact bounds it will set, for example “8 Aug 02:55 to 15 Aug 02:55”.
It says three things, in order: the period retained (“**Period** 8 Aug 02:55 to 15 Aug 02:55”), the sample read (`{n} events read`, or “sample size unknown”), and the step (“hourly step” / “daily step”, followed by “(automatic)” as long as you have not forced it).
**This is the line that tells you whether the figures are worth reading.** “0 events read” and a fine table of “—” say the same thing: there was nothing to measure.
**Hour** or **Day**. Left alone, the step switches to the day on its own beyond **14 days** of period. That is almost always the right choice.
The **Refresh** button reads everything again. On a preset, it **slides the window up to now**; on a **Custom** period, it reloads without moving your bounds.
“Custom” opens two date-and-time fields (“Start of the period”, “End of the period”). **You cannot go below 60 seconds of gap**: if you push one bound towards the other, the opposite bound is pushed back **silently**. No message is shown — it is the only thing this screen does without saying so.
“Custom” is also the only mode where **Refresh** does not move the window: it is what you want in order to read exactly the same slice again after an incident.
Clicking **Day** forces it. **Clicking Day again hands control back to the automatic setting.** The only clue to the current state is the word “(automatic)” at the end of the bounds line: if it is there, you have forced nothing.
For a fraction of a second on opening, the bar shows “Working out the period…”. The bounds depend on **your** local time: they can only be set once the page is open at your end. Then comes “Reading the log…”.
The plot is capped at **2,200 steps**. Concretely: **90 days at the hourly step is 2,160 steps and goes through whole**; **12 months at the hourly step would be 8,760**, and the plot stops at about **91.6 days**.
You will only ever see this if you **forced** the “Hour” step yourself — left alone, it switches to the day at **14 days**. The banner says so and gives you the fix: “**Shortened timeline.** At the hourly step, only the start of the interval is drawn; the totals, however, cover the whole period. Switch to the daily step to see the whole timeline.”
***
## The nine summary tiles
Every tile is built the same way, and **the third line matters as much as the second**:
| The line | What it carries | Example |
| -------- | ------------------------------------------------ | ---------------------------------------------------------------- |
| Label | What is measured | **PURCHASE SPEED** |
| Value | The figure — or “—” if it was **not** measured | the median duration of a purchase, in seconds |
| Sub-line | **What the figure covers**, or why there is none | `typically · 9 times out of 10 under {p90} · over {n} purchases` |
| Tile | What it measures | What its tooltip says |
| ------------------------ | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **SPEND** | The total actually charged | “Purchases actually charged, plus spending outside the item itself. Simulations are excluded.” |
| **AVERAGE BASKET** | The average of the charged purchases | “Average of the charged purchases. Spending outside the item is not included.” |
| **SUCCESSFUL PURCHASES** | Purchases that reached a confirmed charge | “A purchase is only “successful” once the charge is confirmed — never on a payment still under way.” |
| **SUCCESS RATE** | Successful over completed | “Successful ÷ (successful + failed). Purchases cancelled before payment count in neither.” |
| **FAILURES** | Purchases lost, and their top reason (`top reason: {motif}`) | — |
| **DETECTIONS** | Listings spotted by your filters, with their pace (`≈ {n} per hour`) | — |
| **PURCHASE SPEED** | The median duration of a purchase, in seconds | “How long a purchase takes, from the first step to the payment, excluding bank confirmation. Simulations are excluded.” |
| **SALES OBSERVED** | Tracked items whose sale is proven | “Items tracked by the Sales page whose sale is PROVEN by Vinted's marker: an item that simply vanished does not count.” |
| **WATCHLIST ADDITIONS** | Items put under watch during the period | “Items put under watch during the period. The total, however, is not bounded by the period.” |
**“—” is not “0”.** A dash means *not measured*; a zero would mean *measured, and equal to zero*. The sub-line always tells you which: “no paid purchase in the period”, “no purchase timed”, “no counter for this period”, “sales tracking unavailable”… **Never replace a “—” with a zero in your spreadsheet**: you would turn a missing measurement into a fact.
It takes two forms. `out of {n} started` counts your purchase starts. `out of {n} completed · starts not counted` appears when the starts cannot be tied to your filters: the screen then refuses to print a false denominator, and tells you instead of dressing it up.
Either way, **the figure to read is SUCCESS RATE**, never the gap between the two numbers.
If you run dry tests, the sub-line adds ` · including {n} in simulation`.
`typically · 9 times out of 10 under {p90} · over {n} purchases`. The first figure is the usual case; the second — “9 times out of 10 under…” — is the one that counts, because it describes your **bad** days, and bad days are when an item is lost.
Bank confirmation is **outside** this measurement: the tile times the tool, not your bank.
The tile only shows the **top** reason, as `top reason: {motif}`. The labels come from a table written from failures actually observed. The most frequent ones:
* “Un autre acheteur a payé en premier” — another buyer paid first; lost in the race.
* “L'article était déjà parti” — the item was already gone when we tried.
* “Vinted vérifiait encore l'annonce” — Vinted was still checking the listing; it was not buyable yet. That is a postponement, not a failure.
* “Ce compte n'était plus connecté” — this account was no longer connected; fix it on the **Accounts** screen.
* “La validation bancaire n'a pas été faite à temps” — the bank confirmation was not completed in time; you were the one being waited for.
**The first two cannot be fixed**: they say the market was faster. The last three can.
These labels are written by the server in French and are not translated yet. They read the same way on an English interface.
Euros and pounds are not added together. The large value is **the euro only**; the rest is listed in the sub-line, as `{n} purchases · plus {autres} (currencies not converted)`.
The sub-line gives `≈ {n} per hour`. That is the figure to compare from one week to the next: the raw total depends on how long the period is, the pace does not. If the pace collapses while your filters have not changed, look first at the radar state, top left.
***
## The four blocks below the summary
Three metrics, in this order: **Detections · Purchases · Spend**. The context gives the step count — in the screenshot, `169 hourly steps · total 0`. Hovering a point gives the detail: the step label, the value, then ` · {n} purchases` and ` · {n} failures`.
When the metric shown is **not** “Purchases”, a legend appears: “The mark below the baseline shows the steps that carried a purchase.” It is the fastest way to see **at what hours a purchase actually landed** while looking at your detections.
Empty: `No {metrique} recorded in this period.`
Two bands: **HOUR OF THE DAY** (24 cells) and **DAY OF THE WEEK** (7 cells, **M** to **S** — the week starts on Monday). The same three metrics as above.
The peak is circled and annotated: `peak at {h}:00 — {v}`, `peak on {j} — {v}`. Below the bands: “less … more”, then “local time · the circled cell is the peak”.
To the left of the title, the sample: `over {n} days observed` or `over {n} h observed`. **Always read the peak together with its sample** — a “peak at 21:00” over 24 h of observation is one evening, not a rhythm. Count at least two or three weeks before turning it into a habit.
Columns **GROUP · FILTERS · DETECTIONS · PURCHASES · SHARE**. Filters that no group contains fall into a reserved bucket, **“Ungrouped”**.
Note shown below the table: “ “Ungrouped” gathers the filters that no group contains. A filter placed in two groups counts in each: the shares can add up to more than 100%.”
If no group exists: “No group is defined and no detection is tied to a filter in this period. Groups are created from the Filters screen.” If it is refused: “The groups could not be read (`{erreur}`).”, or its fallback “Groups unavailable.”
**BUSIEST FILTERS** — columns **FILTER · DETECTIONS · PURCHASES · SHARE**, note: “An item detected by two filters is counted once per filter: the shares can therefore add up to more than 100%.” A filter deleted since then drops out of the ranking; if nothing is left: “The `{n}` filters for this period have been deleted since.” Empty: “No detection tied to a filter in this period.”
**SPEND BY BRAND** — columns **BRAND · TOTAL · PURCHASES · AVERAGE · SHARE**, note: “Simulated purchases are excluded. “(inconnue)” is not a brand: it is a brand that was not read in time.” Empty: “No purchase charged in this period.”
Both tables show only **8 rows**; beyond that, a `Show all {n} rows` ↔ “Collapse” button appears.
***
## The log footer
Below the blocks, a discreet line says what state **the measurement itself** is in. It is the only part of the screen that talks about its own reliability.
| What is shown | What it means |
| ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
| `Log — {n} events recorded` | The total volume the tool holds. |
| `{n} detections not written yet` | Detections counted but not filed yet. They are **already** in the totals above. |
| `{n} measurements dropped so as not to delay a purchase — the totals are understated by as much` | The tool chose to lose a line of statistics rather than slow a purchase down. |
| “nothing has been logged yet” | Empty log. |
| “Log status unavailable — the figures above may be incomplete.” | The state of the measurement is unknown. |
The “measurements dropped” line is a **deliberate trade-off**: the log queue is capped at **20,000** entries, and when it overflows, the purchase comes before the statistic. On a healthy installation this counter stays at **0**. **If it climbs, stop comparing two periods** — one of them is truncated, and you would read a drop that never happened.
***
## The Accounts tab
This half does not use the log: it queries real Vinted accounts and hands you back what Vinted answers.
The **ACCOUNTS** selector offers three sections: **SCOPE** (“Active account”, “All accounts”), **GROUPS**, and **ONE ACCOUNT**. Its help text is unambiguous: “This choice only concerns **reading**: it changes neither the account that pays nor the rotation.”
An account that is out of service is marked in the list: `{nom} — not connected: nothing can be read`.
**24 hours · 7 days · 30 days · 90 days · 12 months · All**. The last two carry a warning tooltip: “Long period: the first read may take several round trips to Vinted.”
While reading, the button says “Reading…” and a veil, “Reading the orders at Vinted…”, covers the figures. **Clicking another period during that time is ignored**, even though the tooltip says “Reading — the period will change as soon as it is done.” You will have to **click again** once the read is over.
### The seven figures
| Figure | What it counts | What its tooltip says |
| ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Spend** | The item price of **every** order | “Sum of the ITEM PRICES of every order, whatever its state. Postage and buyer protection are not included.” |
| **Confirmed spend** | Completed orders only | “COMPLETED orders only: those still under way can fail or be cancelled.” |
| **Success rate** | Completed over concluded | “Completed ÷ concluded. An order still under way does not enter the denominator.” |
| **Average basket** | The average item price; sub-line `{m} on the completed ones` | “Average of the item prices, across all orders.” |
| **Orders** | The total, “all states together” | — |
| **Completed** | Concluded orders, with `{n} still under way` | — |
| **Cancellations** | Cancelled orders **and** payments that did not go through | “Vinted groups REFUNDED and FAILED under a single state: this figure also covers payments that did not go through. The sub-line isolates those requested from rega — a cancellation made from the Vinted app does not appear there.” |
**These amounts are item prices, not what you paid.** Postage and buyer protection are not in them. Gap measured at our end, on our own orders: an item at **€1.00** cost **€1.75** in total, another at **€1** cost **€4.74**. Count on the order of **+€3 to +€4 per order**, and get the real cost from the **Orders** screen. **Do not build your margin on the “Spend” figure of this tab.**
### The chart, the comparison, and the honesty footer
* **“Spend and completed orders”**: bars are spending, the line is completed orders, and the note says it — **“independent scales”**. So never read a crossing of the two as an event. Empty: “No dated order in this period.”
* **“Account comparison”** only appears **from two accounts onwards**. Bars are scaled to the **biggest spender**: a full bar means “the most”, never “a lot”. Each row details `{n} orders`, `{n} completed`, its rate, and where applicable ` · history truncated`.
* **The honesty footer** states what is missing rather than rounding it away: `History truncated: the totals cover {n} pages read, not the whole history.`, `{n} orders with no readable date: counted in the totals, absent from the chart.`, `Not read: {liste}`.
The read stops at **60 pages per account**, roughly **1,200 orders**. Beyond that, the “History truncated” line appears — and it also appears **per account** in the comparison. A truncated account and a complete one cannot be compared: one has a ceiling, the other does not.
### The VINTED ACCOUNTS table
Right at the bottom, a **live** read, with no period: columns **ACCOUNT · VINTED RATING · ITEMS FOR SALE · FOLLOWERS**, context `{n} accounts connected · live`.
Its note holds for the whole page: “ “—” marks a value Vinted did not return, never a zero.”
Empty: “No account connected. Connect one from the Accounts screen.” If it is refused: “The account list could not be read (`{erreur}`).”, and per row “This account could not be read.” in the tooltip of the dash.
This table **never** shows an email address: the Vinted username, failing that an account number, failing that “username unknown”.
***
## The states of the screen
| State | What you see |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **On opening** | “Working out the period…”, then “Reading the log…” |
| **Reloading** | The previous figures stay on screen, **greyed out**, and the button says “Reading…” |
| **Empty log** | Banner “**No event in this period.** The blocks below show their structure with absent values — these are not zeros.” |
| **Partial read** | Banner “**Incomplete reading.** The figures shown are those of the last successful load — they do not necessarily cover the selected period.” The rest of the screen survives. |
| **Timeline cut** | Banner “**Shortened timeline.** At the hourly step, only the start of the interval is drawn; the totals, however, cover the whole period. Switch to the daily step to see the whole timeline.” |
| **Nothing readable** | “No statistic could be read.” |
| **Service unreachable** | “The service is temporarily unreachable. Check your connection, then retry.” |
| **Accounts — waiting** | “Reading the orders…”, then on reload the veil “Reading the orders at Vinted…” |
| **Accounts — empty** | “**No order in this period**” + “Widen the period, or change accounts.” — or “Some accounts could not be read — see below.” |
| **Accounts — refused** | “**These statistics could not be read**”, the reason, and a “Retry” button. |
```mermaid theme={null}
flowchart TD
A(["A tile shows a figure ?"]) --> B{"Has the log been read ?"}
B -->|"no"| E1["No statistic could be read."]
B -->|"partly"| E2["Incomplete reading banner
Previous figures stay, greyed out"]
B -->|"yes"| C{"Are there events
in the period ?"}
C -->|"no"| E3["No event in this period banner
The blocks show their structure — not zeros"]
C -->|"yes"| D{"Was the value MEASURED ?"}
D -->|"no"| E4["A dash, and the reason in the sub-line
e.g. no purchase timed"]
D -->|"yes"| E5["The figure, and its sample
e.g. out of 64 completed"]
E5 --> F{"Measurements dropped
in the log footer ?"}
F -->|"yes"| G["Totals UNDERSTATED — measurements were
sacrificed so as not to delay a purchase"]
F -->|"no"| H["Complete total"]
```
***
## Actually using it: where to start
This screen answers four questions, and each one has **one** entry point. Do not sweep the page top to bottom: start from your question.
```mermaid theme={null}
flowchart TD
Q(["What do you want to know ?"]) --> Q1["How much I spent"]
Q --> Q2["Why I keep missing items"]
Q --> Q3["When I need to be available"]
Q --> Q4["Which filter deserves my time"]
Q1 --> R1["Accounts tab
Spend + Confirmed spend
then the Orders screen for the REAL cost"]
Q2 --> R2["Monitor tab
SUCCESS RATE + the FAILURES reason
then PURCHASE SPEED"]
Q3 --> R3["Monitor tab
RHYTHMS, together with its sample"]
Q4 --> R4["Monitor tab
BUSIEST FILTERS
DETECTIONS vs PURCHASES columns"]
```
1. **Monitor**, **7 days** period. Read the bounds line: how many events were read?
2. **DETECTIONS**: has the pace, `≈ {n} per hour`, moved since last week?
3. **SUCCESS RATE** and the **FAILURES** reason. If the reason is “Un autre acheteur a payé en premier”, you are in a race, not in a breakdown.
4. **BUSIEST FILTERS**: spot the filters with plenty of **DETECTIONS** and zero **PURCHASES**.
5. Log footer: is the dropped-measurements counter still at 0?
Write the figures down somewhere: **the screen does not compare two periods**, keeping the series is up to you.
1. **Monitor**, **30 days** period, **Purchases** metric in **TIMELINE**: are purchases spread out, or bunched onto a few days?
2. Switch the metric back to **Detections**: the mark below the baseline shows the steps that carried a purchase. Long stretches of detections **without** a mark point at the hours you are missing.
3. **RHYTHMS**: do those hours match your peak? If they do, that is when automatic buying needs to be armed.
4. **PURCHASE SPEED**: if the “9 times out of 10 under…” figure is high, time is lost inside the purchase itself; if it is low, the race is what you lose, not the machinery.
5. **FAILURES**: the reason settles it between “lost in the race” and “fixable at your end”.
1. **Accounts**, scope **All accounts**, the longest period you care about — then narrow down, never the other way round.
2. Read **Confirmed spend**, not **Spend**: orders still under way can fail or be cancelled.
3. Look at the **honesty footer**: “History truncated”, “orders with no readable date”, “Not read: …”. A total sitting on a truncated history is not a total.
4. Mentally add **+€3 to +€4 per order** — or get the real cost from **Orders**.
5. **Cancellations**: read only the sub-line `including {n} requested from rega`. The big figure mixes cancellations with payments that did not go through.
***
## Our advice
**1 — Create a filter before coming here for figures.** Statistics are bounded to **your** filters: no filter, no statistics — and that is correct, not a breakdown. It is also what guarantees that no other customer will ever see a single one of your figures.
**2 — On Accounts: start wide, then narrow down.** Shortening a period asks Vinted for nothing again — the orders already read stay in memory for about **3 minutes** — whereas widening does. “90 days” then “7 days” costs one read; the other way round costs two.
**3 — Do not bounce between the two tabs.** Every return to **Accounts** fires a live read **per connected account**: it is the only part of the screen that is never kept in memory. Nervous tab-switching queries your accounts for nothing.
**4 — Read SUCCESS RATE, never the “started minus successful” subtraction.** When the sub-line says `out of {n} completed · starts not counted`, the denominator is not comparable — the screen flags it instead of hiding it. The rate itself stays correct.
**5 — One failure in two cannot be fixed, and the reason tells you so.** Recorded at our end, on our own purchases, on 31 July: **78 purchase attempts**, **34 successful**, **42 real failures** — of which **25 (59.5%)** were lost in the race (item already gone, or another buyer got there first) and **11 (26.2%)** were down to the tool. **Before changing anything in your settings, read the reason**: half the failures cannot be fixed by any setting; they are fixed by being there earlier — or by arming automatic buying.
**6 — If your purchases “feel slow”, look at PURCHASE SPEED before writing to support.** This tile stops at the payment, **bank confirmation excluded**. If it is low and your purchases still drag, the wait is at your bank. The figure to quote in a support message is the “9 times out of 10 under…” one, never a general impression.
**7 — Before deleting a productive filter, write its figures down — or disable it instead.** Deleting wipes its **BUSIEST FILTERS** row for good; a disabled filter keeps its past. It is the only irreversible action this screen is subject to.
**8 — Hunt down the “plenty of DETECTIONS, zero PURCHASES” filters.** They are the ones filling your feed without converting anything. Two ways out: tighten the filter in **Filters** (brand, price, condition), or accept that it is there to watch the market and file it in a separate group so you stop confusing it with your buying filters.
**9 — Use RHYTHMS to decide on your availability, not to describe your week.** The cells are in **local time**, and the peak only means something with its sample (`over {n} days observed`). Once the peak is identified, that is when a manual purchase is worth the most — and above all, that is when automatic buying needs to be armed already, since it runs on our servers even while you sleep.
**10 — If the “Shortened timeline” banner appears, click “Day”.** It can only appear if you forced the **Hour** step on a long period. And only the *chart* is cut: **the totals stay complete**.
**11 — Watch the log footer like a warning light.** As long as it shows no “measurements dropped”, your totals are complete. As soon as it does, stop comparing periods with each other: one of them is truncated, and the “drop” you would read never happened.
**12 — For a real cost, leave this screen.** The “Spend” of the Accounts tab is item prices. The **Orders** screen carries what you actually paid, postage and buyer protection included.
***
## What surprises people
That is correct. An item detected by two filters is counted **once per filter**, and a filter placed in two groups counts **in each**. Both tables say so underneath themselves.
The **groups** are read once, when the screen opens; only the **counters** follow the window. If you have just created a group in **Filters**, reload the page to see it appear here.
A simulation charged nothing: it enters **SUCCESSFUL PURCHASES** (the sub-line says so, ` · including {n} in simulation`) and stays out of **SPEND**, **AVERAGE BASKET** and **SPEND BY BRAND**. So a flattering success rate can be a dry-test rate — check the sub-line.
On **Monitor**, it is *successful ÷ (successful + failed)* over **our purchase attempts**. On **Accounts**, it is *completed ÷ concluded* over **the state of your orders at Vinted** — an order paid for but later cancelled by the seller weighs there, while it was a success on the Monitor side. They can diverge sharply without either being wrong, and no text on the screen puts them side by side.
The tile only counts sales **proven** by Vinted's marker. An item that simply vanished from the marketplace does not enter it: it may have been withdrawn, hidden or edited, and nobody can claim it was sold.
The value is bounded by the period; the sub-line `{n} tracked in total` is not. It is written in its tooltip, and it is intended: the total is a state, an addition is an event.
It is not a brand: it is a brand that was not read in time. The label is written as such by the server and is not translated — which is why the table's note quotes it verbatim.
Neither on Monitor nor on Accounts. That is deliberate: the Accounts half queries real Vinted accounts, and nobody wants a page left open to keep querying them all day. Click **Refresh**.
When a denominator cannot be established, **SUCCESSFUL PURCHASES** switches to `out of {n} completed · starts not counted` rather than writing “out of 0 started”. A screen that shows an odd figure rather than a false one is doing exactly its job.
***
## On a phone
* **The row of periods SCROLLS, it is not cut off.** At 390 px it measures **576 px** for **366 px** visible: “12 months” and “Custom” are to the right, the **STEP** selector at the far end. Swipe it with your finger.
* **The “Statistics” title disappears below 900 px** — on purpose. The fixed header used to cost **336 px** on an 844 px-tall window, i.e. **40%** of the screen; it is now around **200 px**.
* **The nine tiles move to two columns**, in the same order.
* **Navigation moves to the bottom**: **Feed · Filters · Orders · Tracked · More**. Statistics is reached through **More**.
* On a small screen, tiles and the log footer stay comfortable to read; the five-column tables (brands, groups) are happier on a large screen.
***
## What this screen does not do yet
Said plainly, so you do not go looking for it:
* **No export** — no CSV, no image, no clipboard. If you track a series, copy the figures out.
* **No period-over-period comparison**: no “vs last week”, no trend arrow.
* **Only one failure reason is shown** (`top reason: {motif}`); the full ranking of causes exists but is not displayed here.
* **The time between a detection and a confirmed purchase is measured, but not shown yet.**
* **Two sentences in the Accounts footer, and the failure reasons, are written by the server in French** — they stay in French even when the interface is in English.
* **The layout has only been checked at 390 px and on a large screen**; intermediate widths (tablet) are still to be verified.
***
## Where to go next
Tighten a filter that detects a lot and buys nothing, and create the groups that feed the “Detections by filter group” table.
The real cost of an order, postage and buyer protection included — the one the Accounts tab does not carry.
Reconnect an account marked “not connected: nothing can be read”, and prepare a carrier.
The purchase ceiling, the automatic pick-up point, and the settings that decide what these figures will become.