What this site tracks, what it never touches, and why.
Everything BMoney Visual Maker does — decoding your beat, rendering the disc, encoding the MP4 or GIF — happens locally in your browser tab, on your own device. There is no server behind this site that your beat, your artwork, or your exported file is ever uploaded to. Closing the tab or losing your connection doesn't interrupt anything server-side, because nothing server-side is involved.
This site uses PostHog, a third-party analytics service, to understand basic usage: how many people visit, which templates get picked, whether exports start and finish, and whether a download was attempted. Specifically, the events sent are:
page_view — that a visit happened, plus the referring page.template_selected — which of the three CD templates was picked.export_button_click, export_started, export_completed, export_cancelled, export_failed — that an export was attempted and how it ended, including format (MP4/GIF), resolution, duration, and file size. A failed export sends only a coarse category (for example capability or timeout) — never the raw error text, which can sometimes contain filenames.download_button_click, download_initiated, and (only when the browser itself confirms it) download_confirmed — see the note below on what "confirmed" actually means.None of these events include the contents of your beat or artwork, their filenames, or anything else that could identify what you made. That's a deliberate design constraint in the code, not just a policy — the analytics layer is only ever given pre-approved event names and coarse properties like a template ID, a resolution, or a duration in milliseconds.
When you click Download, your browser triggers its own, standard download — the same mechanism as clicking a download link anywhere else on the web. That's a fire-and-forget action: once it's handed to your browser, this site has no way to know whether the file actually finished writing to your disk, was cancelled by you, or was blocked by your browser or antivirus software.
So the download_initiated event only means a download was requested — not that it succeeded. The separate download_confirmed event is sent only in the rare case where the download mechanism itself reports back a confirmed "saved" status; for an ordinary browser download, that confirmation usually never arrives, and that's expected, not a bug.
If the site owner hasn't configured a PostHog project key, none of this runs at all — no network requests are made, nothing is tracked. You can check this yourself: open your browser's network tab and look for requests to i.posthog.com.
PostHog is used here under a public, write-only project key — the kind meant to be embedded in client-side code. It can only send events in; it can't read anything back out of your browser, and it's not the kind of key that grants account access.
Questions about this? You can reach the site owner at the contact listed wherever you found this link.