The small print, in plain words
Privacy Policy
On this page
Marktmorgen (“Marktmorgen,” “we,” “us,” or “our”) is operated by Solrenning, an independent software studio. This Privacy Policy explains how we collect, use, share, and protect personal information when you use our websites and products — the Marktmorgen creator store at marktmorgen.com (the “Services”).
If you have questions about this policy or about your personal data, contact us at support@marktmorgen.com.
1. Information we collect
We collect the following categories of information:
Account information. When you create an account or subscribe, we collect your email address and any other information you choose to provide (such as your name, if requested at checkout).
Payment information. Payments are processed by Stripe, our payment processor. We do not store your full credit or debit card number, CVC, or equivalent payment credentials. Stripe may collect billing name, address, and payment method details as needed to complete the transaction. We may receive limited payment metadata, such as the last four digits of a card, payment status, and subscription period.
What a creator puts in a store. If you run a Marktmorgen store, we host what you put in it: your store name and description, your photo if you add one, the theme and color you choose, your product titles, prices and descriptions, the links you put on the page, and the files you upload for delivery to your buyers. Your photo is shrunk on your own device before it is sent, is shown publicly on your store page and in previews of links to it, and is deleted from our storage when you remove or replace it.
Buyer information. When someone buys from a creator's store, we handle the buyer's email address and the details of that order — what was bought, when, for how much, and whether the file was delivered — so the sale can be completed and the creator can see it. The card details are handled by Stripe and never reach us. That buyer information belongs to the creator, not to us, and section 4 explains what that means.
A confirmation of each purchase. After a buyer pays, we email them one confirmation on the creator's behalf, under the store's name, with what they bought and how to get back to it; replies go to the creator. What it says is read from the payment on the creator's Stripe account. We keep only a mark that it was sent, tied to that checkout, for 40 days, so it is never sent twice. If a creator asks buyers questions at checkout, the answers are kept with the payment on the creator's own Stripe account, shown to the creator, and for a booked call included in the creator's booking email.
A reminder after an unpaid checkout. Only on stores whose creator switched it on, and only for a buyer who agreed on Stripe's own checkout page to hear from that creator: if they leave without paying, we email them once, on the creator's behalf, with a link back to the product. Stripe keeps the address and the answer on the creator's account. We keep a mark that the reminder for that checkout was handled, for two weeks; a one-way hash of the address and the product for a week, so nobody gets two reminders about the same thing; and the link in the reminder that stops them, tied to the address and the store, for 400 days. Pressing it keeps a one-way hash of the address for that store for good, so that store never sends them a reminder again.
A come-back offer. Only on stores whose creator switched it on, and only to somebody who agreed to hear from that creator and has not left their list: some days after a membership ends, we read from the creator's Stripe account when it ended, which product it was and the address it was paid from, and email that address once, on the creator's behalf, with a discount to come back. We keep a mark that the email for that membership was handled, for 90 days; a one-way hash of the address and the product for 180 days, so nobody gets two such emails about the same thing; and the link in the email, tied to the address, the product and the offer, for 14 days. It carries the creator's list's own one-click unsubscribe.
Managing a membership. When a member asks for a link to manage or cancel their membership, we use the email address they type to look for their membership on the creator's own Stripe account and, if there is one, to email them the link. We keep a record that ties that link to their Stripe customer for one hour and, to limit abuse, one-way hashes of the address and of the network address that asked, also for one hour, and nothing else; the page says the same thing whether or not a membership was found. When a member switches their membership to another of the store's plans, the change is made on the creator's Stripe account, which keeps the record of it, and we email the member a receipt and the creator a note with the member's email address and the two plans. We keep nothing more about it.
Getting a purchase again. When a buyer asks a store for what they bought, we use the email address they type to look for their paid purchases on the creator's own Stripe account and, if there are any, to email them a link to a page that lists them. We keep a record that ties that link to the address for 24 hours and, to limit abuse, one-way hashes of the address and of the network address that asked, for one hour, and nothing else; the list itself is read from Stripe each time the page opens, and the page says the same thing whether or not a purchase was found.
Counting visits to a store. When a creator's store page is opened, the page tells us so, with the site that sent the visitor or the campaign word in the link. To count people rather than page loads we make a one-way fingerprint of the day, the store, the visitor's network address and browser, and add it to a counter that keeps only an estimate of how many different fingerprints it has seen. The fingerprint and the address are not stored, no cookie is set, and the daily counts are kept for about thirteen months, with a running all-time total of the same counts for as long as the store exists. The creator sees totals, never a person.
Ad measurement a creator switches on. A creator can add their own Meta, Google, TikTok or Pinterest pixel to their store. When they do, and only once it is allowed, that store's pages load that platform's script, which sets its own cookies and tells the platform about page views, checkouts started, requests for free products and purchases with their amount, on the creator's behalf and under that platform's own privacy policy. Visitors in the European Economic Area, the United Kingdom, Switzerland or Brazil, or whose country we cannot tell, are asked first and nothing loads unless they agree; everywhere else the pixels load unless the browser sends Global Privacy Control. The choice is kept on the visitor's device for that store, and a link at the foot of its pages changes it.
Booking a call. When someone books a paid call, we use the time they picked, their time zone and the email address on their Stripe receipt to hold that time while they pay, to write the booking down, and to send one confirmation to them and one to the creator. So that each can answer the other, the buyer's confirmation has the creator's email address as the address replies go to, and the creator's has the buyer's. While they pay, a cookie in the buyer's browser names the checkout they opened, for 32 minutes, so that going back to pick another time releases the first one. The buyer and the creator are each reminded of the booking a day and an hour before, from a queue that names the booking and its time, and we keep a mark that each reminder was sent for 14 days. If the buyer moves the booking to another time from the link in their email, we keep the new time and how many times it was moved, tied to that checkout, for 200 days. The same kind of cookie, for the same 32 minutes, is set when someone starts to buy a product sold in a limited number, so that pressing buy again hands back the one they were holding.
Payment plans and sales tax. When a buyer chooses a payment plan, Stripe keeps their card on the creator's account for the remaining payments, and we keep the checkout on a list until the plan has been given its end date, so it stops after the last payment. When a creator switches on sales tax, Stripe asks the buyer for the address it needs to work the tax out, under Stripe's own privacy policy; we do not keep it.
Private podcasts. When you get the feed of a private podcast you bought, we keep your email address with a private feed address made for you, so your podcast app can read it. Each time the app reads the feed or fetches an episode, we check that your address still holds the podcast, and we count those reads to stop a feed from being shared; we do not keep which episodes you play. The creator sees neither your feed nor what you listen to.
Packages of sessions. When you buy a package of calls, we keep your email address, which payment it was, how many sessions it holds, its last day to book, and which bookings were made from it, so you can book the rest from the link we email you and see how many are left. A package with a last day to book is kept until a year after that day; one with no time limit is kept for as long as it can be used. Each session is a booking like any other and is kept the same way.
Gifts. When you buy something as a gift, we keep the recipient's email address, the name and the message you typed, and which payment it was, for about 13 months, so the gift can be handed over, shown on their list of purchases and taken back if the payment is refunded. We email the recipient once, with your name, your message and a link to open it; they are not added to the creator's list and receive nothing else from it unless they ask. You get the receipt. What was given is kept under the recipient's address, like a purchase of their own.
Waitlists. When you join the waitlist for something a creator has not put on sale yet, we keep your email address, when you joined and whether you checked the box to hear from the creator otherwise, and we email you a button to confirm it. Once it is confirmed, you get one email when the product goes on sale; then the waitlist's addresses are deleted. Only if you checked the box is your address added to the creator's list, once confirmed. The creator sees how many people are waiting, not who. Unconfirmed sign-ups are kept until the product goes on sale, and a link in every waitlist email removes your address at any time.
Courses. When someone buys a course, we note the email address they paid with and when, so the course opens for them and modules that open over time open on the right day. The browser that paid keeps a cookie for a day so the course can open right away, and any browser let into a course keeps a cookie for 90 days so the student does not have to ask again. For each student we keep when they joined, when they last opened the course and which lessons they marked done; the creator sees this in their studio, and we email the student when a module opens for them. A student taken off a course by its creator is kept on a list so the course stays closed to them. To check who bought a course, we ask the creator's own Stripe account by email address.
Comments under lessons. A student who comments under a lesson chooses a name, and we keep that name, what they wrote and when, until they or the creator delete it or the course is deleted. The creator and the other students of that course see the name and the words; nobody sees the student's email address. When the creator answers a comment, we email the student who wrote it, at most once an hour for each lesson. A creator who asked for it gets a notification on their phone with the lesson and the start of the comment, without the name.
A one-click offer after paying. When a product is followed by a one-click offer, Stripe keeps the buyer's card on the creator's account for payments the buyer makes while present, and a cookie in the buyer's browser, for two hours, lets only that browser take the offer. We keep a record of whether the offer was taken, tied to that order, for eight days.
Free copies, and a creator's list. When you ask a creator's store for something they give away for free, we collect your email address, what you asked for, when, and whether you checked the box saying you want to hear from that creator. The box starts empty. We send you one email, with the link to what you asked for, and nothing else. When you use that link, your address is added to that creator's list, marked with your choice, and the creator can download the list. If you never use the link, the request is deleted after 7 days and your address is not added to anything. To limit abuse, we also keep a one-way hash of your email address, and of your IP address, for one hour.
Emails from a creator. A creator on the Pro plan can email the people on their list who agreed to hear from them: those who checked the box when they got something free or bought, and those the creator imports after confirming that each of them agreed. We send those emails on the creator's behalf, under the creator's name, through our email provider. For each one we use your address, the email the creator wrote and a random code for your unsubscribe link. We do not put tracking pixels or tracked links in them. When you unsubscribe — one press, from the link or your mail app's own button — we record it and when, and you are not written to by that creator again unless you check their box again yourself.
A creator's community. When a creator opens a community on their store, we decide who may come in by looking up the email address a person types on the creator's own Stripe account, on that creator's list for something free, or among the buyers the creator brought over from another platform, and we email that address a link that works for one hour. Using it sets a cookie for that store in their browser for 90 days, the same one a course uses. For each member we keep their email address, the name they choose to be seen by, whether they chose to be listed in the member directory and to be emailed announcements, when they joined and were last there, and whether the creator muted or removed them. We keep what members write: posts, comments, the pictures they add, likes, and reports of a post or comment. Posts, comments, pictures and likes are seen by the other members and by the creator. The directory shows only the chosen name, and only of those who asked to be listed. A member's email address is seen by the creator and never by other members. What is written is kept while the community exists, until its author or the creator deletes it; deleting a post deletes its comments, likes, reports and picture. Who reported something is kept for 90 days, so each member's report counts once. The answer about whether someone may come in is kept for up to five minutes, a record of each announcement emailed and who it went to for up to 60 days, the code in a member's unsubscribe link with their member record, and, to limit abuse, one-way hashes of the address and network address that asked for a link for one hour.
Live events in a community. When a member says they are coming to a creator's live event (an RSVP), we keep that they are coming and when they said so, under a one-way key made from their email address, with the event; giving the place back removes it. The creator and the people on their team see who is coming, with the name and email address the community keeps for each member. Reminders a day and an hour before go only to members who asked for the community's emails; a move or a cancellation is emailed once to everyone coming. For each of those emails we keep a record of it and of who it went to for 30 days, so it is never sent twice. For an event kept for the buyers of some products, the answer to whether a member holds one is looked up on the creator's Stripe account and kept for up to five minutes. An event, with the list of who is coming, is kept until the creator deletes it once it is over or canceled, or until it makes room for a newer one after 500 are kept. When a member presses Join here, the event's video room loads from Jitsi Meet inside the page, with the name they chose in the community filled in as their name in the room, where the others in it see it. A replay is a YouTube, Vimeo or Loom video that loads from that service only when a member presses play, and so does a video on a creator's sales page, when a visitor presses play.
Moving a store from another platform. A creator can bring spreadsheets from another platform. The file is read in their own browser, and we receive only the columns they match: for a list, email address, name, labels and consent; for products, title, price, description and link; for past buyers, email address and product. We keep the rows as they came, which rows were already seen, the report of rows not brought in (each with its row number, column, reason and value), the buyers still to be emailed, and the import's own record (the file's name, who started it and its counts) for 14 days after the import began, and then delete them. Contacts are added to the creator's list only when the creator confirms that the people in the file agreed to hear from them; each is marked as imported, with when, and keeps the name and labels from the file. An address that unsubscribed from that creator is never added back. For each past buyer we keep which products they were given, when and by which import, stored against a one-way hash of their email address, for as long as the store exists; nothing is charged, no receipt is made, and these are never counted as sales. When that person opens the store's list of purchases or its community with that address, we use it to look up what they were given. If the creator checks it, each past buyer gets one email from the store's name, through our email provider, saying what moved and how to open it. We send it on the creator's instruction and on their word that these people bought from them and may be told so, which we cannot check against the other platform. A store may send up to 20,000 of these in 30 days, and for that we keep only a count.
A creator's affiliate program. When someone follows an affiliate's link to a store, a cookie named nl_via_ followed by the store's address holds the affiliate's code and the time of the click, for up to 90 days; a purchase counts for the affiliate only within the window the creator set. Visitors in the European Economic Area, the United Kingdom, Switzerland or Brazil, or whose country we cannot tell, are asked first, because the rules there require consent: the cookie is set only if they allow it, and their answer is kept in their browser for that store. To count a click once per visitor per day we keep a one-way hash of the visitor's network address and browser for two days. When a purchase counts, we note which product, when, what was paid before tax and in all, and the share it earns, and never the buyer's name or email address. Where a creator lets buyers join without applying, a buyer who presses “Get my link” joins with the email address their order was paid with, which we read from the creator's Stripe account for that order. When someone applies to be an affiliate, we keep their email address, the note they wrote, their code, when they applied and what the creator decided, the PayPal address they choose to be paid at, if they give one (we email the address they joined with whenever it changes), their clicks and sales, and the payments the creator records to them with the date and reference the creator types. An affiliate who signs in to their page keeps a cookie named nl_aff_ followed by the store's address, for 30 days. The creator sees all of this; an affiliate sees only their own figures. It is kept with the store's records. We never hold or pay out an affiliate's money: the creator pays them. A creator who pays from their own PayPal through us gives us the Client ID and Secret of an app in their PayPal Business account; we keep the Secret encrypted, never show it again and delete both when they disconnect. Each time they pay, we send PayPal each affiliate's email address, the amount and a note, and PayPal sends the money from the creator's PayPal to the affiliate's, under PayPal's own privacy policy; we keep which PayPal batch and payment paid which affiliate.
Creators inviting creators. A creator's studio gives them an invite link for other creators. Opening it sets nothing. Pressing “Accept the invite” sets a cookie named nl_invite holding the invite's code, for 60 days, and it is removed when a store is made. When the first store of a new account is made with it, we keep which store invited which, and when. To add the credit the invite earns, we read from our own Stripe account the payments the invited account made to us, and keep, for each, the amount credited, its date and whether it is on the plan yet. The inviting creator sees the invited store's public name and address, when it was made, whether it is in its trial, paying or not, and the credit it earned them, and never its email address or what it sells or earns. Kept while either store exists.
Calendars a creator connects. A creator can give us the private iCal address of up to three of their own calendars. We store the address, never show it again once saved, and use it only to read when they are busy; we keep only the busy times, never a title, guest or place, and each reading for up to six hours. The calendar's provider sees our request for it. A creator also gets a private address of their own that lists their upcoming calls and sessions with the name and email address of each buyer, for the calendar app they subscribe with; replacing that address turns the old one off.
Webhooks a creator adds. A creator can give us up to five web addresses of their own, such as a Zapier or Make hook. When a sale, a change to a membership, a confirmed request for something free, a booking, a moved booking or a refund happens in their store, we send that address a message with its details, which can include the buyer's name and email address, the product and the amount. What happens to it there is the creator's choice and responsibility. We keep each address and its signing secret until the creator removes it, a mark of each event sent for 30 days so it is never sent twice, and each delivery, with the answer the address gave, for up to seven days.
License keys. When a creator sells a product with license keys, we keep each key with the sale it went to, when, and the buyer's email address, so the buyer can see it again and the creator can see who has it, and whether the creator revoked it. Anyone can ask whether a key is valid; the answer says nothing about who bought it. Keys are kept with the store's records.
Course quizzes and certificates. For each student and quiz we keep how many tries they used, their last answers, their best mark and whether they passed, with their course progress. A certificate keeps the name exactly as the student typed it, the course title, the creator's name, the student's email address and when it was issued or withdrawn. Its page shows the name, the course, the creator and the date to anyone who has its address, is kept out of search engines, and never shows the email address. Certificates are kept for good, so the page goes on proving what it says; a withdrawn one says it was withdrawn. A student who wants theirs withdrawn asks the creator.
Stamped PDFs. When a creator switches on stamping for a product, every page of the PDF a buyer downloads carries the buyer's email address, the date and the end of the order number. The stamped copy is made by our own code, is kept privately beside the creator's file so a later download gets the same copy, and is deleted with that file; a note of which copy belongs to which sale is kept for about 400 days. Anyone the buyer passes the file to can read that line.
A store's team. A creator can invite up to five people to help run a store. For each invitation we keep the address it went to, the role, when it was made and when it runs out, seven days later; the link in it works once. For each member we keep their sign-in address, their role and when they joined, and, for each person, which stores they are on, so their studio can find them. A store keeps an activity log of its last 500 lines: when, who (their sign-in address), their role and what they did, such as a change they made in the studio, a file they downloaded or a change to the team. The owner sees the team and the log, and is emailed when someone joins or changes role. The team, its invitations and its log are deleted with the store, and a member taken off the team or who leaves is removed from it at once.
Passkeys and new browsers. A creator can add up to ten passkeys to their account. For each we keep only the public half of the key, a counter, the name they gave it, the kinds of connection the device reported, whether it is kept in a synced keychain, and when it was added and last used; the private half never leaves their device. Each is kept until they remove it. Signing in with a passkey sets a cookie named nl_pk for five minutes, for that one sign-in. Every sign-in also sets a cookie named nl_device holding a random code for that browser, for 400 days, and we keep a one-way hash of that code with the account, up to 100 browsers, until 400 days after the account's last sign-in. When an account that has signed in before signs in from a browser it has not used, we email its owner when it happened, how, and the browser and system as the browser names them; we do not keep that description. In the studio, a cookie named nl_store remembers which of an account's stores was last open, for a year.
Email drafts. For each draft of an email to a creator's list we keep its subject, its text, who it is meant for, who last saved it (their sign-in address) and when, until it is sent or deleted, up to 20 per store.
Sending a purchase email again. A creator, an Admin or Support can have a buyer's purchase email sent again; it goes only to the address the buyer paid with, read again from the creator's Stripe account.
An email platform a creator connects. A creator can connect their own Mailchimp, Kit, beehiiv or MailerLite account with an API key. We encrypt the key before it is stored, keep its last four characters to show them, and delete it when they disconnect. When someone who agreed to hear from that creator asks for something free and confirms it, or buys and agreed, we send that platform their email address, their first name when the payment carries a name, and the tags the creator chose, to add them to the audience, form, publication or group the creator picked. Nobody who did not agree is sent, and we then keep no address for them. For each person sent we keep a record of how it went, with their address and first name, for up to a week, the last 50 of them in the creator's studio, and a one-way hash of each person and event for 30 days so nobody is sent twice. What happens on the platform is governed by the creator's own account there and that platform's privacy policy.
Phone notifications. When a creator or someone on their team turns notifications on for a device, we keep what the browser gives us to reach it (its push address and keys), a label such as “iPhone · Safari”, which events it wants, when it was added and whose it is, until it is removed or the browser turns notifications off, with how the last send went. A notification says an amount, a product title or a time, never a buyer's name or email address; it is encrypted for the device and passes through the push service of that browser's maker, such as Apple, Google or Mozilla. We keep a mark of each event sent for 40 days, so it is never sent twice.
Reviews. A buyer can review what they paid for. We check the order on the creator's own Stripe account, and keep the stars, the words, the name the buyer chose to show (or “Verified buyer”), the order reference and the payment it came from, when it was written and changed, whether the creator hid it or answered it, and whether the payment was later refunded. The buyer's email address is not kept with the review and is never shown; the review's code is a one-way hash that includes it, so one buyer has one review per product. The review, with the chosen name, is public on the store; its buyer can change or delete it, and the creator can hide it but not change it. Deleting the product deletes its reviews. If the creator switches on the email that asks for a review, we put each paid order on a list with when it was paid, send its buyer one email on the creator's behalf, and keep a mark that its buyer was asked, for 120 days. The link in that email, tied to the order and the address it went to, works for 60 days; its link to stop being asked works for 400 days, and pressing it keeps a one-way hash of the address for that store for good, so that store never asks again.
Video rooms. When a creator chooses a video room for their calls, each booking, or each time of a group call or session, gets a Jitsi Meet address with a random name. We keep it for 60 days after the call and put it in the booking emails, reminders, calendar files, the creator's bookings feed and the buyer's list of purchases. Jitsi Meet (meet.jit.si) is run by 8x8, not by us: whoever opens the room uses that service under its own privacy policy, and the first person in may be asked to sign in to it with an account such as Google. We send Jitsi nothing ourselves. A community's live event has a room of its own, made with the event, as the section on live events describes.
Google Calendar or Zoom, if a creator connects it. A creator can connect their own Google Calendar to their store, so that an event with a Google Meet link is made on it for each booked call set to Google Meet and, if they choose it, for a community's live event. A creator can connect a Zoom account in the same way, once Zoom approves our Marketplace listing. This section says what happens then. None of it happens unless a creator connects one. Only the store's owner and its Admins can connect or disconnect it, and the owner is emailed each time.
Google. When a creator connects Google Calendar, we ask Google for their account's identity and email address (openid, email), to show which account is connected, and for one permission, https://www.googleapis.com/auth/calendar.events. We use that permission only to create, change and delete the events of calls booked through their store, and of their community's live events, each with a Google Meet link, on their primary calendar. We do not read, change or delete any other event, and we read nothing else from their calendar or their Google account. What we send Google: for a one-to-one call, a title with the product and the buyer's name (or their email address when there is no name), a description with the store's address and the buyer's email address, the time, and the buyer's email address on the event's guest list; for a group call or a session on dates, the product's title, the time and each buyer's email address on the guest list, up to 200, set so that guests do not see one another; for a live event, only its title, its time and the address of its page, and no member's name or email address. Google is told not to email anyone about these events: the booking emails come from us. When a booking is moved the event moves with it, and when it is refunded in full the event is deleted or the buyer taken off the guest list.
Marktmorgen's use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. We use that information only to make and keep these meetings, never for advertising; we do not sell it, transfer it to anyone else except as needed to provide this feature or as the law requires, or use it to train any artificial intelligence model; and no person reads it unless the creator asks us to for support, it is needed for security, or the law requires it.
Zoom. When a creator connects Zoom, we ask for permission to create, read, change and delete the meetings of the Zoom user who connects, and to read that user's own profile for the name and email address shown in the studio. We only change or delete meetings we made, and we do not read the user's other meetings, recordings, chats or participant lists. What we send Zoom: for a one-to-one call, a topic with the product and the buyer's name (or their email address when there is no name), an agenda with the store's address and the buyer's email address, and the time; for a group call or a session on dates, the product's title and the time; for a live event, only its title, its time and the address of its page. The link that starts a meeting as its host is asked of Zoom when the creator presses Start, shown to them, and never stored.
What we keep, and how it ends. For each connection we keep the account's ID, email address and name, when and by whom it was connected, and the access and refresh tokens the provider gives us, encrypted at rest; the tokens never leave our servers. For each meeting we keep which account made it, its ID, link, title and time and, on Google, its guest list, until 60 days after the meeting. We keep a short log of problems with a connection for 30 days, and each consent in progress for ten minutes. When a creator disconnects from the studio, we give the token back to Google or Zoom so that access ends on their side too, and delete the connection and its tokens; meetings already made stay on the creator's calendar or Zoom account. If the creator removes our app from their Zoom account, Zoom tells us and we delete every connection that user made, with its tokens, at once. If the creator withdraws our access in their Google account, we stop using the connection and tell them, and disconnecting deletes it.
Usage and technical data. We may collect information such as IP address, browser type, device type, pages visited, referring URL, and approximate location derived from IP address. This helps us operate, secure, and improve the Services.
Communications. If you email us, we keep the content of that correspondence and your contact details so we can respond.
Creator research answers. If you fill in the form at marktmorgen.com/creators, we collect your name, email address, country, the platform where you sell, the store or profile link you choose to share, your answers, the date you sent them, and the consent choices you checked. To limit abuse, we also keep a one-way hash of your IP address for one hour; we do not store the IP address itself with your answers.
Research outreach. If we contacted you first to ask about your experience as a creator, we used business contact details you had made public: your name, your business email address or social media profile, your store or profile link and, for UK companies, details from the public Companies House register. We use them only to send that research message and to continue the conversation if you reply. Our legal basis is our legitimate interest in understanding what creators need before we build a product. You can object at any time by replying “stop” or by emailing us, and we will not contact you again.
2. How we use information
We use personal information to:
- create and manage your account;
- process subscriptions, renewals, cancellations, and refunds, and email you before a charge you might not expect: the first one after your free trial, and each renewal of a yearly subscription;
- provide the Services: host your store page, keep the files you sell where only you can reach them, and hand a file to a buyer who paid you for it;
- send you a free copy you asked a creator's store for and, once you use the link we sent, add your address to that creator's list with the choice you made;
- communicate with you about your account, billing, and service updates;
- detect, prevent, and investigate fraud, abuse, and security incidents;
- comply with legal obligations;
- improve the reliability and quality of the Services; and
- if you answered our creator research, read your answers to decide what to build next and, only if you checked the matching optional box, email you follow-up questions about your answers or tell you when we launch a product for creators. Each of these is a separate choice, and we contact you only by email.
Where the GDPR or similar laws apply, we process personal data on the following legal bases: performance of a contract (providing the subscription), legitimate interests (security, service improvement, and necessary communications), consent (where we ask for it, such as the creator research form), and legal obligation. You can withdraw consent at any time by emailing us; this does not affect processing that happened before you withdrew it.
4. If you buy from a creator’s store
The store belongs to the creator, not to us. For the personal data of that store's buyers, and of the people who ask it for something free, the creator is the controller and Marktmorgen is their processor: we handle that data to run the store on their behalf and on their instructions, and we do not use it for our own purposes, do not sell it, and do not email a creator's buyers or list to market anything of ours.
The same is true for the members of a creator's community, the people who apply to their affiliate program, their students' quiz answers and certificates, and their buyers' reviews: the creator is the controller, and we handle that data on their behalf. When a creator connects an email platform, Google Calendar or Zoom, or chooses Jitsi Meet for their calls and events, that is the creator's choice, and the data sent or used there is governed by the creator's account and that service's own terms.
In practice this means a request about your data as a buyer — a copy of it, a correction, a deletion — is answered by the creator you bought from. Write to them first. If you write to us instead, we will pass it on and tell you we did.
Two things stay ours in that situation: the security of the systems the data sits in, and the legal obligations we have to keep records of our own, such as fraud prevention and anything the law requires us to retain.
6. Data retention
Account and billing records are kept for as long as your account is active and as needed for tax, accounting, and legal purposes. Support emails are retained as long as needed to resolve your request and maintain a reasonable business record.
A creator's list is kept for as long as their store exists, or until the creator, or the person on it, asks us to remove an address. A request for a free copy whose link is never used is deleted after 7 days. An address that unsubscribed from a creator stays on that list, marked as unsubscribed, so it is never written to again; if you ask for it to be deleted entirely instead, it is.
A community's posts, comments, pictures and member records are kept while the community exists, until the author or the creator deletes them. An affiliate program's records, license keys and the list of who holds them are kept with the store's records. Certificates are kept for good, so their pages keep proving what they say. Webhook deliveries are kept for up to seven days, and the mark that an event was sent for 30 days. A calendar reading is kept for up to six hours, and the calendar address until the creator removes it.
A store's team, invitations and activity log are kept until the store is deleted, and invitations run out after seven days. Passkeys are kept until removed, and the record of the browsers an account signed in from until 400 days after its last sign-in. Email drafts are kept until sent or deleted. An email platform's key is kept until the creator disconnects it, each record of a person sent there for up to a week, and the mark that they were sent for 30 days. A device's notification address is kept until it is removed or turned off. Reviews are kept until their buyer deletes them or the creator deletes the product. A video room's address is kept for 60 days after its call.
A live event and its list of who is coming are kept until the creator deletes the event once it is over or canceled, or until it makes room after 500 are kept; the record of each event email, for 30 days. What an import from another platform sends us is deleted 14 days after it began, except the contacts it added to a list, kept as the list is, and what past buyers were given, kept for as long as the store exists. A Google Calendar or Zoom connection is kept until the creator disconnects it or removes our app, each meeting's record until 60 days after the meeting, and a connection's problem log for 30 days.
Creator research answers are kept for up to 24 months from the date you sent them, or until you ask us to delete them, whichever comes first. They are stored with our database provider (Upstash) on infrastructure used by our hosting provider (Vercel).
Research outreach records (who we contacted, when, and any reply) are kept for up to 24 months from the last contact. If you ask us to stop, we keep only your name and contact detail on a do-not-contact list, so that we can respect your request.
7. International transfers
Marktmorgen serves customers internationally. Your information may be processed in the countries where we and our service providers operate, which include the United States and may include the European Union. Where required, we use appropriate safeguards for cross-border transfers. Our database provider, Upstash, stores the records this policy describes under its Data Processing Addendum, which includes the EU Standard Contractual Clauses, the UK Addendum and the EU-U.S. Data Privacy Framework.
8. Your rights, including under the GDPR
Depending on your location, you may have the right to access the personal data we hold about you; correct inaccurate data; delete your data; restrict or object to certain processing; receive a copy of your data in a portable format; and withdraw consent where processing is based on consent.
If you are in the European Economic Area or the United Kingdom, where the General Data Protection Regulation (GDPR) or the UK GDPR applies, or in another jurisdiction with similar laws, you may exercise these rights by emailing support@marktmorgen.com. We will respond within the time required by applicable law, typically one month under the GDPR. You also have the right to lodge a complaint with your local data protection authority.
You may cancel your account and subscription at any time. Cancellation and refunds are described in our Refund Policy.
9. Children’s privacy
The Services are not directed to children under 18. We do not knowingly collect personal information from children. If you believe a child has provided us with personal data, contact us and we will delete it.
10. Security
We use reasonable technical and organizational measures to protect personal information. No method of transmission or storage is completely secure. You are responsible for keeping your email inbox and any passkeys you add secure, since they are how you sign in.
11. Changes
We may update this Privacy Policy from time to time. The “Last updated” date at the top of this page will change when we do. We encourage you to review this page periodically.
12. Contact
Marktmorgen
Email: support@marktmorgen.com
Website: marktmorgen.com