Privacy Policy

Your data is yours. This page says what we collect, why we collect it, who we share it with, and how to reach us. We do not sell personal information.

Mission Campaign is email newsletters for churches and nonprofits. The product is in private beta. There is a public waitlist. Churches and nonprofits control their lists. We process those lists so we can send on their behalf.

This policy is grouped by who you are: a visitor, someone on the waitlist, an account holder, a workspace member, or a person on a customer’s list.

People on a customer’s list

If you get mail from a church or nonprofit that uses Mission Campaign, that organization is responsible for the list. They added you, imported you, or you joined from their public page or an embed. We store what they need to mail you, and we send their campaigns for them.

Questions about why you are on a list belong with that organization. Every campaign we send includes a way to leave the list, including one-click unsubscribe. Some emails include a link to update the name and email on file.

If you need help from us, email [email protected].

Visitors

You can read the homepage and the blog without an account.

We set a signed session cookie named _mission_campaign_key. It holds a session id, a CSRF token so forms cannot be forged from other sites, flash messages, and — if you were sent to sign in — the page to return to. The cookie can last a long time in the browser. Being signed in is a separate check against a session on our servers.

The public site remembers light or dark theme in your browser (localStorage key marketing-theme). That stays on your device.

We load the Geist font from Google Fonts.

When it is turned on, we count visits on the public site with Tinylytics.

When it is turned on, we send crash reports from the public site with Sentry so we can fix broken pages. Those reports go through our own server.

We do not run advertising pixels. We do not use Google Analytics.

Subscribe forms on customer pages are rate-limited by IP address so one visitor cannot flood a list. We do not store that IP on the contact.

Waitlist

Requesting an invite asks for your email. We send a short note to that address. Disposable mailbox domains are ignored — we create no row and send nothing.

A follow-up form can ask for your first name, last name, about how many people you email, how often you send, your organization, what you use today, and how you heard about us.

We use this to decide who to invite and to email you when we can. The people who run Mission Campaign can see waitlist entries.

To leave the waitlist, email [email protected].

Account holders

Sign-up starts with an email. We send a confirmation link. You choose your name, workspace name, and password on that page. That is how we know the address is yours. We will not tell a visitor whether an address already has an account.

We store:

• Email
• A hash of your password — not the password itself
• First and last name
• A profile photo, if you upload one
• Timezone, so dates look right
• Whether the account is confirmed
• A pending email, if you change your address

When you sign in we store a session: the IP address and browser (user agent) from that login, and when the session expires. Sessions go idle after 14 days — we extend them if you come back before the last week — and they never last more than 60 days from login. Expired sessions are deleted in production.

You can change your name, email, password, and photo under your account. Changing your password signs you out everywhere else. Changing your email sends a confirm link to the new address and a notice to the old one.

There is no button in the product to delete a user account. Email [email protected] and we will help.

Workspace members

A workspace is a church or nonprofit’s space. It has a name, a short id, a public-page username, and settings for that page.

Owners can invite people by email. An invite stores the address, who invited them, and when it expires. Accepting makes you a member of that workspace.

In a workspace we store what members put there: the contact list, tags, segments, campaigns, From addresses and sending domains, and images uploaded into a campaign. A CSV import keeps the file and a record that the importer said those people agreed to receive email.

If you send a help note from a workspace, we receive your name, email, workspace, and message so we can reply.

The workspace owner can delete the workspace. That removes it from the product. Images already sent in email may stay available so old messages still load.

What we store about people on a list

For each person on a workspace list we may store:

• Email
• First and last name
• Tags
• How they joined — the organization’s site, an embed, a CSV import, or added in the dashboard
• Status — pending, active, dormant, unsubscribed, bounced, or complained
• When those status changes happened

A public join stays pending until the person confirms the email we send. We give the same “check your email” answer whether the address is new, already pending, or already on the list.

Workspace members can export the list, mark someone dormant — they stay on the list and are not mailed — or delete a contact. Deleting removes the row. Send history keeps the email snapshot and drops the link to that person. Adding the same address later is a new contact.

We do not mail unsubscribed, bounced, complained, dormant, or pending people as active recipients. We also skip addresses on our platform-wide never-email list, in every workspace.

When a campaign is sent we store a message row: the email we sent to, whether it was a campaign or a test, and delivery times if our sending provider tells us it was delivered, bounced, or reported as spam. A hard bounce or spam report can update that person’s status on the list.

We do not track opens or clicks.

A test send goes to the signed-in member’s email only.

Cookies and local storage

• _mission_campaign_key — signed session cookie (session id, CSRF, flashes, return path)
• CSRF token — inside that cookie, and as a hidden field on forms
• timezone — IANA timezone name, set by the signed-in app so dates match your computer
• marketing-theme — light or dark, in localStorage on the public site

The signed-in app may also remember whether the sidebar is open (sidebar_state cookie) and the sidebar color (localStorage).

Who we share with

We use a few companies to run the product. They get what they need to do their job — not a copy of everything to use for their own marketing.

• Bento — account mail, confirmation, password reset, waitlist notes, subscription confirmations, and help replies
• PostShiba — campaign sending, and delivery events (delivered, bounce, complaint)
• Tinylytics — visit counts on the public site
• Sentry — crash reports, when configured
• Cloudflare — stores and serves uploaded files (profile photos and campaign images)
• Google Fonts — the typeface on the public site

We may also look at data when you ask for help, when we have to fix a failure, when we are investigating abuse or a security problem, or when the law requires it.

We do not sell personal information. We do not sell lists.

Children

Mission Campaign is for churches, nonprofits, and the adults who run them. It is not directed at children.

Where data is processed

We have not published a single hosting region. Data may be processed where we and the vendors above operate.

Your rights

Email [email protected]. Tell us what you want: a copy of what we have, a correction, or a deletion. We will need to make sure it is you.

People on a customer’s list can leave through the unsubscribe link in the email. Workspace members can edit or delete contacts they added. Account holders can edit their profile in the product.

Changes

If we change this policy we will update the date at the top of this page.

Questions

Email [email protected]. The Terms of Service cover how you may use the product.