Privacy notice

Who's responsible for your data

Marketool is built and run by Michael Shreeves, acting as an individual rather than through a company, who is the data controller for the information described here. Contact hello@mashreeves.com for anything to do with privacy, data rights, or accessibility - that's the single contact address for the whole service.

What's collected, and why

• Account details - your organisation's name, the email address of each person with an account, their role (admin or staff), and a securely hashed password (never the password itself). Used to run your account and let you sign in.
• Failed sign-in attempts - a running count of wrong passwords on your account, and the time of the lock if it was locked. Five wrong passwords, or five wrong codes from your authenticator app, lock the account for 30 minutes and we email you; the lock is also written to the audit record (your account's ID, never your password). The count resets when you sign in or reset your password. The lock time is kept until the next sign-in attempt after the lock has ended. Used to stop other people guessing your password.
• Staff invitations - when an admin invites a colleague, we store the colleague's email address and the role they're invited to, and email them a link to set up their account. The link works once and stops working after 7 days or if the admin cancels it; we keep only a scrambled form of it, never the link itself. The invitation record is erased 30 days after it's used, cancelled or expires. If an admin removes someone, that person can no longer sign in straight away; their account is kept for 30 days so it can be reinstated, then erased automatically.
• Your branding - the logo files, brand colours and the phone number, email address and website an admin enters to be printed on banners. Logos are stored on our own server and deleted with your account. Inside the app they're shown only to your own organisation; each logo also has a public web address that can't be guessed, so that email signatures made here can show it to the people you email.
• Email signatures - the name, job title and numbers you type into the signature builder stay in your browser and are never sent to us.
• Scheduled posts - when you schedule a post, we store its caption, platform and time, who planned it, and - for a banner - the banner image itself (normally a banner never leaves your browser; scheduling is the exception, so the reminder can link to it). At the time, we email a reminder to whoever planned it. The image is deleted 30 days after the post is marked done or its time has passed, and the rest 90 days after its date. If you choose to have Marketool publish a post to Facebook or Instagram, we also keep the id Meta gives the published post and a link to it, so it can be deleted there too, and Meta's reason if it couldn't be published. If an admin turns on auto-share, Marketool makes the same kind of post itself for each new listing in your feed, from the listing's own details, and keeps it unposted until an admin approves it; your admins get an email when there are posts to approve. When the feed marks a listing sold or let, Marketool adds a line saying so to the Facebook posts it published for it, and a comment to the Instagram ones.
• Your Facebook and Instagram connection - if an admin connects your organisation's own Meta app in Settings, we keep its App ID, its App Secret (encrypted), and the Facebook Page and Instagram account it publishes to, with the Page's access key (encrypted) and who connected it and when. We also keep the Facebook sign-in access key of the admin who connected it (encrypted) and when Meta says it runs out, about 60 days later, because Instagram lets a post be deleted or commented on only with that key, and your admins get an email a week before it runs out. It is deleted once that admin leaves your organisation. These are deleted when an admin removes them, or with the rest of your organisation's data. While an admin is choosing which Page to connect, their Facebook sign-in and the list of Pages they manage are held, encrypted, in their session for up to 15 minutes, then forgotten.
• Two-factor authentication - required for admins, optional for staff. When you set up an authenticator app, the shared secret this creates is stored so codes can be checked at sign-in. If you choose to add a passkey instead of, or alongside, an authenticator app, the public key it creates is stored the same way - a public key on its own can't be used to sign in as you anywhere else, and nothing about your fingerprint, face or device PIN ever reaches us.
• Signing in with Microsoft - if you choose "Continue with Microsoft", Microsoft confirms who you are and tells us your email address, your name (used only to pre-fill a new agency's sign-up form, not stored), whether you used multi-factor authentication, and two identifiers for your Microsoft account and your organisation's Microsoft directory. We store those two identifiers on your account so the next Microsoft sign-in finds you; they're cleared when your account is erased. Your Microsoft password never reaches us.
• Your agency's own Microsoft sign-in - if an admin sets one up under Settings, we store your organisation's Microsoft directory ID, its app registration's ID and secret (encrypted), the email domains it covers, and, if they turn on group sync, the group's ID and name. Group sync reads the members of that one group from Microsoft each night to add and remove staff; a change it makes is recorded in the audit log.
• Your listings feed - if you connect one, the property details and photos it contains (addresses, prices, features) are imported so you can build banners and videos from them. This comes from your own supplier feed, which you control. If you connect a BLM file over FTP, we also store the FTP server name, username and folder you enter, and the password (encrypted, and never shown back to you). These are used only to collect your listings file, and are deleted with your account.
• What you enter for a slideshow video - its address, price and feature text, and any photo or audio file you upload for it. Uploaded photos and audio are deleted again once that video finishes rendering. The text we suggest for a music generator is built from your own listing details and is not stored - except that, if your organisation uses its own ElevenLabs key, the lyrics and voice you choose are saved with that video so its music can be made. A finished video, and the details saved with it, are kept until the person who made it or an administrator deletes it, or until your organisation's data is deleted. The banner builder is different: it runs entirely in your browser, so a banner's text and photo are never sent to us - unless you choose "Schedule it" (see "Scheduled posts" above).
• Your font choice - if you pick a font under Appearance in your account menu, that choice is saved with your account so it follows you to any device, and is deleted with your account.
• An audit log of admin actions - feed changes and imports, branding changes, adding or removing an ElevenLabs key (never the key itself), connecting or disconnecting Facebook and Instagram (never the secret or access key), deleting videos and posts, posts published or failing to publish, and staff invitations, removals and reinstatements are recorded with who did it, when, and from what IP address, kept even if the account that did it is later deleted. This is a security and accountability record, not used for anything else.
• Ordinary technical data - your session cookie (keeps you signed in); a small cookie called lb_theme remembering your light, dark or high-contrast theme choice; and one called lb_shell remembering whether you've narrowed the side menu to icons, and a copy of your font choice so pages you see signed out in the same browser use it too. Both last a year, hold no personal information, and are set only once you make a choice. If you tick "Keep me signed in on this device" when you sign in, there's one more: a cookie called REMEMBERME that keeps you signed in on that device for up to 30 days. It isn't set unless you tick the box, and it's strictly necessary for the thing you asked for, so it doesn't need separate consent. Once you've ticked it and completed two-factor authentication, that device won't ask for a code again until the cookie runs out. None of these cookies is used for tracking or analytics, and there's no advertising script anywhere on the site.
• Usage statistics - every page loads Matomo, an analytics tool I host myself at analytics.mashreeves.com, on the same server in Manchester, UK that runs my other services. It records which pages are viewed, the page you came from, your browser and device type, a rough location (country or region, worked out from your IP address) and when. Your IP address is shortened before it's stored, with the last two parts removed (81.2.x.x, say), so the full address is never kept. It sets no cookie, so there's nothing to consent to and no banner. The lawful basis is legitimate interests: I want to understand how the service is used so I can improve it. None of this goes to another company.

Third parties involved

Three companies are involved in running the service itself:

• Vultr hosts it. The application, its database and uploaded files are on a Vultr server in Vultr's Manchester, UK data centre.
• Cloudflare sits in front of every request to the site and handles its DNS and HTTPS, so it sees your IP address, your browser and the page you asked for. It's a US company and processes this under its standard data processing terms.
• Microsoft 365 delivers the emails the service sends, such as password resets. The service hands each email to a mail server on its own hosting, which passes it to Microsoft 365 to deliver, so Microsoft sees the recipient's email address and what the email says. Microsoft holds this email in the United Kingdom.
• Brevo is kept as a fallback email provider. It handles no email day to day, and would relay the same emails only if the Microsoft 365 route failed and I switched to it. Brevo is a French company and processes data in the EU, which the UK recognises as giving adequate protection.

And if you generate a slideshow video with music, the listing's town and postcode and your chosen mood are sent to Mubert, a third-party text-to-music API, to generate a short jingle. This only happens when Mubert is configured and you ask for a video with music; nothing else about your account or listings is shared with it.

If your organisation adds its own ElevenLabs key in Settings, a video's lyrics, the mood, voice and length you chose, and any description of the music you typed are sent to ElevenLabs to make its jingle - using your organisation's own ElevenLabs account, under your organisation's own agreement with them. Lyrics are built from the listing's town and postcode, price and features, and you can edit them first; we don't send anything about your customers. The key is stored encrypted and is deleted with the rest of your organisation's data.

If your organisation connects its own Meta app and chooses to have a post published automatically, the banner or video and the caption you wrote are sent to Meta (Facebook and Instagram) at the time you chose, through your organisation's own app and under your organisation's own agreement with Meta. A banner is sent as a JPEG through a private link that works for an hour. Once published, the post is on Facebook or Instagram under Meta's own terms and privacy policy.

If you sign in with Microsoft, Microsoft handles that sign-in under its own terms and privacy policy, and your sign-in to Marketool is recorded in your organisation's Microsoft sign-in logs. We send Microsoft only the email address you type, to open the right sign-in page.

Beyond these, no other third party receives your data - the usage statistics above stay on my own server, and property photos are composed into videos on our own server using local software (FFmpeg/GD), not an external image or video service.

The one-click demo

Trying the demo from the sign-in page doesn't collect anything about you. You choose to be an administrator or a standard user, and each is a shared, passwordless account in Larkmoor Homes, a made-up agency whose listings, addresses and contact details are all invented. Nothing you do in the demo is saved.

How long things are kept

You can delete your own account at any time from the account menu. For the first 30 days this is reversible - signing back in offers a one-click restore, in case it was done in error or you change your mind. After 30 days it's permanent and your account is erased automatically. If you were the last person in your organisation, its imported listings, photos, slideshow videos, logos and branding go with it; if colleagues remain, the organisation's shared work stays with them. (The only admin can't delete their account while others remain - another admin has to be added first, so nobody is left unable to manage it.) The one thing that's kept is a record that an admin action happened and when (see "An audit log of admin actions" above). It refers to people by an internal number rather than by name or email address, so it no longer identifies anyone once their account is erased.

Usage statistics work to a separate clock. The individual visit records are deleted after 13 months; after that, only aggregated reports are kept (page counts, that sort of thing), and those don't identify anybody.

Your rights

Under UK GDPR you can ask to see what's held about you, have it corrected, have it erased, object to or restrict how it's used, or ask for a copy in a portable format. Email the address above for any of these. If you're not satisfied with the response, you can complain to the Information Commissioner's Office.

Where this runs

Marketool is live at marketool.mashreeves.com. It runs on a Vultr server in Vultr's Manchester, UK data centre, so your data is held in the UK, with Cloudflare in front of it. Each release is an atomic switch to a freshly built copy, followed by a health check. Vultr's automatic backups cover the server, and a restore, including one to a specific point in time, was tested and confirmed working on 10 September 2026.

Changes to this notice

If what's collected or how it's used changes, this page is updated in the same change that ships the new behaviour - it should always describe what the service actually does, not what it used to do.