Legal
Privacy policy
The analysis runs on your device. We never receive your reports, your trades, or your account details. This page lists every case where anything at all reaches our servers, when, and why.
Who is responsible
Stratlyze is operated by tomventures LLC, Dohlenzelgstrasse 2b, 5210 Windisch, Switzerland. We are the controller for the data described below.
How to reach us
Write to hello@stratlyze.com about anything on this page: what we hold, a correction, a deletion, or withdrawing a consent. The same address reaches us for bugs, and so does the feedback form. There is no ticket system to get through first and a person reads it.
The analyzer: on your device
Stratlyze parses your MT5 backtest reports, reconstructs trades and computes every figure in your browser, or in the desktop app on your machine. Reports, trades, equity curves, price data and portfolios are stored in a local database on your device. There is no server-side analysis at all.
We measured this rather than asserting it. Driving the shipped build through loading a report, every analysis tab, every mode, a PDF export and a reload produced no network request to anywhere except the server the app itself was loaded from. Fonts, code and the SQLite engine are served from our own origin. The analyzer runs no third-party analytics, advertising or tracking script, and it sets exactly one cookie: the light-or-dark theme you picked, described further down.
There are four cases where the analyzer itself reaches a server, and only four. Each is listed below, numbered. Three of them require an action from you; the fourth is the desktop version check. Buying a license and signing in to the customer portal happen outside the analyzer and are covered further down.
1. Usage analytics, off by default
If, and only if, you turn on usage analytics, the app sends anonymous usage events to our own endpoint on hardware we rent: which features and modes you open, coarse error categories, and performance timings. You can turn it on in Settings, and the app also asks you once, inline, after your first report has loaded. It never asks twice. If you say no, or close the question, nothing changes and it does not come back.
The event vocabulary is fixed in code and there is no free-form field, so nothing out of your report can be sent even by accident: not a detail of it, not a symbol, not a filename, not a date, not a figure. That is a statement about the shape of the code, not about our care: every field that carries a word is restricted to a fixed list of our own keys, both in the app and again at the endpoint, and a value outside the list means the whole event is dropped rather than trimmed. Quantities are sent, and they are ours rather than yours: when the event happened, and how long a measured step of the app took. Both are coarsened before they leave, the time to the minute and the duration to one of four bands, because a startup time grows with how much you have saved and we do not want a measurement of that any more than you do. Each is checked against the shape we expect before it is accepted, and a figure out of your report does not have that shape. How many reports you loaded is sent as a size band, never as a count.
A complete event looks like this and contains nothing else: the event name, one fixed key saying which view, button or coarse error category it was, the size band and file extension when a report was loaded, the name and duration of a timing when it was a timing, a random client identifier, a per-session identifier, a timestamp, the app version, your browser’s language setting, your timezone name, and whether you are on web or desktop. Sixteen keys, and that is the whole vocabulary. No name, no email, no license key, no hardware fingerprint, no user-agent string. You do not have to take our word for the list: the app prints one complete event with the real values, plus the payload of every other kind of event it can send, inside the question it asks you and again in Settings, before you decide.
About that client identifier, and when it comes into existence. It is a random id with nothing in it derived from you, your device or your data, and since August 2026 it is created at the moment you say yes and not before. Switching analytics off again deletes it, and if you turn them back on later a fresh id is created, so the two periods are not connected to each other. This is a change: until August 2026 the id was created on every start whether or not you had agreed, which stored something on your device that we had no permission to store, even though nothing was ever sent from it.
One consequence of that, said here rather than left to be discovered. If you installed Stratlyze before August 2026, an id from those builds may still be sitting on your device even though analytics are off, because the fix stopped new ones being created and does not by itself reach back for one that already exists. Nothing was ever sent from it. Settings shows you what is actually on your device right now instead of asking you to trust this paragraph, and pressing Off there removes it. We are not going to write “there is no identifier on your device” as a flat statement when it is true of a new install and was not true of an upgraded one.
This is consent, and you can take it back. Switching it off in Settings stops all sending immediately, in that window and in every other one you have open, with no reload and no confirmation step, and deletes the identifier described above. There is nothing to uninstall and no separate opt-out list. Events already sent stay with us under that random id. They carry no name, no email and no license, and once the id is deleted from your device nothing in them leads back to a person, which is why there is nothing here for you to ask us to do.
What our servers see, stated separately from what we store. The analytics endpoint does not read or record your IP address or your user-agent string; that is a property of its own code, which we wrote and can point at. The web server in front of it still handles the request, and web servers log requests, so the connection itself is visible to us in the ordinary way it would be for any page you load. We are not going to describe that as “no IP address anywhere” when a request had to arrive over a network to get here.
2. License activation
When you activate a license, the app sends your license key and a machine identifier to our license server. The machine identifier is a random id minted once on your device. It is not a hardware fingerprint and is not derived from anything about you or your data. We store it to enforce the device limit on your license and to let you deactivate a device from the customer portal. The server also sees the IP address of the request, as every web server does. No trading data is part of activation. During the beta every feature is unlocked without a key, so most people never trigger this at all.
3. Hosted share links, when you press the button
A hosted share link is the one thing in the analyzer that puts anything of yours on our server, and it is opt-in: it happens only when you ask for it. There is no background sync, no default, and no account that keeps anything in step. You choose it again for every single card, so each link is a separate decision and a separate press of the button.
What is uploaded is the card, and only the card. That is: the rendered image, the headline figures printed on it, a downsampled outline of the equity curve (up to 400 points, in your account currency, so the starting balance is visible in it), the symbol, currency and date range, the basis line, and any note you typed. Your report file, your trade list, your broker and your account credentials are not in the payload, and the server independently rejects anything shaped like more. Nothing is uploaded until you press “Create link”, and closing the dialog uploads nothing.
You can take a share down. Every link comes with a private revoke link, shown to you when you create it, and the app also saves that revoke link on your device alongside the share, so you do not have to keep the one that was shown. Opening the revoke link only asks; it takes a confirmation to remove anything, because chat apps and note apps fetch a saved URL by themselves. When you confirm, the stored image is deleted and the page returns a plain gone response from then on. If you have neither the link nor the device, write to us and we will remove it.
What revoking cannot do, said before you need it. Chat and social apps copy the preview picture onto their own infrastructure the moment a link is pasted, and some of them keep that copy inside messages that were already delivered. We cannot reach those copies and neither can you. Revoking controls one thing: whether the link, when someone clicks it, still opens.
Share pages are never indexed. Every share page carries noindex in its head, the card image is served with the same instruction in its response headers, and no sitemap lists any of them. That is unconditional: not a setting, not a default you could change, and not something a plan alters. Your track record must not become a search result. Link-preview bots are still allowed to fetch the picture, because that is what makes a pasted link show a preview at all, and refusing them would break the feature without hiding anything from a search engine that has already been told not to index the page.
We keep the card while it is being used, and we sweep it when it is not. A share that has never been opened once is deleted after 90 days. A share that has not been opened for 24 months is deleted once it is also at least 24 months old, so nothing is ever removed inside its first two years. A share that people still open is not swept. We also keep a salted one-way hash of the creating connection’s IP address, never the address itself, used only against abuse. Share pages carry a coarse counter of page loads, which includes the link-preview bots that fetch a page when it is pasted. We do not record who views them.
4. The desktop update check
The desktop app fetches one small file from our update server a few seconds after it opens, to see whether a newer version exists. It sends nothing about you or your data: it is a plain download of a public file, so our web server sees the request and its IP address the same way it would if you visited the website. If the check fails the app carries on without a word. The web app does not do this at all, because it loads fresh every time.
On Windows, on macOS and in the Linux AppImage, a newer build is then downloaded in the background and the app asks you before restarting to apply it. That download is our own installer coming to you; nothing about your reports, trades or account goes the other way. The Debian package does not do this and only shows a notice instead.
Purchases
Payments are processed by Lemon Squeezy as Merchant of Record. We never see your card or bank details. After a purchase, Lemon Squeezy sends us your email address and order details (product, order id, status, amount) so we can create your license and email you the key. We also retain the raw order notification they send, which can include the billing name, address and tax details they collected, kept for accounting and to avoid sending the same license twice. Your license key itself is stored only as a cryptographic hash. Invoices and receipts are provided by Lemon Squeezy and their processing is governed by their own privacy policy.
The customer portal
account.stratlyze.com signs you in with your license key and sets one httpOnly session cookie, stratlyze_portal_session, so you stay signed in. It is written only when you sign in, it is what the sign-in is made of, and it is not used for tracking. Signing out removes it. Every cookie our code can put on your device is listed further down, in full. The portal shows your own licenses, orders, device activations and downloads, and nothing else is collected there.
What is stored on your device, and how to clear it
This website writes nothing to your browser storage, and it sets a cookie only when you ask it to. If you choose Light or Dark with the theme control, we store that one word in a cookie named stratlyze_theme, scoped to stratlyze.com and its subdomains so the website, the web app, the account portal and the slippage tool all show you the same theme. It holds one of exactly two words, light or dark, and nothing else: no identifier, no counter, no history, no record of where you have been. It cannot be used to recognise you, and it goes nowhere but back to us with a page request, which is what a cookie is.
There is no cookie banner, and the reason is worth stating rather than assuming. Nothing is stored until you act. Arriving here, reading, and letting the site follow your operating system all leave your browser exactly as they found it. Following your system is the default, and the default stores nothing. The cookie appears only when you press Light or Dark, and pressing it is the request for the thing the cookie does. It then carries that one setting, nothing reads it but the page you are looking at, and it cannot identify you. That is the narrow case the cookie rules treat as a preference set on your own instruction rather than something we decided to place on your device, and we read it as exempt from a consent prompt; a banner asking permission for a setting you had just chosen would be theatre, not consent. If you disagree, the remedy is yours and costs nothing: set the control back to System. Choosing System does not store the word “system”; it deletes the cookie. Everything here works with the cookie blocked or removed, and you simply get your system theme on each visit.
Here is every cookie our code can write, because a list can be checked and a count cannot. stratlyze_theme, above, written only when you pick Light or Dark. stratlyze_portal_session, written only when you sign in at account.stratlyze.com and removed when you sign out. sg, which exists only while the site is behind a private-preview password: if you were given that password and typed it, your browser still holds sg=1 from that visit, and it records nothing except that you got past the door. There is one more in our source and you cannot be given it: stratlyze_analytics signs us in to our own analytics dashboard and is issued only to whoever holds our admin token. That is the whole list. If it is ever wrong, it is a bug in this page and we would like to hear about it.
The analyzer sets that same one cookie and no other. It stores your work in two places in your own browser: an IndexedDB database named stratlyze and a private file-system directory of the same name. Those hold your loaded reports and the data derived from them (strategies, portfolios, brokers, price data, the analysis cache) plus your preferences (language, region format, UI scale, prop-rule templates and your analytics answer). Your theme is kept there too, alongside the cookie, because the desktop app has no cookies at all and needs somewhere to remember it. None of it is transmitted.
The random analytics client id is stored there too. It is created when you say yes and deleted when you say no, so on a default install of this version it does not exist. On a device that ran a build from before August 2026 one may still be there from those builds, which created it on every start; Settings shows you whether yours has one and removes it when you press Off. The same directory also holds a device id used to count license activations, which is created only if you activate a license.
Settings → Data → “Clear all data” deletes the reports and everything derived from them, and deliberately keeps your preferences so the app does not reset its language and theme underneath you. Being a preference, your analytics answer survives it, and so does the analytics id if analytics are on: the switch in Settings is what removes that one, and it removes it straight away. To remove absolutely everything in the web app, clear site data for the domain in your browser; in the desktop app, uninstall it. There is no copy of any of it on our side to delete.
Why we are allowed to hold each of these
Usage analytics rest on your consent, and nothing else. The app asks you once, after your first report, and you can also give or take back the answer in Settings at any time. It asks once and then never again, whichever way you answered, and a declined answer is recorded as an answer so that it stays declined.
License activation and purchase records exist because we cannot give you the thing you bought without them, and because invoices have to be kept. The salted hash of the IP address behind a share link exists so we can act on abuse of a public URL without storing the address itself.
We are not going to claim a retention schedule we do not run, so this lists the one we do. Order and invoice records stay for as long as accounting law requires. A license record stays while the license exists. A share card goes when you revoke it, when you ask us to remove it, or when the sweep described above reaches it: 90 days if it was never opened, or two years unopened once it is also at least two years old. Analytics events keep no IP address and no user agent, and the random client id inside them is never joined to a name, an email or a license. We call that anonymous in ordinary speech and we will not overclaim it here: the id is stable for as long as you leave analytics on, so the events from one installation form a sequence, and a rare combination of timezone name and language setting narrows a sequence more than a common one does. It contains nothing about your trading and nothing that names you, and it is still a record about one installation rather than a bare count. For anything that is tied to you, an order, a license or a share link, ask us to remove it and we will, unless accounting law requires us to keep it. Analytics events are the one thing we cannot act on one by one: once the identifier is deleted from your device, nothing left anywhere tells us which rows were yours. We would rather write that down than accept a request we could not honour.
Where our servers are, and your rights
The few server-side things described above (the license database, the customer portal, share links and the analytics endpoint) run on dedicated hardware in Germany. We do not sell data, we run no advertising, and we share nothing with third parties beyond the payment processor named above.
You can ask us what we hold about you, ask for it to be corrected, or ask for it to be deleted, and you can withdraw the analytics consent at any time in Settings without giving a reason. Write to hello@stratlyze.com and a person will answer. If you think we have handled your data wrongly you can also complain to a supervisory authority: in Switzerland the Federal Data Protection and Information Commissioner, or in the EU the authority where you live.
Changes
Stratlyze is in beta and still changing. If we ever start collecting something new, it will be listed on this page before it ships, and anything that is not strictly necessary will stay off until you switch it on.
Last updated: 12 August 2026. Verified against the shipped build. The usage-analytics section was rewritten on 11 August after a security review of our own code: the promise that a report detail cannot be sent by accident is now enforced by the code rather than by care, the analytics identifier is created only when you agree and deleted when you take that back, and the paragraph about IP addresses now separates what the endpoint stores from what a web server sees. On 12 August, a review of that rewrite found four claims on this page that were still ahead of the code, and all four were corrected rather than defended: what may still be on the device of someone who installed before August 2026, the second number in every event, what we can and cannot delete on request, and how much of the event vocabulary the app actually shows you. Later the same day the deletion promise was withdrawn a second time, because there is no delete endpoint behind it and, once the identifier is off your device, nothing for one to find; and “stops all sending immediately” became true in every open tab rather than only in the one holding the switch. The hosted-sharing section was rewritten on 8 August 2026 to match the retention sweep and the removal routes the code actually runs. On 20 August 2026 this page changed because the product did: the theme you pick is now remembered in a cookie, so that one choice follows you from the website to the app and the portal instead of each of them asking again. The sentences that said we set no cookies went with it. Their first replacement said there were exactly two, which was wrong on the day it was written, so the count is gone for good and what you get instead is the list above, of every cookie our code can write, including the two you will never be given.